메뉴
Use when writing any user-facing reply — answers, status updates, summaries, or final reports — especially after multi-step work, when tempted to show process, add headers to a short answer, open by classifying the question, or open with praise.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when asked to implement, build, add, fix, refactor, or change anything in a codebase — vague asks included. Tier-driven phases: intake, investigate, plan, build, verify, deliver. Entry point: /implement.
The map-reduce + blackboard pipeline that lets a small-context model digest inputs far beyond one attention window — a codebase, a long document, a corpus, a multi-part idea — and state only evidence-anchored, citation-checked conclusions. Use when / Trigger: executing or resuming an analyst run (/analyst:digest, /analyst:resume, /analyst:show), or any analysis input exceeds one 200-line chunk.
Use whenever a change needs a system-design decision — architecture, system design, data model, module/service boundaries, interface/API contracts, scale, or an ADR. The canonical discipline for designing systems: tradeoffs made explicit, the design sized to the 15 elicited context fields, one-way doors found by a five-flag checklist (one ADR each), every component earning its place through a two-cell subtraction walk, and every "start simple" seam carrying a concrete extraction trigger. Executed as checkpointed run steps (references/phase-*.md) that write into docs/architecture/ + docs/adr/ per scribe's documentation contract.
Stay focused on the project with the task in hand; recall another project's knowledge ONLY when the task actually needs it. When a task requires changing a shared dependency you own (a local composer/npm package in another repo), make the change IN that owning repo — commit, push, retag — then update and re-verify the consumer. Trigger: an edit is about to land inside a dependency directory, or a task can't be done without touching a package you maintain elsewhere.
Use when asked for a deep audit, production-readiness review, architecture review, or prioritized recommendations across a codebase or subsystem — orchestrates parallel reader agents with adversarial verification and publishes findings to docs/deep-analysis/
Run a large, multi-place task as a checkpointed state machine over the runs store — plan, adversarial plan review, wave-by-wave execution, synthesis — one step per invocation, resumable after any interruption. Trigger: cross-file refactor, data migration, large feature build, multi-source research — work that cannot finish in one pass. Manual invocation: /deep-work.
| name | outcome-first |
| description | Use when writing any user-facing reply — answers, status updates, summaries, or final reports — especially after multi-step work, when tempted to show process, add headers to a short answer, open by classifying the question, or open with praise. |
The first sentence answers the question; the reply's shape is a lookup on the ask type, never a model of the reader. Card: hooks/cards/outcome-first.md.
| Ask contains | Card | Fixed fields, fixed order |
|---|---|---|
| is / does / can / should | yes-no | answer (yes/no/blocked) · because (≤2 sentences) · evidence (path:line or command + output) |
| status / progress / where are we | status | done[] · in_progress[] · blocked[] · next · evidence_refs[] |
| find / list / what's wrong | findings | per finding: location · finding · severity · evidence, ordered by severity |
Never merge, reorder, or skip a field; never invent a fourth card. A why-question gets a because-answer in prose — the yes-no card only when the question was literally yes/no.
Rationalization to refuse: "I'll frame what kind of question this is first" — the answer needs no introduction.
Sentence one states the outcome; the reply matches exactly one card.
