Choosing a Workflow
The root router of the workflow family in packages/pi-thinkrail-workflow. It classifies the incoming
work and names the workflow skill that governs it — nothing more. A routed skill's steps live in that
skill alone; read it, don't run it from memory.
Classify
Read the request and the workspace, then answer three questions — usually silently, from what is already
in front of you:
- Is this project onboarding? No spec graph yet — an empty (or effectively empty) workspace where
the user brings a raw idea, or an existing codebase being set up / specced for the first time.
- Is this the PR lifecycle? Finished work shipping as a pull request, or an existing PR being
tended — created, brought up to date, given screenshots, its checks watched, its review comments
addressed. Fixes that flow from a PR's own review comments belong here, not to feature work.
- Does the work create or change anything in the project? A new feature, added functionality, a
behavior change, a nontrivial design decision — anything that alters what the project is or does.
If the route is genuinely ambiguous from the request alone, ask one short clarifying question
(ask_user_question, composed per the asking-user-questions concept skill) rather than guessing.
Route
| Classification |
Route |
| Project onboarding — no spec graph yet: an empty workspace with a raw idea, or an existing codebase to set up / spec |
Read and follow setting-up-a-project — a dispatcher that routes on the workspace's state |
| The PR lifecycle — finished work to ship as a pull request, or an existing PR to tend: create, bring up to date, screenshots, checks, review comments |
Read and follow shipping-a-pr |
| The work creates or changes anything in the project — a new feature, added functionality, a behavior change, a nontrivial design decision |
Read and follow brainstorming — however small it looks; that skill owns the "too small" judgment |
| Anything else — answering questions, explaining code, running commands or checks, work that changes nothing |
No matching workflow. Say so in one line (e.g. "No workflow skill covers this; proceeding directly.") and proceed with your own judgment. Never stretch a route to fit — a forced route is worse than none. |
One route per piece of work. If a request bundles work from different rows (e.g. "explain X, then
change Y"), route the part that changes the project and handle the rest directly.
Red flags — stop and re-route
- You started designing or editing before naming a route — routing comes first.
- You are following a routed skill's steps from memory instead of reading that skill.
- You classed a change as "anything else" because it looked small or mechanical — size is
brainstorming's call, not the router's.
Handoff
This skill ends by naming exactly one of: setting-up-a-project, shipping-a-pr,
brainstorming, or no matching workflow (proceed with judgment). Adding a workflow to the family adds a row to the table above —
see the writing-workflow-skills skill.
1---2name: choosing-a-workflow3description: Use FIRST when any new piece of work arrives — a request, feature, change, fix, question, or idea — before starting on it or choosing an approach. Not for continuing work already routed to a workflow skill.4---56# Choosing a Workflow78The root router of the workflow family in `packages/pi-thinkrail-workflow`. It classifies the incoming9work and names the workflow skill that governs it — nothing more. A routed skill's steps live in that10skill alone; read it, don't run it from memory.1112## Classify1314Read the request and the workspace, then answer three questions — usually silently, from what is already15in front of you:16171. **Is this project onboarding?** No spec graph yet — an empty (or effectively empty) workspace where18 the user brings a raw idea, or an existing codebase being set up / specced for the first time.192. **Is this the PR lifecycle?** Finished work shipping as a pull request, or an existing PR being20 tended — created, brought up to date, given screenshots, its checks watched, its review comments21 addressed. Fixes that flow from a PR's own review comments belong here, not to feature work.223. **Does the work create or change anything in the project?** A new feature, added functionality, a23 behavior change, a nontrivial design decision — anything that alters what the project is or does.2425If the route is genuinely ambiguous from the request alone, ask one short clarifying question26(`ask_user_question`, composed per the **asking-user-questions** concept skill) rather than guessing.2728## Route2930| Classification | Route |31|---|---|32| Project onboarding — no spec graph yet: an empty workspace with a raw idea, or an existing codebase to set up / spec | Read and follow **setting-up-a-project** — a dispatcher that routes on the workspace's state |33| The PR lifecycle — finished work to ship as a pull request, or an existing PR to tend: create, bring up to date, screenshots, checks, review comments | Read and follow **shipping-a-pr** |34| The work creates or changes anything in the project — a new feature, added functionality, a behavior change, a nontrivial design decision | Read and follow **brainstorming** — however small it looks; that skill owns the "too small" judgment |35| Anything else — answering questions, explaining code, running commands or checks, work that changes nothing | **No matching workflow.** Say so in one line (e.g. "No workflow skill covers this; proceeding directly.") and proceed with your own judgment. Never stretch a route to fit — a forced route is worse than none. |3637One route per piece of work. If a request bundles work from different rows (e.g. "explain X, then38change Y"), route the part that changes the project and handle the rest directly.3940## Red flags — stop and re-route4142- You started designing or editing before naming a route — routing comes first.43- You are following a routed skill's steps from memory instead of reading that skill.44- You classed a change as "anything else" because it looked small or mechanical — size is45 brainstorming's call, not the router's.4647## Handoff4849This skill ends by naming exactly one of: **setting-up-a-project**, **shipping-a-pr**,50**brainstorming**, or **no matching workflow** (proceed with judgment). Adding a workflow to the family adds a row to the table above —51see the writing-workflow-skills skill.
jetbrains