メニュー
Use when investigating a bug, test failure, or unexpected behavior and proposing a fix — always runs investigation in Plan Mode so no code changes happen until the root cause and approach are confirmed.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when preparing notes for a 1:1 with a report, drafting written feedback, or summarizing a person's recent work/contributions ahead of a conversation or review cycle.
Use when asked to generate or update architecture diagrams or ER (entity-relationship) diagrams from the codebase — the code is the source of truth, not existing docs.
Use when the user asks how to reduce Claude Code costs, manage token usage, choose the right model for a task, or wants a review of whether a session/workflow is running efficiently.
Use when the user asks for a standup update, daily summary, "what did I work on yesterday", or wants to recap recent commits before a team sync.
Use when writing or reviewing code that crosses a trust boundary (user input, external APIs, file/network/DB I/O) — guards against invalid input, injection, unsafe failure modes, and missing validation at the edges without over-defending internal code.
Use when reviewing local code changes for correctness and assessing the blast radius / impact of a change — what else could break, who/what depends on the changed code.
| name | debug-with-plan |
| description | Use when investigating a bug, test failure, or unexpected behavior and proposing a fix — always runs investigation in Plan Mode so no code changes happen until the root cause and approach are confirmed. |
Investigation and fix-proposal are kept separate from execution. Root-cause first, propose second, implement only after explicit approval.
Reproduce first. Get the exact failing command/input/conditions before theorizing. If you can't reproduce it, say so — don't guess at a fix for something you haven't observed.
Stay in Plan Mode for the investigation. Read code, run read-only
commands (logs, git log/git blame on the suspect area, test runs),
form a hypothesis — but make no edits yet.
Find the root cause, not the symptom. Ask "why" until you hit something that, if changed, would have prevented the bug from ever being possible — not just the line where it surfaced.
Propose, don't just fix. Lay out:
## Root cause
<what's actually wrong, and why it produces the observed symptom>
## Proposed fix
<the change, and why this is the right altitude — fixing the cause,
not papering over the symptom>
## Alternatives considered
<if there were other viable approaches, name them and why you didn't pick them>
## Regression test
<what test would have caught this, and that you'll add it>
Exit Plan Mode and implement only after the user approves the proposal.