The Complete /kit + GSD Lifecycle

One sentence in.
A running business out.

The Master Starter Kit takes a product idea through 127 steps of research, architecture, design, planning, code generation, deployment, monitoring, and autonomous iteration. This is the full journey, end to end.

Phase 1
You Describe
Your idea, your market, your constraints
→
Phase 2
Kit Researches
Adversarial tribunal, 60-100 files
→
Phase 3
Kit Designs
Architecture, specs, API contracts
→
Phase 4
Kit Plans
Tasks, sprints, quality gates
→
Phase 5
GSD Builds
Code, test, verify, deploy, iterate
127
Steps
13
Phases
17
Quality Gates
6
Session Boundaries
8
Verification Layers
Act I

The Kit plans your product

You type /kit. Over the next several hours, across multiple sessions, the Kit interviews you, researches your market, designs your system, and produces every document needed to build.

Step 0
Ecosystem Setup
Verifies plugins, health checks, creates project scaffolding. Detects whether you're starting from scratch, enhancing existing code, migrating, or repurposing.
~30 minutes
Gate 0 — Approve path
0
$ claude
> /kit

✓ Health check passed
✓ Plugins verified (297 skills)
✓ Version current

◆ MATURITY SCAN
  Score: 0 (greenfield)
  Path: Standard

GATE 0 Approve path? [y]
// Intake builds your CONFIG

PROJECT: "Fleet management SaaS"
DOMAIN: "Logistics"
CATEGORY: "SaaS + B2B Platform"
STACK: "Next.js / Supabase"
FEATURES: 23 from intake
EXPANSION: +14 from brainstorm

// TTG: reasoning shown to user
// User confirms or corrects
1
Steps 1 - 2
Discovery & Intake
The Kit interviews you about your product, detects your tech stack, verifies versions against live sources (never training data), brainstorms features beyond your initial scope, and classifies your project into domains and categories to load specialized knowledge packs.
~3-6 hours
Project brief Feature list Domain rules Expansion backlog CLAUDE.md
Gate 1 — Intake confirmed
Step 3
Adversarial Tribunal
A 10-round adversarial research process that debates competitors, builds user personas, assesses technical feasibility, maps risks, and recommends features. Domain-specific rounds fire automatically for specialized verticals (healthcare compliance, fintech regulation, etc.).
~2-4 hours
60-100 research files Competitor analysis Persona cards Feasibility verdicts Risk matrix
Gate 3 — Feature priorities approved
3
// Tribunal rounds

Round 1 Competitive landscape
Round 2 User personas & jobs
Round 3 Technical feasibility
Round 4 Risk assessment
Round 5 Feature prioritization
Round 6 Business model
Round 7 UX paradigms
Round 8 Data architecture
Round 9 Growth strategy
Round 10 Final verdict

+ domain rounds
Logistics: fleet regs, ELD,
DOT compliance, telematics
// TTG: resolved internally
// Only irreversible decisions
// surface to user

Service Specs
  auth-service · 3,200 words
  fleet-service · 4,100 words
  dispatch-service · 3,800 words
  billing-service · 2,900 words
  reporting-service · 2,600 words

Screen Specs
  18 screens with component trees,
  state shapes, responsive behavior
4
Steps 4 - 7
Architecture & Design
Service specifications, screen specifications, API contracts, database schemas, navigation maps, design tokens, and a full component library. Each spec goes through the Think-Then-Generate protocol. Mobile architecture, offline strategy, and native features are planned if applicable.
~3-6 hours
Service specs Screen specs API contracts DB schema Nav map Design direction Component library
Gate 5 — Architecture approved
Steps 8 - 16
Planning, Quality & Infrastructure
Every spec becomes concrete task files with acceptance criteria, effort estimates, and 8-layer verification checklists. Tasks group into integration units, then sequence into sprints. Testing infrastructure, CI/CD pipelines, design system tokens, enforcement gates, and quality baselines are established.
~6-12 hours
Task files Sprint plan Design tokens Test configs CI/CD templates 17 enforcement gates Context Bible
Gate 8 — Sprint plan approved
Gate 16 — Quality baseline set
8
// Task generation

Tasks generated: 147
Integration units: 12
Sprints planned: 6

// Per task:
  Acceptance criteria
  File plan (exact paths)
  Test requirements
  Effort estimate
  8-layer verification checklist

// Quality infrastructure
17 gates configured per path
DoD validator · 10-point scoring
Proof artifacts · auto-collected
// Business operations

Marketing launch plan, SEO, PLG
Legal privacy, ToS, DPA, EULA
Financial models, unit economics
BI dashboards, experiments
Support SLAs, runbooks, KB
Hiring roles, interview loops
Competitive battle cards, intel
Partner channel strategy

// Each step has depth minimums
// enforced by generators
17
Steps 17 - 28
Extend: Beyond Code
Marketing plans, legal documents, financial models, BI dashboards, SEO strategy, support platform setup, incident response runbooks, team hiring plans, competitive intelligence, partner strategy, and investor materials. Each step produces real files with enforced depth minimums.
~4-8 hours
Marketing plan Legal docs Financial model BI dashboards SEO strategy Support setup Investor deck
Steps 29 - 33
Harden
17 rounds of auditing, enhancement, depth verification, and expansion across everything produced so far. The Kit re-reads every spec, finds gaps, strengthens weak sections, cross-validates consistency, and produces an expansion plan for post-launch features.
~3-5 hours
Audit reports Enhancement logs Expansion plan Cross-ref validator
Gate 33 — Ready to build
29
// Hardening passes

