CODING PLANNER

Documentation · AR Labs

Skill

The skill

How Coding Planner routes a request, what its commands produce, and where your decisions enter.

Purpose and scope

Coding Planner turns a coding request into work that can be specified, implemented, reviewed, and delivered. The skill chooses the route; individual commands perform the work.

Use it for features, fixes, or refactors that need tracked implementation. Prose, formatting, and obvious corrections too small to warrant an issue can be done directly.

Choose task or campaign

Route by the shape of the work
Route Use when Planning output
Lone task One coherent deliverable, even if it touches several files. One tracked issue and an implementation spec.
Campaign Several independently reviewable pieces need a shared plan. A requirements plan, a tree of issues, and a spec for each piece.

When uncertain, start as a task. Spec generation can reveal that it needs to split. The amount of evidence depends on risk, so a task receives the same review expectations as a campaign’s individual pieces.

Plan a campaign

  1. Clarify the request

    /grill-me resolves decisions, scope boundaries, system decomposition, and acceptance scenarios in a design brief. A continued interview hands the brief to a fresh planning session.

  2. Capture the design

    /generate-design produces the architecture document, decision records, and diagrams when needed. This is optional at entry.

  3. Define the deliverables

    /create-prp produces the feature requirements plan (PRP): outcomes, acceptance criteria, and vertical slices. The design is revisited with those requirements before decomposition.

  4. Split into tracked work

    /to-issues creates the individual work items and their dependencies. Each item owns a bounded outcome and its acceptance criteria.

Take a task through delivery

The work performed for each task
Command Produces Reader’s check
/generate-spec Implementation approach, file scope, acceptance scenarios, and proof obligations. Is this a complete, feasible plan for the stated outcome?
/implement Code, tests, evidence, an implementation walkthrough, and a pull request where required. Does the result do what the spec asks?
/review An independent verdict on standards, spec compliance, architecture, and evidence. Are findings resolved against the code being delivered?
/deliver The reviewed change landed on its integration target. Has the code arrived where the work was intended to land?

After a campaign’s children finish, /integrate checks the assembled result and reconciles it with the design. Passing individual tasks does not establish that the whole feature works.

Know which document to read

Each artifact has a distinct purpose
Artifact Question it answers
Design brief What was decided during clarification? It is the input to requirements planning.
Design document and decision records Why is the system structured this way?
PRP What must the feature deliver? It replaces the brief as the requirements source.
Issue What outcome does this piece own, and what must it satisfy?
Implementation spec How should this piece be built in this codebase?
Tests, evidence, and review What demonstrates that the implemented result meets its obligations?

Start with the current issue and its linked spec when resuming work. Use recorded provenance to establish what has already happened; a detailed document alone does not establish that a planning step ran.

Decisions and approval

The person settles scope, approves plans, and answers unresolved design questions. Authors produce the artifacts; an independent reviewer assesses the code. Execution can pause at approvals or continue under a configured autonomy level.

For the checks behind those boundaries, read Harness: checks and approvals. The entry reference covers the persisted interview handoff.

In the lab's repository, the skill lives at .claude/skills/coding-planner/SKILL.md and its commands in .claude/commands/coding-planner/. The public repository holds an earlier release.