choosing-a-workflow

1# Choosing a Workflow
2 
3The root router of the workflow family. It classifies new
4workflow-eligible work and names the workflow skill that governs it — nothing more. Work already routed
5resumes its active workflow instead. A routed skill's steps live in that skill alone; read it, don't run
6it from memory.
7 
8## Classify
9 
10For a new piece of work, read the request and use what is already known to answer three questions:
11 
121. **Is this project onboarding?** No spec graph yet — an empty or effectively empty workspace where
13   the user brings a raw idea, or an existing codebase being set up or specced for the first time.
142. **Is this the PR lifecycle?** Finished work shipping as a pull request, or an existing PR being
15   tended — created, brought up to date, given screenshots, its checks watched, or its review comments
16   addressed. Fixes that flow from a PR's own review comments belong here.
173. **Does the work change what the product does?** A new feature, a change in behavior, or a bug
18   fix — however small, and even when the request already spells out the design. A detailed request
19   shortens the interview; it never skips it.
20 
21If none applies, no workflow is needed: proceed directly without a workflow announcement. Only work
22that changes no behavior belongs here: a non-PR question, explanation, or check; a typo, documentation, or
23configuration-only edit; a mechanical refactor such as a rename.
24…