/writing-plans
The spec-to-plan bridge. Routed to by /feature once the brainstormed spec is approved, and by /sprint before execution. Decomposes the spec into 2–5 minute tasks, each carrying its exact file path(s) and a concrete verification step that maps to a tdd obligation. Writes the plan
$ npx -y skills add arbiterForge/codeArbiter --skill writing-plans --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/writing-plans
Context preview
The summary Claude sees to decide when to auto-load this skill.
The spec-to-plan bridge. Routed to by /feature once the brainstormed spec is approved, and by /sprint before execution. Decomposes the spec into 2–5 minute tasks, each carrying its exact file path(s) and a concrete verification step that maps to a tdd obligation. Writes the plan
SKILL.md
writing-plans.SKILL.mdname: writing-plans
description: The spec-to-plan bridge. Routed to by /feature once the brainstormed spec is approved, and by /sprint before execution. Decomposes the spec into 2–5 minute tasks, each carrying its exact file path(s) and a concrete verification step that maps to a tdd obligation. Writes the plan to .codearbiter/plans/<slug>.md, ordered with dependencies flagged and an MVP slice identifiable. Nothing executes until every task has a path and a verification and the task set covers every acceptance criterion.
writing-plans
Turn an approved spec into an executable plan. Routed to by `/feature` (after spec approval) and `/sprint`.
Pre-flight
Read these, or STOP and surface the gap — never plan against an unapproved or missing spec:
- `{{PROJECT_DIR}}/.codearbiter/specs/<slug>.md` — the approved brainstorming spec. The single source of acceptance criteria. Absent or unapproved → STOP and route back to `/feature`.
- `{{PROJECT_DIR}}/.codearbiter/CONTEXT.md` — the `stage:` frontmatter (the maturity value) and project context.
- `{{PROJECT_DIR}}/.codearbiter/tech-stack.md` — file layout, build/test/lint invocations. A verification step cites a real command from here, never a guess.
- `{{PROJECT_DIR}}/.codearbiter/coding-standards.md` — structure and naming, so a task names the right path.
**If `--farm` was requested:** check that `FARM_API_KEY` is set in the environment{{IF:pi}} of the Pi parent process{{ELSE}} (or `.env` at `{{PLUGIN_ROOT}}/tools/.env`){{END}}. If absent, BLOCK immediately — cite `{{PLUGIN_ROOT}}/includes/farm.md` for setup instructions. Do not proceed; the farm dispatcher cannot run without an API key. Model selection happens later (at dispatch time in `subagent-driven-development`), so no model research is needed here.
Phase 1 — Criterion extraction · gate: BLOCK
Lift every acceptance criterion from the spec verbatim and assign each a stable ID (`AC-01`, `AC-02`, …). This list is the coverage ledger for the whole plan — Phase 4 checks the task set against it.
A criterion the spec leaves ambiguous is a `[CONFIRM-NN]` against `{{PROJECT_DIR}}/.codearbiter/open-questions.md` — surface it, do not invent the intent.
Gate: every acceptance criterion in the spec captured as a numbered `AC-NN`. A partial ledger does not pass.
Phase 2 — Task decomposition · gate: BLOCK
Break the work into the smallest honest units. Each **task** is ~2–5 minutes of work and carries:
- **id** — `T-01`, `T-02`, … stable.
- **path(s)** — the exact file(s) the task touches, resolved against `coding-standards.md`. "Some files" is not a path.
- **verification** — one concrete command or observable that proves the task done (e.g., `<test cmd> -k test_token_expiry passes`, `endpoint returns 401 on missing header`). It cites a real `tech-stack.md` invocation or a directly observable behavior — never "looks right".
- **maps-to** — the `tdd` obligation this verification corresponds to. The verification *maps to* a tdd obligation; it does NOT replace tdd's own gates. `tdd` Phase 1 still derives and Phase 4 still verifies obligations against passing tests.
- **covers** — the `AC-NN`(s) this task advances.
Split anything that won't fit ~5 minutes or touches unrelated paths. Reject the trap of one monolithic "implement the feature" task — that defeats the plan.
Gate: every task has at least one path AND a verification AND a `maps-to`. A task missing any of the three blocks the plan.
Phase 3 — Order & MVP slice · gate: BLOCK
Order tasks so each runs only after what it depends on. Flag every dependency explicitly (`T-07 depends on T-03`). A cycle is a decomposition error — return to Phase 2 and split.
Group the ordered tasks so the **MVP slice** is identifiable: the minimal contiguous task set that satisfies the spec's core acceptance criteria and is shippable on its own. Everything past the slice is incremental.
Gate: a complete dependency order with no cycle, and an explicitly marked MVP slice.
Phase 4 — Coverage proof & write · gate: BLOCK
Cross the ledger against the task set, both directions:
- Every `AC-NN` is covered by at least one task's `covers`. An uncovered criterion blocks — author the missing task.
- Every task advances at least one `AC-NN`. A task that covers nothing is scope creep — cut it or surface it.
Then write the plan to `{{PROJECT_DIR}}/.codearbiter/plans/<slug>.md` — `<slug>` matching the spec — with the `AC-NN` ledger, the ordered task table (id · path(s) · verification · maps-to · covers · depends-on · **status**, initialized `PENDING`), the marked MVP slice, and any out-of-scope item tagged inline `[NEEDS-TRIAGE]`.
The status column is the pipeline's resume ledger: `subagent-driven-development` flips a task to `ACCEPTED` the moment it accepts it, so an interrupted run (crash, compaction, closed session) is re-entered by `/feature` at the first non-`ACCEPTED` task instead of restarted from brainstorming.
Gate: bijective coverage proven — no criterion without a task, no task without a criterion — and the plan written to disk. This clears the path to execution: `executing-plans` (checkpointed, via `/feature`) or `subagent-driven-development` (autonomous, via `/sprint`) — each routes every task through `tdd`. The plan never hands off to `tdd` directly.
Phase 4-farm extension (only when `--farm` was requested)
When `--farm` was requested, after the bijective coverage gate passes and the `.md` plan is written, produce the farm artifact (`plan.json`) — **one MVP slice at a time** — per `{{PLUGIN_ROOT}}/skills/writing-plans/references/farm-plan.md`. Load that leaf and follow it; it owns the per-task failing-test + schema-valid `plan.json` procedure.
Gate: all failing tests written and confirmed failing; `plan.json` written and schema-valid. Both artifacts exist before handing off to `subagent-driven-development`.
Hard rules
- MUST NOT plan against an absent or unapproved spec — STOP and route back to `/feature`.
- MUST NOT em
Read more
name: writing-plans description: The spec-to-plan bridge. Routed to by /feature once the brainstormed spec is approved, and by /sprint before execution. Decomposes the spec into 2–5 minute tasks, each carrying its exact file path(s) and a concrete verification step that maps to a tdd obligation. Writes the plan to .codearbiter/plans/<slug>.md, ordered with dependencies flagged and an MVP slice identifiable. Nothing executes until every task has a path and a verification and the task set covers every acceptance criterion.
writing-plans
Turn an approved spec into an executable plan. Routed to by `/feature` (after spec approval) and `/sprint`.
Pre-flight
Read these, or STOP and surface the gap — never plan against an unapproved or missing spec:
- `{{PROJECT_DIR}}/.codearbiter/specs/<slug>.md` — the approved brainstorming spec. The single source of acceptance criteria. Absent or unapproved → STOP and route back to `/feature`.
- `{{PROJECT_DIR}}/.codearbiter/CONTEXT.md` — the `stage:` frontmatter (the maturity value) and project context.
- `{{PROJECT_DIR}}/.codearbiter/tech-stack.md` — file layout, build/test/lint invocations. A verification step cites a real command from here, never a guess.
- `{{PROJECT_DIR}}/.codearbiter/coding-standards.md` — structure and naming, so a task names the right path.
**If `--farm` was requested:** check that `FARM_API_KEY` is set in the environment{{IF:pi}} of the Pi parent process{{ELSE}} (or `.env` at `{{PLUGIN_ROOT}}/tools/.env`){{END}}. If absent, BLOCK immediately — cite `{{PLUGIN_ROOT}}/includes/farm.md` for setup instructions. Do not proceed; the farm dispatcher cannot run without an API key. Model selection happens later (at dispatch time in `subagent-driven-development`), so no model research is needed here.
Phase 1 — Criterion extraction · gate: BLOCK
Lift every acceptance criterion from the spec verbatim and assign each a stable ID (`AC-01`, `AC-02`, …). This list is the coverage ledger for the whole plan — Phase 4 checks the task set against it.
A criterion the spec leaves ambiguous is a `[CONFIRM-NN]` against `{{PROJECT_DIR}}/.codearbiter/open-questions.md` — surface it, do not invent the intent.
Gate: every acceptance criterion in the spec captured as a numbered `AC-NN`. A partial ledger does not pass.
Phase 2 — Task decomposition · gate: BLOCK
Break the work into the smallest honest units. Each **task** is ~2–5 minutes of work and carries:
- **id** — `T-01`, `T-02`, … stable.
- **path(s)** — the exact file(s) the task touches, resolved against `coding-standards.md`. "Some files" is not a path.
- **verification** — one concrete command or observable that proves the task done (e.g., `<test cmd> -k test_token_expiry passes`, `endpoint returns 401 on missing header`). It cites a real `tech-stack.md` invocation or a directly observable behavior — never "looks right".
- **maps-to** — the `tdd` obligation this verification corresponds to. The verification *maps to* a tdd obligation; it does NOT replace tdd's own gates. `tdd` Phase 1 still derives and Phase 4 still verifies obligations against passing tests.
- **covers** — the `AC-NN`(s) this task advances.
Split anything that won't fit ~5 minutes or touches unrelated paths. Reject the trap of one monolithic "implement the feature" task — that defeats the plan.
Gate: every task has at least one path AND a verification AND a `maps-to`. A task missing any of the three blocks the plan.
Phase 3 — Order & MVP slice · gate: BLOCK
Order tasks so each runs only after what it depends on. Flag every dependency explicitly (`T-07 depends on T-03`). A cycle is a decomposition error — return to Phase 2 and split.
Group the ordered tasks so the **MVP slice** is identifiable: the minimal contiguous task set that satisfies the spec's core acceptance criteria and is shippable on its own. Everything past the slice is incremental.
Gate: a complete dependency order with no cycle, and an explicitly marked MVP slice.
Phase 4 — Coverage proof & write · gate: BLOCK
Cross the ledger against the task set, both directions:
- Every `AC-NN` is covered by at least one task's `covers`. An uncovered criterion blocks — author the missing task.
- Every task advances at least one `AC-NN`. A task that covers nothing is scope creep — cut it or surface it.
Then write the plan to `{{PROJECT_DIR}}/.codearbiter/plans/<slug>.md` — `<slug>` matching the spec — with the `AC-NN` ledger, the ordered task table (id · path(s) · verification · maps-to · covers · depends-on · **status**, initialized `PENDING`), the marked MVP slice, and any out-of-scope item tagged inline `[NEEDS-TRIAGE]`.
The status column is the pipeline's resume ledger: `subagent-driven-development` flips a task to `ACCEPTED` the moment it accepts it, so an interrupted run (crash, compaction, closed session) is re-entered by `/feature` at the first non-`ACCEPTED` task instead of restarted from brainstorming.
Gate: bijective coverage proven — no criterion without a task, no task without a criterion — and the plan written to disk. This clears the path to execution: `executing-plans` (checkpointed, via `/feature`) or `subagent-driven-development` (autonomous, via `/sprint`) — each routes every task through `tdd`. The plan never hands off to `tdd` directly.
Phase 4-farm extension (only when `--farm` was requested)
When `--farm` was requested, after the bijective coverage gate passes and the `.md` plan is written, produce the farm artifact (`plan.json`) — **one MVP slice at a time** — per `{{PLUGIN_ROOT}}/skills/writing-plans/references/farm-plan.md`. Load that leaf and follow it; it owns the per-task failing-test + schema-valid `plan.json` procedure.
Gate: all failing tests written and confirmed failing; `plan.json` written and schema-valid. Both artifacts exist before handing off to `subagent-driven-development`.
Hard rules
- MUST NOT plan against an absent or unapproved spec — STOP and route back to `/feature`.
- MUST NOT em
Showing the first part of this file.
When you can't trust yourself with your code base, trust Arbiter.
Repo: arbiterForge/codeArbiter
Other skills on codearbiter.
- /brainstorming
The Socratic spec-refinement front of /feature, and the planning front of /sprint. Routed to BEFORE any code — it takes a one-line idea and drives it to an approved, concrete spec with testable acceptance criteria. Four gated phases — frame, refine, write, approve. No
Open skill - /commit-gate
The only path to a commit. Routed to when the user invokes /commit or otherwise instructs codeArbiter to persist staged changes. Nine gated phases — permission, branch, classification, verification (test/lint/secrets), behavioral proof, diff review, selective stage, message,
Open skill - /context-check
Optional manual drift audit — report stale provenance-tracked docs (via _provenancelib drift detection across .codearbiter/.provenance/), then per stale doc offer re-scout / re-baseline / defer. Not the daily loop; commit-gate auto-heal owns routine maintenance.
Open skill - /context-creation
The brownfield back-fill. Routed to by /create-context, and by startup when .codearbiter/CONTEXT.md lacks the <!--INITIALIZED--> body marker but source code exists. Six gated phases — pre-flight, scout dispatch, synthesis, gap interview, write, lock. Reads the existing codebase
Open skill - /crypto-compliance
The banned-primitive gate. Routed to when changed code hashes, signs, encrypts, derives keys, generates security-relevant randomness, configures TLS, or imports a crypto library. Rejects broken primitives, disabled TLS verification, and home-rolled crypto; the approved-primitive
Open skill - /debug
Investigate-then-decide root-cause analysis for a defect whose cause is unknown (distinct from /fix, which assumes a known bug). Five gated phases: capture, hypothesize, gather, decide, hand off. Investigation only, no code changes; exits to /fix, /adr, or a no-action close.
Open skill

