minimal-diff
Ship the smallest change that solves the Issue. Use on every implementation task; scope creep is the default failure mode of executors.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Ship the smallest change that solves the Issue. Use on every implementation task; scope creep is the default failure mode of executors.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | minimal-diff |
| description | Ship the smallest change that solves the Issue. Use on every implementation task; scope creep is the default failure mode of executors. |
The Issue names the work. Anything outside the Issue is a separate Issue — not a bonus, not a cleanup freebie.
Write a one-line note in your Summary (followups: list), not a code change. The Coordinator decides whether to spawn a new Issue.
Run git diff. For every hunk, ask: does this line change the behavior the Issue asks for? If not, it is out of scope — revert it. Three similar lines is better than a premature abstraction.
End with ## Summary: files changed, tests run, status. Keep the "files changed" list short; if it's long, the diff probably creeped.
Pick the right worker class for each Issue. Use every time you assign an Issue; wrong routing wastes tokens and creates rework.
Break a Company Goal into 3-10 atomic Issues. Use when a Goal arrives with no pre-existing plan and you need to produce a shippable work list.
Run build/test/lint and read the actual output before claiming done. Use on every implementation task, at the end.
Start implementation with a red test. Use on any bugfix or new behavior — not on refactors or style changes.
Report research results in a form other agents can act on. Use at the end of every Explorer session.
Find files and code patterns fast. Use for every codebase question that starts with "where is X" or "how is Y used".