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.
npx skills add https://github.com/arbiterForge/codeArbiter --skill writing-plans
Turn an approved spec into an executable plan. Routed to by /feature (after spec approval) and /sprint.
Read these, or STOP and surface the gap — never plan against an unapproved or missing spec:
${CLAUDE_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.${CLAUDE_PROJECT_DIR}/.codearbiter/CONTEXT.md — the stage: frontmatter (the maturity value) and project context.${CLAUDE_PROJECT_DIR}/.codearbiter/tech-stack.md — file layout, build/test/lint invocations. A verification step cites a real command from here, never a guess.${CLAUDE_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 (or .env at ${CLAUDE_PLUGIN_ROOT}/tools/.env). If absent, BLOCK immediately — cite ${CLAUDE_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.
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
${CLAUDE_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.
Break the work into the smallest honest units. Each task is ~2–5 minutes of work and carries:
T-01, T-02, … stable.coding-standards.md. "Some files" is not a path.<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".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.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.
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.
Cross the ledger against the task set, both directions:
AC-NN is covered by at least one task's covers. An uncovered criterion blocks — author the missing task.AC-NN. A task that covers nothing is scope creep — cut it or surface it.Then write the plan to ${CLAUDE_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.
--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
${CLAUDE_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.
/feature.tdd gate — it maps to a tdd obligation, it does not replace one.tech-stack.md or STOP.[CONFIRM-NN].plan.json in --farm mode without writing and confirming each failing test first.meta.model or meta.apiBaseUrl in plan.json — these belong to the dispatch step.--farm if FARM_API_KEY is absent — cite ${CLAUDE_PLUGIN_ROOT}/includes/farm.md and BLOCK.${CLAUDE_PLUGIN_ROOT}/includes/harvest.md) over any [NEEDS-TRIAGE] out-of-scope items — batch-confirm promoting them to open-tasks.md (work) or open-questions.md (decisions) so they don't die in the plan file.Use when implementing any feature or bugfix, before writing implementation code
Use when implementing any feature or bugfix, before writing implementation code - write the test first, watch it fail, write minimal code to pass; ensures tests actually verify behavior by requiring failure first
Use when creating new skills, editing existing skills, or verifying skills work before deployment - applies TDD to process documentation by testing with subagents before writing, iterating until bulletproof against rationalization
Rules for writing and reviewing tests in the Remotion repository. Use whenever adding, editing, or reviewing tests, especially for Studio UI, rendering, CLI, server, media, and cross-package changes, to prefer complete integration workflows over narrow helper tests and implementation details.
Patterns and pitfalls for the ONNX domain Attention operator (opset 23/24) CUDA implementation. Use when modifying the dispatch cascade in core/providers/cuda/llm/attention.cc, writing mask/bias CUDA kernels, debugging attention test routing, or adding features to the ONNX Attention op. NOT for contrib domain MultiHeadAttention/GroupQueryAttention.
> Translates a HuggingFace model into a prefill-only AutoDeploy custom model using reference custom ops, validates with hierarchical equivalence tests.
Translates a HuggingFace model into a prefill-only AutoDeploy custom model using reference custom ops, validates with hierarchical equivalence tests.
Generates Angular 17+ standalone components, configures advanced routing with lazy loading and guards, implements NgRx state management, applies RxJS patterns, and optimizes bundle performance. Use when building Angular 17+ applications with standalone components or signals, setting up NgRx stores, establishing RxJS reactive patterns, performance tuning, or writing Angular tests for enterprise apps.
Take arbiterforge/codearbiter-ca-writing-plans from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.