Pass 1 Post-completion audit
Pass 2 Enhancement rounds
Pass 3 Depth verification
Pass 4 Deep dive audit
Pass 5 Expansion planning

// Per pass: every spec re-read,
// gaps found, sections strengthened,
// consistency cross-validated

✓ All specs above depth thresholds
✓ No phantom references
✓ Cross-doc consistency verified
✓ Expansion backlog prioritized
Act II

GSD writes your code

Step 34 transitions from planning to execution. The GSD engine reads every task file the Kit produced and builds your product sprint by sprint, with 8-gate verification on every task.

1

Read Task

Load task file, parse acceptance criteria, read referenced specs and the Context Bible for full project awareness.

2

Plan & Write

Plan the implementation against the spec, then write the code. Follow existing patterns from the architecture anchor.

3

Verify (8 gates)

Type check, tests, lint, build, design compliance, screenshots at 4 breakpoints, state completeness, integration check.

4

Prove & Advance

Collect proof artifacts (console output, screenshots, test reports). Update state files. Move to next task.

// GSD execution modes

Parallel GSD (/parallel-gsd)
  One agent per service, each in its own git worktree
  Lead agent coordinates cross-service integration
  Zero merge conflicts — worktrees are isolated copies

Sequential GSD (/gsd)
  Single agent processes tasks in sprint order
  20-40 tasks per session
  Good for smaller projects or when order matters

Autopilot GSD (/gsd-autopilot)
  Fully autonomous — pauses only at session boundaries
  Writes .kit/state.json for external orchestration
  Can run overnight via kit-autopilot.sh

// On failure
Retry × 3 with automated fix attempts
BLOCKED after 3 failures + full diagnostic report

The Kit produces code. Steps 0-33 produce the blueprints: service specs, screen specs, API contracts, task files, sprint plans, design systems, testing strategies, and deployment configs. Step 34 onward is execution: the GSD engine reads those specs and writes working software, sprint by sprint, with mechanical quality enforcement at every step.

Act III

Ship, watch, collect

After the code is built and tests pass, the Kit handles deployment, monitoring setup, feedback collection, and support infrastructure. Three steps take you from "tests pass" to "product live with monitoring."

Step 35
Deploy
Auto-detect deploy target (Vercel, Railway, Fly, Docker). Resolve CI/CD templates. Run go-live checklist. Deploy. Verify health endpoint.
→
Step 36
Monitor
Scaffold Sentry error tracking, analytics, uptime checks, and alerting rules. Connect health endpoints to monitoring.
→
Step 37
Collect
Set up feedback widgets, NPS surveys, knowledge base, support pipeline, and SLA definitions. Build triage routing.
Act IV

The autonomous loop

Step 38 closes the loop. Signals from monitoring and feedback drive automatic fixes, sprint planning, and iteration. The product improves itself.

Lifecycle Engine
Build
→
Ship
→
Watch
→
Collect
→
Loop
↳ Loop feeds back into Build. The cycle repeats autonomously.
Detach at any point and manage manually.
// Signal-driven iteration

bug_report → auto-triage → fix → test → deploy → verify
feedback   → categorize → prioritize → sprint backlog
metrics    → threshold check → alert → investigate
uptime     → health check fail → page → runbook
NPS drop   → feedback correlation → root cause → sprint

// The loop persists to
.lifecycle/signals/ — incoming events
.lifecycle/actions/ — responses taken
.lifecycle/history/ — decision log
Timeline

What happens when

Realistic time estimates for a Standard path project. Express path compresses this significantly; Full path extends it.

Phase Steps Time You Do Kit / GSD Does
Setup 0 - 0.5 ~30 min Approve path Install ecosystem, detect maturity, route to path
Discovery 1 - 2 3-6 hrs Answer intake questions Build CONFIG, verify versions, brainstorm features
Research 3 2-4 hrs Review verdict 10-round tribunal, 60-100 research files
Design 4 - 7 3-6 hrs Approve specs Service specs, screen specs, API contracts, DB schema
Plan 8 - 16 6-12 hrs Approve sprint plan Task files, sprints, design system, quality gates, CI/CD
Extend 17 - 28 4-8 hrs Pick what applies Marketing, legal, financial, BI, SEO, ops, hiring
Harden 29 - 33 3-5 hrs Review summaries Audit, enhance, deepen, expand all documentation
Build 34 Variable Choose execution mode GSD writes code sprint by sprint, 8-gate verification
Ship 35 ~30 min Review deploy config CI/CD resolution, go-live checklist, deploy, smoke test
Watch 36 ~30 min Confirm monitoring Sentry, analytics, uptime, alerting
Collect 37 ~1 hr Review feedback setup Feedback widgets, NPS, KB, support pipeline, SLAs
Loop 38 Ongoing Confirm autonomous mode Signal aggregation, auto-fix, sprint planning, iteration

Session boundaries. This process is designed for multi-session execution. Six session boundaries mark safe stopping points where all context is persisted to files. A new Claude Code conversation can pick up exactly where the last one left off by reading the session context manifest and handoff file.