Core Workflow

Visual overview

The fresh-project loop starts with /onboard, turns your plans into the project overview, then repeats through spec, implementation, proof, review, and completion. Write the plans directly or optionally run /discovery for a deep planning conversation. For existing apps, start with Existing Codebase instead of /onboard.

Establish the plan

You own project-plan.md and build-plan.md. The overview step checks those inputs and generates the compact project context agents read every session.

write plans directly ---------------------------> /overview
optional /discovery -> review + approve plans -> /overview

Both paths produce the same user-owned planning files. Discovery never runs from onboarding and never becomes a gate before Overview.

Configure shared workflow policy

blueprint/config.json keeps deterministic workflow preferences consistent across every adapter. It controls review cadence, checkpoint commits, branch prefixes, verification strictness, regular and Continuous quality gates, and Continuous Mode limits. Automatic audit, check, and try-guide gates all default to manual.

Onboarding can explain and update selected values. See Project Configuration for the complete schema and the approval boundaries configuration cannot change.

Run overview again whenever the plans change materially, including when you add a feature after the initial build.

Set up shared verification separately

Automatic GitHub checks are optional setup, not another stage inside every feature. Run $ci or /ci after onboarding or adoption when the project should use one documented Verify command locally and in GitHub Actions.

/onboard or /adopt -> /ci -> Verify locally -> GitHub runs Verify

Verify combines only configured checks in order: typecheck, tests, then build. If you later run /tests, it adds the real test command to an existing Verify recipe without creating CI by itself.

Repeat for each feature

The normal loop keeps one active scope at a time.

If a bug or small request is not in the build plan, use /fix instead of /feature.

If you know something is failing but do not yet know why, start with /debug. It reproduces and traces the failure without editing the project. A confirmed problem then returns to /implement when it belongs to active work, or /fix when it is a standalone bug.

Run the remaining plan continuously

$continuous or /continuous is an explicit alternative when you want to run multiple planned features without the normal step pauses:

/continuous -> next unchecked feature -> local completion -> repeat

The build plan is the queue, so no feature list is required. Each feature keeps its own branch, verification, archive, and one clean local main commit. The run stops on decisions, unsafe state, failed checks, or unresolved serious findings, and it never pushes. See Continuous.

Continue after the initial build

build-plan.md remains the ordered roadmap after the first release. Keep completed items checked, preserve their numbers, and add new unchecked features under the current list or a milestone heading such as ## Post-MVP.

The continuing loop is:

add feature to build-plan.md -> /overview -> /feature -> /implement -> /check -> /complete

Most incremental features change only the build plan. Update project-plan.md too when the new capability changes the product direction, users, data, stack, monetization, UI/UX, or deployment.

If you run /feature "new capability" and no planned item matches, the skill offers to add it. It shows the proposed plan changes first, waits for approval, refreshes the overview, and then creates the spec. It checks for near-duplicates before adding anything and keeps /fix as the path for bugs or small ad-hoc changes.

Reverse a completed feature

Use /rollback <feature> when shipped work needs to be removed. Rollback matches the checked build-plan item to its archived spec and exact git commit, reviews later commits for dependency risk, then writes a guarded rollback spec and stops.

/rollback 4 -> review risk + spec -> /implement -> /check -> /complete

Implementation reverses only the approved product diff on a rollback/ branch. Blueprint plans, context, adapters, and history are protected. Completion keeps the original feature archive, adds a separate rollback record, and unchecks the build-plan item so the roadmap reflects that the capability is no longer present. See the Rollback command for the conflict and data safety boundaries.

Keep human gates visible

The workflow deliberately pauses before application code and before merging. A feature spec is cheaper to change than a large diff, and a diff is cheaper to change than a broken main branch.

Autopilot is an explicit opt-in for one bounded feature or fix pass. It uses Verify and the configured regular quality gates, repairs confirmed high-severity findings when its audit gate runs, and delays the human review packet until the pass ends. It does not run rollbacks or merge.

Continuous Mode is explicit opt-in for the remaining planned feature queue. It uses the configured Continuous quality gates and can complete the local branch, archive, and merge lifecycle for each feature. Neither mode can push, deploy, publish, send, perform destructive actions, waive checks, or make product decisions for you.

Resume from files

The current feature checklist records completed steps. Git records code and checkpoint commits. After a context clear, $status or /status can determine the exact next action without reconstructing the project from conversation history.