メニュー
Use before claiming anything works, is fixed, is done, or passes; before status updates on changes you haven't run; before agreeing with someone else's claim about your work; and before state-changing commands like restarts, deletes, or config edits.
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 | prove-it |
| description | Use before claiming anything works, is fixed, is done, or passes; before status updates on changes you haven't run; before agreeing with someone else's claim about your work; and before state-changing commands like restarts, deletes, or config edits. |
Claims require evidence produced this session. Three rungs: written (the code exists), runs (you executed it without error), verified (you watched it do the right thing). The injected form of this rule is the card at hooks/cards/prove-it.md.
| Thought | Reality |
|---|---|
| "The change is simple — it obviously works" | Simple changes break builds daily; running it is cheaper than being wrong. |
| "'Should work' is honest hedging" | It is an unverified claim in hedge clothing. Name the rung. |
Every claim in the reply names its rung; every "verified" has attached evidence.
