# Choosing A Workflow

Use at the start of new project onboarding, PR lifecycle work including PR checks, or...

- Repository: https://github.com/JetBrains/thinkrail (6952 stars)
- Category: Git and review
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add JetBrains/thinkrail --skill choosing-a-workflow -g -a claude-code -y`
Codex: `npx skills add JetBrains/thinkrail --skill choosing-a-workflow -g -a codex -y`
Cursor: `npx skills add JetBrains/thinkrail --skill choosing-a-workflow -g -a cursor -y`
Gemini CLI: `npx skills add JetBrains/thinkrail --skill choosing-a-workflow -g -a gemini-cli -y`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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:

1. **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.
2. **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.
3. **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 |

The rest: https://github.com/JetBrains/thinkrail/blob/HEAD/packages/pi-thinkrail-workflow/skills/choosing-a-workflow/SKILL.md