explain
無料Explain what a piece of code does — a specific file, class, or method in close detail, or a user-facing flow as a concise system overview. What it does and why, not whether it's good.
日本語の概要は準備中です。原文の説明を表示しています。
Pressure-test an assumption, decision, or inherited constraint — Socratic cross-examination that forces you to defend or abandon your position
インストールする前に、エージェントに与えられる指示の中身を確認できます。
This is a conversation, not an audit. Do not produce structured output. Do not list findings upfront. Start by understanding what they actually believe — then follow the thread with one question at a time.
If you already have context — from a prior skill, from the conversation, or from something specific the user said — name the assumption you want to pressure-test and why. Then go straight to questioning. Do not ask them to restate what you already know.
If you do not have context, ask one plain question to surface the assumption before proceeding.
Ask one question at a time, following the gaps in their reasoning. The goal is to make them interrogate the assumption themselves before you weigh in. Good questions to reach for:
On origin:
On necessity:
On validity:
On alternatives:
Have opinions. When an assumption is weak, say so and say why.
When the assumption has been turned over enough — either they've found the weakness themselves, or it's clear they won't without a push — give your verdict directly. Is the assumption valid, partially valid, or worth rejecting? Name the underlying need, name the better path if there is one, and say why.
Close with:
"Did you already suspect this assumption was wrong — or did you genuinely believe it until now?"
Wait for their answer. Respond with one short paragraph: what their answer reveals about how they form and hold assumptions under pressure, and whether they're more likely to inherit bad decisions or make them consciously.
Rigorous and direct. This is not about being contrarian — it's about knowing why you're doing something before you do it. Push hard on weak assumptions. Confirm strong ones clearly. Never mistake familiarity for validity.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Explain what a piece of code does — a specific file, class, or method in close detail, or a user-facing flow as a concise system overview. What it does and why, not whether it's good.
日本語の概要は準備中です。原文の説明を表示しています。
Take one new feature slice from idea to reviewed, committed code in a single guided pass — scope it into the smallest shippable slice, build it test-first with strict TDD, review and fix the diff, then commit it. Chains slice → test-driven-development → the built-in /code-review → git-commit. Not for reviewing an existing PR, upgrades, or open-ended design questions.
日本語の概要は準備中です。原文の説明を表示しています。
Turn the working changes into one or more atomic commits with well-written messages. Use whenever the user runs /git-commit or asks to commit their work, wrap up a feature, or "commit what I have."
日本語の概要は準備中です。原文の説明を表示しています。
Prepare to deliver difficult technical news to a client — a conversational prep session before the hard conversation happens
日本語の概要は準備中です。原文の説明を表示しています。
Walk through the Designer/Developer wrap-up checklist for offboarding a client engagement — conversationally, one item at a time.
日本語の概要は準備中です。原文の説明を表示しています。
Discover how a codebase already handles a specific concern — search broadly, find every instance, and assess consistency. The "how does this app do X?" tool.
日本語の概要は準備中です。原文の説明を表示しています。