メニュー
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.
