# Planning Workflow > Route work when the next action is unclear or coordination is explicitly requested. Clear implementation tasks do not need this skill or a plan. - Skill: `ferueda/planning-workflow` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add ferueda/planning-workflow` - Raw SKILL.md: https://api.skillmd.com/api/skills/ferueda/planning-workflow/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: ferueda (https://skillmd.com/u/ferueda) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ferueda/planning-workflow --- # 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. - An explicit request to classify an issue or work item: use `triage`. Work already assigned for execution does not need a triage pass first. - 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 ` 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.