メニュー
Use as stages 2-3 of specpowers-flow — generate OpenSpec artifacts from the approved proposal, then harden them via validation and independent adversarial review.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use as stages 6-7 of specpowers-flow — execute the approved plan test-first (subagent-driven per task recommended, inline single-context supported) with no silent scope expansion, then verify the implementation complies with the hardened spec via independent adversarial review.
Use as stage 8 of specpowers-flow — verify all prior gates passed, then archive the completed change into the living specs (real openspec archive if present, else conservative guided merge).
Use as stages 4-5 of specpowers-flow — write the implementation plan into tasks.md from the hardened spec, then build and check the requirement coverage matrix before any code is written.
Use as stage 1 of specpowers-flow — turn a raw idea into an approved direction and a proposal.md draft. Produces problem statement, scope boundary, success criteria, non-goals, risks, and open questions.
Use when running an end-to-end spec-driven change from idea to archive — orchestrates the full OpenSpec + Superpowers-style workflow with explicit stages and gates. Triggers - "run the full specpowers flow", "start a complete spec-driven change", "go from brainstorm to archive", "use specpowers for this feature".
| name | specpowers-spec |
| description | Use as stages 2-3 of specpowers-flow — generate OpenSpec artifacts from the approved proposal, then harden them via validation and independent adversarial review. |
Starting from the approved proposal.md in openspec/changes/<change>/, produce the full artifact set for the change:
proposal.md with any sections left as stubs during brainstorm (Why, What Changes, Impact).design.md covering the technical approach, key decisions, and explicit tradeoffs.tasks.md as a checkbox task list that will drive planning and execution.specs/<capability>/spec.md using ADDED/MODIFIED/REMOVED markers with testable SHALL statements and at least one concrete scenario per statement.Consult references/openspec-artifact-format.md for the required directory layout and section contracts for each artifact type.
Completion gate: the change directory exists at openspec/changes/<change>/ and all four artifact types — proposal.md, design.md, tasks.md, and at least one spec delta — are present and structurally complete (no missing required sections).
With the artifacts from stage 2 in place, run two hardening passes before any planning begins:
Validation pass: if the openspec CLI is available, run openspec validate on the change directory and resolve every reported issue. Without the CLI, apply the format checks defined in references/openspec-artifact-format.md — verify required sections exist, every SHALL statement has at least one scenario, and no ADDED/MODIFIED/REMOVED marker is missing its requirement body.
Adversarial review pass: dispatch an independent reviewer per references/independent-review.md with the instruction to refute the spec. The reviewer applies the full checklist in references/adversarial-spec-review.md, probing for ambiguity, missing failure paths, lifecycle gaps, rollback omissions, and security surfaces. Collect the returned findings (verdict, severity, location, recommendation). For each finding at blocker severity, update the relevant artifact to address it; for accepted non-blocker findings, incorporate them or record a reasoned disposition. Re-run the validation pass after syncing findings to confirm the updated artifacts are still structurally sound.
Gate evidence: once both passes succeed, record a gate evidence file at openspec/changes/<change>/.specpowers/gates/harden-spec.yaml per references/stage-protocol.md. The record must contain the stage name, timestamp, and a sha256 digest for each artifact verified (proposal.md, design.md, tasks.md, every spec delta). On any future resume, the orchestrator recomputes these digests; if an artifact has changed, this gate is invalidated along with all downstream gates.
Completion gate: validation passes with no errors, no finding of blocker severity remains unresolved, and all accepted findings have been synced back into the spec artifacts. Advance to specpowers-plan.