Route new project setup, pull request lifecycle work, and product changes such as features or bug fixes to the workflow that governs them. It also identifies when a request needs no workflow, so routine questions and nonbehavioral edits can proceed directly.
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.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
The root router of the workflow family in packages/pi-thinkrail-workflow. 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.
For a new piece of work, read the request and use what is already known to answer three questions:
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.
| 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 |
One route per piece of work. If a request bundles unfinished implementation with PR work, route the implementation first and return to shipping-a-pr only after it lands.
This skill ends by naming exactly one of: setting-up-a-project, shipping-a-pr, brainstorming, or no matching workflow (proceed directly). Adding a workflow to the family adds a row to the table above — see the writing-workflow-skills skill.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Helps an agent ask focused questions when a workflow needs user decisions. It groups independent questions into rounds, frames choices as visible outcomes, and explains how to continue when answers are skipped or interactive questions are unavailable.
Clarify the product goal and technical choices before a feature, behavior change, or bug fix is built. The workflow records an agreed task specification, guides implementation against it, and updates durable project specs when the work lands.
Build a draft specification graph for an existing codebase that has no specs. Survey its guidance files, documentation, manifests, and code; infer project purpose and module boundaries, adopt suitable existing design documents, and validate the resulting graph for review.
Manage MCP server settings in ThinkRail when servers need to be added, changed, enabled, or troubleshot. It explains user and repository configuration, safe credential references, approval and sign-in steps, and how to load deferred tools.
Routes project setup to the appropriate workflow by checking whether specs and source code already exist. It sends an empty workspace with a new idea toward a requirements document, or an existing codebase toward an initial spec graph, and offers review when specs are already present.
Create and maintain pull requests for finished work. The workflow can sync a branch, update PR details or screenshots, report checks, monitor CI when asked, and address review comments while confirming the latest Git and GitHub state.