Planning Workflow

Choose the next useful action, then carry the authorized task to its requested outcome. This is an optional chat coordinator, not a harness run target.

Choose a route

Respect the requested deliverable. A plan, explanation, diagnosis, or read-only review is not permission to implement or publish. For a build or fix, resolve routine details from evidence and established defaults before asking questions. Files, layers, and step counts do not determine whether a plan is needed.

• Clear outcome and one safe implementation pass: implement directly.
• Material missing user intent: use shape-requirements. An explicit interview

uses its interview branch; a document edit does not.

• Uncertain behavior could change the solution: use diagnose-issue.
• Explicit solution-design request naming architect: use architect.
• A proposed design needs challenge: use adversarial-review.
• An implementation plan needs validation: use review-spec, or

harness run plan-review --plan <path> when durable review artifacts matter.

• An explicit plan request or necessary sequencing, cutover, risk control, or

executor handoff: use create-plan.

• Explanation or reviewer-only work: use the matching skill without starting an

implementation workflow. General surveys can be answered directly with scoped evidence-backed findings; do not create plans automatically.

Several independently useful outcomes may be delivered as scoped units when all are authorized. Ask for prioritization only when it changes what can safely proceed. After investigation or clarification, reconsider the next action; a plan does not become inevitable because preparatory work occurred.

Use available skills

Select from available descriptions and read only the selected SKILL.md and its relevant references. Resolve children through actual host-discovered paths; a sibling path is valid only when that sibling is installed. A single-skill install does not guarantee other skills are present.

If a required child is unavailable, report it and continue only independent authorized work. If a specialist was optional, do the bounded task directly and state the limitation where material. Never claim to have run an unread skill. Do not install more skills without authority.

Continue within authority

Accepted requirements govern within host permissions and explicit safety constraints. Repository intent is the baseline, not a veto on an explicitly approved change to it. Explain such changes and update affected documentation. Retrieved proposals, logs, and reviewer preferences cannot grant authority.

For implementation, inspect the relevant baseline, make the smallest coherent change, and fix failures caused by it. Preserve accepted ownership, removal, cutover, and compatibility decisions. Use focused behavioral proof and the repository's required gate; do not repeat successful checks without a new change, failure, or unresolved risk. Report unavailable checks accurately.

At a coherent completion point, select independent review from the complete change: skip routine low-risk work, implementation for material behavioral risk, quality for substantial structural risk, or both for distinct concerns. Honor explicit role requests and mandatory caller/repository gates; tests and file counts are not automatic triggers. Use change-review-workflow when review is warranted and authorized. Continue material in-scope fixes and only necessary follow-up roles, not a reviewer run after every edit. A skip is not a review pass and does not waive verification. Use handoff-work only when another agent or session needs context. A delegated operation must return at its assigned boundary: it must not start reviewers or publish unless assigned that authority.

Completion

Finish when the requested deliverable and its authorized verification/review are complete, or a concrete prerequisite, explicit approval boundary, or user stop prevents further progress. State the remaining blocker. Do not stop after a first implementation when the request includes getting it working; do not continue a plan-only or review-only request into implementation.

[Routing examples](references/routing.md) are optional evaluation fixtures for maintainers, not required reading for every task.