workflow-routerlisted

# 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. #### Concrete single behavior change - Concrete single behavior change: define done → `test-driven-development` test-first change → `code-simplification` on the cha