Specpowers plan
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.From its SKILL.md
npx -y skills add ujffdi/specpowers-flow --skill specpowers-planAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.7 KB, 770 tokens by cl100k_base, as published. Nobody here has run it
Stage 4: Plan from Spec
With a hardened spec in place (stages 2-3 complete, gate evidence digests still matching disk), write the implementation plan directly into openspec/changes/<change>/tasks.md. This file already exists from stage 2 — add the plan by filling in or replacing the task list in place rather than creating a parallel document, so the change directory always has a single source of truth for tasks.
Each task entry must include:
- Steps: a concrete, ordered sequence of actions that fully implements the requirement it covers.
- Target files/modules: the specific files, directories, or modules the task will create or modify.
- Test strategy: what kind of test (unit, integration, contract, structural check) demonstrates the task is done and links to a requirement row.
- Verification commands: the exact commands to run to confirm the implementation is correct (build commands, test runners, validators, lint checks).
- Rollback/failure handling: how to undo this task's changes if it fails mid-execution, or how to detect a partial-apply so the next attempt is safe.
- Dependency assumptions: any other tasks, artifacts, or runtime conditions this task depends on, stated explicitly, so nothing is silently assumed.
Derive each task entry directly from the hardened spec deltas — every SHALL statement and every scenario in openspec/changes/<change>/specs/<capability>/spec.md must be traceable to at least one task. Do not add tasks for behavior not present in the hardened spec; if a needed step has no backing requirement, stop and update the spec first.
Completion gate: tasks.md contains a plan with at least one task per requirement in the hardened spec, every task entry carries the required fields listed above, and the plan is explicitly grounded in the hardened spec (not an independent scope expansion). Record a gate evidence file at openspec/changes/<change>/.specpowers/gates/plan-from-spec.yaml per references/stage-protocol.md with the stage name, timestamp, and sha256 digest of tasks.md and each spec delta reviewed.
Stage 5: Check Coverage
Build the requirement coverage matrix before any implementation begins. Follow the format and rules in references/plan-coverage-matrix.md.
Extract every requirement from the spec deltas: each SHALL statement and each scenario becomes one row in the matrix. For each row, record the plan step from tasks.md that addresses it, the target implementation area (file or module), and the verification command or test that will confirm it. Assign a status: Covered when both a plan step and a verification path are present, Missing when no plan step addresses the requirement, or Blocked when a plan step exists but no concrete verification path can be defined.
Once the initial matrix is assembled, apply the pass rule: every requirement row must have status Covered. Any row with status Missing or Blocked means the plan is incomplete — route back to stage 4 (plan-from-spec) to add or repair the relevant tasks before proceeding. Do not advance on a partial matrix.
When every row is Covered, record a gate evidence file at openspec/changes/<change>/.specpowers/gates/check-coverage.yaml per references/stage-protocol.md with the stage name, timestamp, and sha256 digest of tasks.md and the coverage matrix artifact.
Completion gate: the coverage matrix is complete, every requirement has at least one plan step and at least one verification path, and no row is in Missing or Blocked status. Advance to specpowers-build.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most plan spec skills give in 770 tokens
Counted across 1,099 of the 1,860 authors here whose files we hold, read 2026-08-07
- Ask one question at a timein 51 of 1099
- Break plans into vertical slicesin 29 of 1099, across 11 files
- Publish issues in dependency orderin 27 of 1099, across 9 files
- Iterate until user approves the breakdownin 25 of 1099, across 7 files
- Explore the repository to understand the codebase statein 24 of 1099, across 7 files
- Use domain glossary vocabularyin 23 of 1099, across 5 files
- Apply correct triage labels to published issuesin 23 of 1099, across 5 files
- Prefer AFK slices over HITLin 22 of 1099, across 7 files
- Write a specification before writing any codein 22 of 1099, across 14 files
- Write failing tests before implementation codein 22 of 1099, across 20 files
- Ask clarifying questions until requirements are concretein 21 of 1099, across 13 files
- Respect existing architecture decision recordsin 20 of 1099, across 5 files
Said here and by no other author read
- fill the existing task list in place
- derive each task directly from the hardened spec
- trace every SHALL statement to at least one task
- trace every scenario to at least one task
- build the requirement coverage matrix before implementation
- extract every requirement into the matrix
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.