Choosing A Workflow
Use at the start of new project onboarding, PR lifecycle work including PR checks, or...
Install
npx skills add JetBrains/thinkrail --skill choosing-a-workflow -g -a claude-code -y- Repository
- JetBrains/thinkrail7k
- Category
- Git and review
- Updated
- 3d ago
- License
- Apache-2.0
- Context cost
- Lightabout 744 tokens
- Runs scripts
- No, instructions only
What it does
Use at the start of new project onboarding, PR lifecycle work including PR checks, or any change to what the product does, a feature, a behavior change, or a bug fix. Not for continuing work already routed to a workflow, non-PR questions, checks, explanations, or edits that change no behavior.
Choosing a Workflow
The root router of the workflow family. It classifies new workflow-eligible work and names the workflow skill that governs it, nothing more. Work already routed resumes its active workflow instead. A routed skill's steps live in that skill alone; read it, don't run it from memory.
Classify
For a new piece of work, read the request and use what is already known to answer three questions:
- 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 or 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, or its review comments addressed. Fixes that flow from a PR's own review comments belong here.
- Does the work change what the product does? A new feature, a change in behavior, or a bug fix, however small, and even when the request already spells out the design. A detailed request shortens the interview; it never skips it.
If none applies, no workflow is needed: proceed directly without a workflow announcement. Only work that changes no behavior belongs here: a non-PR question, explanation, or check; a typo, documentation, or configuration-only edit; a mechanical refactor such as a rename.
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 | Read and follow setting-up-a-project |
| PR lifecycle work | Read and follow shipping-a-pr |
| A feature, behavior change, or bug fix | Read and follow brainstorming |
| None of the above | No matching workflow; proceed directly without announcing the routing result |
