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.
Use when asked to set up, onboard, initialize, or spec a project with no spec graph, or when invoked by the app's Set-up-project card. Not for ordinary work in an already-specced project.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
The single entry point for turning a project into a spec graph. Figure out which situation you're in, then follow the matching skill — don't improvise the flow yourself.
Look at the workspace and use the spec tools (spec_grep / spec_graph):
goal-and-requirements.md or any SPEC.md)?| Situation | Follow |
|---|---|
| Already has specs | Don't redo it. Briefly offer to review/extend the graph (fill obvious gaps — a missing architecture.md, un-specced modules). Other work routes as usual: features, behavior changes, and bug fixes through brainstorming; work that changes no behavior proceeds directly. Declined → stop. Accepted → Graph extension below. |
| No specs · empty / near-empty repo | The starting-a-new-project skill — interview the user to turn the idea into goal-and-requirements.md. |
| No specs · real source code | The importing-a-codebase skill — analyze the code + agent files and draft the first spec graph, asking only for intent the code can't reveal. |
Read and follow that skill's steps.
No dedicated skill covers extending an existing graph. If the offer is accepted, align and adapt to the user's request with your own judgment, holding the writing-specs bar without a routing announcement.
Ends by naming exactly one of: starting-a-new-project, importing-a-codebase, or — when specs already exist — the review/extend offer above (declined → stop; accepted → graph extension on judgment against the writing-specs bar).
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.
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.
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.
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.