plan-work

Files (1)

• SKILL.md

SKILL.md (first lines)

# plan-work

Read the [working agreement](../../references/workflow.md) unless it is already in this task's context. A natural-language request for an implementation plan selects planning; routine reasoning within implementation does not start a separate planning phase. Inspect the repository and applicable saved project lessons, checking their current relevance, before asking questions it can answer. Planning is read-only; verification inspection does not start the product.

Before questions, inspect other worktrees for in-flight work, this checkout's uncommitted changes, and any unfinished plan or implementation already documented for this repository. A clean idle worktree is not another workstream. When another workstream is active, or this checkout is dirty with work this task must leave untouched, read [concurrent work](../../references/concurrent-work.md) and record continue, wait, or isolate in the plan so implementation can cold-start. A clean sole checkout needs no worktree and no extra question.

Check relevant plan choices against the north star, assignment and success criteria; resolve consequential conflicts with the user. Stop when goal, boundaries, interfaces and checks suffice. Clear assignments need no interview or advance design of routine details. When a short throwaway experiment can settle an open technical question, propose that experiment instead of lengthening the plan with a risk list.

When the assignment is vague or underspecified (missing the goal, boundaries, interfaces, success checks, or a material trade-off that would change the plan), an optional short decision round may ask only what blocks a sound plan. Offer a concrete recommendation the user can accept or steer, in a few focused questions. Do not add a separate skill for that round, require a glossary, expand a design tree, or turn planning or Auto-Work into an interview gate.

For a repeated correction, read the [learning guidance](../../references/learning-work.md) and plan prevention proportionate to the assignment.

Explain the goal, benefit, observable success criteria, scope, exclusions, material risks, dependencies, decisions, and checks. Add files, interfaces, commands or sequencing where needed. When an API, CLI, or config format is new or changed, include a short usage example from the caller's side and the key signatures, so a later implementation that has only the plan has a concrete target and review can compare against it. A small change may need only a few paragraphs. When the change is material (architecture, a breaking change, several surfaces, or schema and deploy), note second-order effects in one line each where relevant: caller impact, data or migration, deploy and rollback, and security or auth. Mark speculation as speculation. Omit this for a routine fix or a small plan.

Resolve success criteria, instruction conflicts, permissions, and consequential choices before presenting a descriptively titled plan. Carry the working agreement, [implementation requirements](../../references/implementation-work.md), accepted references, and open learning collection into the handoff. Use an accessible reference to the complete collection when the receiver can reach it; include the full collection when they cannot. In standalone work, direct the human to check the plan and start implementation, then commission Review. In expressly commissioned Auto-Work, Light waits for plan approval; Dark can continue within the human goal assignment. Neither mode resolves consequential missing choices by assumption.

Read the playbook [catalog](../engineering-work/references/catalog.md) when the user asks about methods or the task has an unexplained defect, a live failure or trace, a performance or metric target, refactoring, a design question, a visual reference, agent comparison, skill authoring, or resumed work. Skip it for a clear routine change with suitable checks. Assess verifier gaps independently. Only selected additions enter the plan. Unaccepted offers neither block planning nor recur for that scope.

Check task-relevant prerequisites and feedback routes, reusing current evidence. Follow [project readiness](../../references/project-readiness.md) when the affected behavior has no runnable check, a check route is broken or differs between local and CI, or a consequential decision lacks project direction. Reuse suitable checks and verifiers without an offer or justification. Read the [verification guidance](../../references/verification-work.md) for options and handoff when acceptance needs a running UI, CLI, service, side effect, or journey that established checks do not cover, or when the change affects a feature an existing verifier covers. Retain evidence gaps and acceptance limits.

From geldmacher/workflow, MIT.

More from geldmacher/workflow