thinkrail

The existing-codebase branch of project-setup: analyze a repo that has code but no specs and draft its first spec graph — goal-and-requirements.md, architecture.md, and short per-module SPEC.md files — deriving everything possible from the code and agent files (AGENTS.md, CLAUDE.md, README, manifests), and interviewing the user only for the intent the code can't reveal. Normally reached via the project-setup dispatcher.

The brand-new / empty-project branch of project-setup: turn a raw idea into a focused goal-and-requirements.md through a short, tailored interview (vision, MVP scope, success criteria, tech). Normally reached via the project-setup dispatcher, on an empty workspace with no code yet. For features in an existing project, use brainstorming instead.

Start here to set up or onboard a project's specs — draft its first goal-and-requirements.md, architecture.md, and module specs. The front door that detects whether the workspace is a brand-new/empty project or an existing codebase with no specs, then routes to the right flow. Use whenever asked to set up, onboard, initialize, or spec a project.

Use this BEFORE any creative or feature work: building a new feature, adding functionality, changing behavior, or making a nontrivial design decision. Turns the user's request into a validated design — recorded as a spec-graph task-spec — before any implementation. Do not skip this because a change looks small.

The project's specs are its ground truth: durable documents describing the architecture, decisions, contracts, and boundaries behind the code, organized as a connected graph. Read this skill and reach for the spec tools FIRST — before reading code — whenever you explore the project, plan or start a task, add or change a feature, implement anything, investigate an area, check work against recorded decisions and contracts, or otherwise work with specs. Also use it to create or maintain specs.