Workflow Router

Use this as the entry point; downstream skills own their detailed instructions.

Route

Classify the request, choose only the matching sequence below, and state each transition rationale in one line. Do not add steps from another route unless its trigger is present. In an unfamiliar repository, perform repository reconnaissance first (inspect structure, README/CONTRIBUTING, build/test framework, CI, recent git log, and existing patterns per AI_ENGINEERING_WORKFLOW.md).

Idea to staging

Vague but issue-sized request

• Vague or decision-heavy request that clarification resolves into one independently verifiable issue: clarify-work → define-done.
• Transition rationale: clarify creates a safe boundary; define-done makes success testable; a single bounded issue needs no decomposition or durable spec.

Broad or multi-issue request

• Broad request that will not fit one independently verifiable issue even after clarification (several independent slices, unsettled cross-cutting decisions, a durable spec the team will reference across issues): clarify-work → to-prd → decompose-to-issues.
• Transition rationale: clarify creates a safe boundary; to-prd drafts and publishes the durable spec the multi-issue breakdown depends on; decomposition protects independent delivery.