메뉴
Use when diagnosing a reported failure, regression, or unexpected behavior — before proposing any fix, when a fix attempt has just failed, or when the evidence in hand is secondhand (a user report, a log summary, an assumption about what a library or platform does).
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when orchestrating multi-agent or long-running work — spawning sub-agents, fanning out parallel tasks, delegating subtasks, running build-then-review loops, or deciding which model tier should do a piece of work.
Use when building a self-contained shippable artifact from scratch or a major rev — an MCP server, a CLI, a library/SDK, a skills pack, a plugin — anything that gets packaged and released rather than merged into an existing app.
Use when maintaining project state across sessions — writing or reading a STATE.md / MEMORY.md, recording what was learned, resuming interrupted work, or deciding what to persist for future sessions.
Use when building or redesigning a product UI/visual system — creating a design system, writing or following a DESIGN.md contract, generating screens in a design tool (Stitch/Figma) then porting to code, or doing a branded visual redesign.
Use during hands-on execution of any coding or agent task — especially when following multi-item instructions, deciding how much to deliberate, about to claim something is done, or producing output at risk of reading as generic AI slop.
Use when building or running an automated measurement/audit/reporting pipeline that scores many subjects on a recurring basis and reports to stakeholders — a compliance monitor, a benchmark matrix, a metrics dashboard, a scheduled scan-and-report.
| name | diagnostic-loop |
| description | Use when diagnosing a reported failure, regression, or unexpected behavior — before proposing any fix, when a fix attempt has just failed, or when the evidence in hand is secondhand (a user report, a log summary, an assumption about what a library or platform does). |
Find the true cause, then fix it — never the other way around. Diagnose from evidence in this order, never skipping ahead:
When a step depends on what a library, framework, or platform does (redirect handling, event ordering, caching, selector semantics), prove it with a throwaway probe — a 5-line script against the real thing — rather than asserting it from memory. Memory of platform behavior is where confident wrong fixes come from.
| Excuse | Reality |
|---|---|
| "The cause is obvious" | Obvious causes are hypotheses. The probe is the cheapest step — run it. |
| "Reproducing is expensive" | A fix without a reproduction is a guess; a wrong guess costs a second debugging round plus the fake fix's cleanup. |
| "I'll patch the 2–3 likely suspects" | Parallel patching means you never learn which one it was — and two of the three patches are now unexplained code. |
| "The library definitely does X" | Prove it with a probe. Platform behavior is the most common source of confidently wrong fixes. |
| "Third attempt, slightly different" | Two failures already falsified the model. Stop and re-derive it. |
A trivially evident bug — a failing test naming the exact line, a typo — can be fixed directly; the reproduction already exists. Even then: verify after the fix, and state the cause. If "trivial" turns out wrong once, re-enter the loop at step 1.
See PROVENANCE.md for sources.
