@bhargavvc/sdd-cc 1.30.1 → 1.42.3

package/README.md

@@ -1,20 +1,20 @@
 <div align="center">
 
-# GET SHIT DONE
+# SPEC-DRIVEN DEVELOPMENT
 
 **English** · [Português](README.pt-BR.md) · [简体中文](README.zh-CN.md) · [日本語](README.ja-JP.md) · [한국어](README.ko-KR.md)
 
-**A light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code, OpenCode, Gemini CLI, Codex, Copilot, Cursor, Windsurf, and Antigravity.**
+**A light-weight meta-prompting, context engineering, and spec-driven development system for Claude Code, OpenCode, Gemini CLI, Kilo, Codex, Copilot, Cursor, Windsurf, and more.**
 
-**Solves context rot — the quality degradation that happens as Claude fills its context window.**
+**Solves context rot — the quality degradation that happens as your AI fills its context window.**
 
 [![npm version](https://img.shields.io/npm/v/@bhargavvc/sdd-cc?style=for-the-badge&logo=npm&logoColor=white&color=CB3837)](https://www.npmjs.com/package/@bhargavvc/sdd-cc)
 [![npm downloads](https://img.shields.io/npm/dm/@bhargavvc/sdd-cc?style=for-the-badge&logo=npm&logoColor=white&color=CB3837)](https://www.npmjs.com/package/@bhargavvc/sdd-cc)
-[![Tests](https://img.shields.io/github/actions/workflow/status/gsd-build/sdd/test.yml?branch=main&style=for-the-badge&logo=github&label=Tests)](https://github.com/gsd-build/sdd/actions/workflows/test.yml)
-[![Discord](https://img.shields.io/badge/Discord-Join-5865F2?style=for-the-badge&logo=discord&logoColor=white)](https://discord.gg/sdd)
+[![Tests](https://img.shields.io/github/actions/workflow/status/bhargavvc/sdd-cc/test.yml?branch=main&style=for-the-badge&logo=github&label=Tests)](https://github.com/bhargavvc/sdd-cc/actions/workflows/test.yml)
+[![Discord](https://img.shields.io/badge/Discord-Join-5865F2?style=for-the-badge&logo=discord&logoColor=white)](https://discord.gg/mYgfVNfA2r)
 [![X (Twitter)](https://img.shields.io/badge/X-@sdd__foundation-000000?style=for-the-badge&logo=x&logoColor=white)](https://x.com/sdd_foundation)
 [![$SDD Token](https://img.shields.io/badge/$SDD-Dexscreener-1C1C1C?style=for-the-badge&logo=data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMjQiIGhlaWdodD0iMjQiIHZpZXdCb3g9IjAgMCAyNCAyNCIgZmlsbD0ibm9uZSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48Y2lyY2xlIGN4PSIxMiIgY3k9IjEyIiByPSIxMCIgZmlsbD0iIzAwRkYwMCIvPjwvc3ZnPg==&logoColor=00FF00)](https://dexscreener.com/solana/dwudwjvan7bzkw9zwlbyv6kspdlvhwzrqy6ebk8xzxkv)
-[![GitHub stars](https://img.shields.io/github/stars/gsd-build/sdd?style=for-the-badge&logo=github&color=181717)](https://github.com/gsd-build/sdd)
+[![GitHub stars](https://img.shields.io/github/stars/bhargavvc/sdd-cc?style=for-the-badge&logo=github&color=181717)](https://github.com/bhargavvc/sdd-cc)
 [![License](https://img.shields.io/badge/license-MIT-blue?style=for-the-badge)](LICENSE)
 
 <br>
@@ -41,793 +41,217 @@ npx @bhargavvc/sdd-cc@latest
 
 **Trusted by engineers at Amazon, Google, Shopify, and Webflow.**
 
-[Why I Built This](#why-i-built-this) · [How It Works](#how-it-works) · [Commands](#commands) · [Why It Works](#why-it-works) · [User Guide](docs/USER-GUIDE.md)
-
 </div>
 
 ---
 
+> [!IMPORTANT]
+> **Returning to SDD?**
+>
+> Run `/sdd-map-codebase` to re-index your codebase, then `/sdd-new-project` to rebuild SDD's planning context. Your code is fine — SDD just needs its context rebuilt. See the [CHANGELOG](CHANGELOG.md) for what's new.
+
+---
+
 ## Why I Built This
 
 I'm a solo developer. I don't write code — Claude Code does.
 
-Other spec-driven development tools exist; BMAD, Speckit... But they all seem to make things way more complicated than they need to be (sprint ceremonies, story points, stakeholder syncs, retrospectives, Jira workflows) or lack real big picture understanding of what you're building. I'm not a 50-person software company. I don't want to play enterprise theater. I'm just a creative person trying to build great things that work.
+Other spec-driven tools exist, but they're all built for 50-person engineering orgs — sprint ceremonies, story points, stakeholder syncs, Jira workflows. I'm not that. I'm a creative person trying to build great things consistently.
 
 So I built SDD. The complexity is in the system, not in your workflow. Behind the scenes: context engineering, XML prompt formatting, subagent orchestration, state management. What you see: a few commands that just work.
 
 The system gives Claude everything it needs to do the work *and* verify it. I trust the workflow. It just does a good job.
 
-That's what this is. No enterprise roleplay bullshit. Just an incredibly effective system for building cool stuff consistently using Claude Code.
-
 — **TÂCHES**
 
 ---
 
-Vibecoding has a bad reputation. You describe what you want, AI generates code, and you get inconsistent garbage that falls apart at scale.
-
-SDD fixes that. It's the context engineering layer that makes Claude Code reliable. Describe your idea, let the system extract everything it needs to know, and let Claude Code get to work.
-
----
-
-## Who This Is For
-
-People who want to describe what they want and have it built correctly — without pretending they're running a 50-person engineering org.
+## How It Works
 
----
+The loop is six commands. Each one does exactly one thing.
 
-## Getting Started
+### 1. Initialize
 
 ```bash
-npx @bhargavvc/sdd-cc@latest
+/sdd-new-project
 ```
 
-The installer prompts you to choose:
-1. **Runtime** — Claude Code, OpenCode, Gemini, Codex, Copilot, Cursor, Windsurf, Antigravity, or all (interactive multi-select — pick multiple runtimes in a single install session)
-2. **Location** — Global (all projects) or local (current project only)
-
-Verify with:
-- Claude Code / Gemini: `/sdd:help`
-- OpenCode: `/sdd-help`
-- Codex: `$sdd-help`
-- Copilot: `/sdd:help`
-- Antigravity: `/sdd:help`
+Questions → research → requirements → roadmap. You approve it, then you're ready to build.
 
-> [!NOTE]
-> Codex installation uses skills (`skills/sdd-*/SKILL.md`) rather than custom prompts.
+> **Already have code?** Run `/sdd-map-codebase` first. It analyzes your stack, architecture, and conventions so `/sdd-new-project` asks the right questions.
 
-### Staying Updated
-
-SDD evolves fast. Update periodically:
+### 2. Discuss
 
 ```bash
-npx @bhargavvc/sdd-cc@latest
+/sdd-discuss-phase 1
 ```
 
-<details>
-<summary><strong>Non-interactive Install (Docker, CI, Scripts)</strong></summary>
-
-```bash
-# Claude Code
-npx @bhargavvc/sdd-cc --claude --global   # Install to ~/.claude/
-npx @bhargavvc/sdd-cc --claude --local    # Install to ./.claude/
-
-# OpenCode (open source, free models)
-npx @bhargavvc/sdd-cc --opencode --global # Install to ~/.config/opencode/
+Your roadmap has a sentence per phase. That's not enough to build it the way *you* imagine it. Discuss captures your decisions before anything gets planned: layouts, API shapes, error handling, data structures — whatever gray areas exist for this specific phase.
 
-# Gemini CLI
-npx @bhargavvc/sdd-cc --gemini --global   # Install to ~/.gemini/
-
-# Codex (skills-first)
-npx @bhargavvc/sdd-cc --codex --global    # Install to ~/.codex/
-npx @bhargavvc/sdd-cc --codex --local     # Install to ./.codex/
-
-# Copilot (GitHub Copilot CLI)
-npx @bhargavvc/sdd-cc --copilot --global  # Install to ~/.github/
-npx @bhargavvc/sdd-cc --copilot --local   # Install to ./.github/
-
-# Cursor CLI
-npx @bhargavvc/sdd-cc --cursor --global      # Install to ~/.cursor/
-npx @bhargavvc/sdd-cc --cursor --local       # Install to ./.cursor/
-
-# Windsurf (Codeium, VS Code-based)
-npx @bhargavvc/sdd-cc --windsurf --global    # Install to ~/.windsurf/
-npx @bhargavvc/sdd-cc --windsurf --local     # Install to ./.windsurf/
-
-# Antigravity (Google, skills-first, Gemini-based)
-npx @bhargavvc/sdd-cc --antigravity --global # Install to ~/.gemini/antigravity/
-npx @bhargavvc/sdd-cc --antigravity --local  # Install to ./.agent/
-
-# All runtimes
-npx @bhargavvc/sdd-cc --all --global      # Install to all directories
-```
+The output feeds directly into research and planning. Skip it, get reasonable defaults. Use it, get your vision.
 
-Use `--global` (`-g`) or `--local` (`-l`) to skip the location prompt.
-Use `--claude`, `--opencode`, `--gemini`, `--codex`, `--copilot`, `--cursor`, `--windsurf`, `--antigravity`, or `--all` to skip the runtime prompt.
-Use `--sdk` to also install the SDD SDK CLI (`sdd-sdk`) for headless autonomous execution.
-
-</details>
-
-<details>
-<summary><strong>Development Installation</strong></summary>
-
-Clone the repository and run the installer locally:
+### 3. Plan
 
 ```bash
-git clone https://github.com/gsd-build/sdd.git
-cd sdd
-node bin/install.js --claude --local
+/sdd-plan-phase 1
 ```
 
-Installs to `./.claude/` for testing modifications before contributing.
-
-</details>
+Research → plan → verify, in a loop until the plans pass. Each plan is small enough to execute in a fresh context window.
 
-### Recommended: Skip Permissions Mode
-
-SDD is designed for frictionless automation. Run Claude Code with:
+### 4. Execute
 
 ```bash
-claude --dangerously-skip-permissions
-```
-
-> [!TIP]
-> This is how SDD is intended to be used — stopping to approve `date` and `git commit` 50 times defeats the purpose.
-
-<details>
-<summary><strong>Alternative: Granular Permissions</strong></summary>
-
-If you prefer not to use that flag, add this to your project's `.claude/settings.json`:
-
-```json
-{
-  "permissions": {
-    "allow": [
-      "Bash(date:*)",
-      "Bash(echo:*)",
-      "Bash(cat:*)",
-      "Bash(ls:*)",
-      "Bash(mkdir:*)",
-      "Bash(wc:*)",
-      "Bash(head:*)",
-      "Bash(tail:*)",
-      "Bash(sort:*)",
-      "Bash(grep:*)",
-      "Bash(tr:*)",
-      "Bash(git add:*)",
-      "Bash(git commit:*)",
-      "Bash(git status:*)",
-      "Bash(git log:*)",
-      "Bash(git diff:*)",
-      "Bash(git tag:*)"
-    ]
-  }
-}
-```
-
-</details>
-
----
-
-## How It Works
-
-> **Already have code?** Run `/sdd:map-codebase` first. It spawns parallel agents to analyze your stack, architecture, conventions, and concerns. Then `/sdd:new-project` knows your codebase — questions focus on what you're adding, and planning automatically loads your patterns.
-
-### 1. Initialize Project
-
-```
-/sdd:new-project
-```
-
-One command, one flow. The system:
-
-1. **Questions** — Asks until it understands your idea completely (goals, constraints, tech preferences, edge cases)
-2. **Research** — Spawns parallel agents to investigate the domain (optional but recommended)
-3. **Requirements** — Extracts what's v1, v2, and out of scope
-4. **Roadmap** — Creates phases mapped to requirements
-
-You approve the roadmap. Now you're ready to build.
-
-**Creates:** `PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md`, `.planning/research/`
-
----
-
-### 2. Discuss Phase
-
-```
-/sdd:discuss-phase 1
-```
-
-**This is where you shape the implementation.**
-
-Your roadmap has a sentence or two per phase. That's not enough context to build something the way *you* imagine it. This step captures your preferences before anything gets researched or planned.
-
-The system analyzes the phase and identifies gray areas based on what's being built:
-
-- **Visual features** → Layout, density, interactions, empty states
-- **APIs/CLIs** → Response format, flags, error handling, verbosity
-- **Content systems** → Structure, tone, depth, flow
-- **Organization tasks** → Grouping criteria, naming, duplicates, exceptions
-
-For each area you select, it asks until you're satisfied. The output — `CONTEXT.md` — feeds directly into the next two steps:
-
-1. **Researcher reads it** — Knows what patterns to investigate ("user wants card layout" → research card component libraries)
-2. **Planner reads it** — Knows what decisions are locked ("infinite scroll decided" → plan includes scroll handling)
-
-The deeper you go here, the more the system builds what you actually want. Skip it and you get reasonable defaults. Use it and you get *your* vision.
-
-**Creates:** `{phase_num}-CONTEXT.md`
-
-> **Assumptions Mode:** Prefer codebase analysis over questions? Set `workflow.discuss_mode` to `assumptions` in `/sdd:settings`. The system reads your code, surfaces what it would do and why, and only asks you to correct what's wrong. See [Discuss Mode](docs/workflow-discuss-mode.md).
-
----
-
-### 3. Plan Phase
-
-```
-/sdd:plan-phase 1
-```
-
-The system:
-
-1. **Researches** — Investigates how to implement this phase, guided by your CONTEXT.md decisions
-2. **Plans** — Creates 2-3 atomic task plans with XML structure
-3. **Verifies** — Checks plans against requirements, loops until they pass
-
-Each plan is small enough to execute in a fresh context window. No degradation, no "I'll be more concise now."
-
-**Creates:** `{phase_num}-RESEARCH.md`, `{phase_num}-{N}-PLAN.md`
-
----
-
-### 4. Execute Phase
-
-```
-/sdd:execute-phase 1
-```
-
-The system:
-
-1. **Runs plans in waves** — Parallel where possible, sequential when dependent
-2. **Fresh context per plan** — 200k tokens purely for implementation, zero accumulated garbage
-3. **Commits per task** — Every task gets its own atomic commit
-4. **Verifies against goals** — Checks the codebase delivers what the phase promised
-
-Walk away, come back to completed work with clean git history.
-
-**How Wave Execution Works:**
-
-Plans are grouped into "waves" based on dependencies. Within each wave, plans run in parallel. Waves run sequentially.
-
-```
-┌────────────────────────────────────────────────────────────────────┐
-│  PHASE EXECUTION                                                   │
-├────────────────────────────────────────────────────────────────────┤
-│                                                                    │
-│  WAVE 1 (parallel)          WAVE 2 (parallel)          WAVE 3      │
-│  ┌─────────┐ ┌─────────┐    ┌─────────┐ ┌─────────┐    ┌─────────┐ │
-│  │ Plan 01 │ │ Plan 02 │ →  │ Plan 03 │ │ Plan 04 │ →  │ Plan 05 │ │
-│  │         │ │         │    │         │ │         │    │         │ │
-│  │ User    │ │ Product │    │ Orders  │ │ Cart    │    │ Checkout│ │
-│  │ Model   │ │ Model   │    │ API     │ │ API     │    │ UI      │ │
-│  └─────────┘ └─────────┘    └─────────┘ └─────────┘    └─────────┘ │
-│       │           │              ↑           ↑              ↑      │
-│       └───────────┴──────────────┴───────────┘              │      │
-│              Dependencies: Plan 03 needs Plan 01            │      │
-│                          Plan 04 needs Plan 02              │      │
-│                          Plan 05 needs Plans 03 + 04        │      │
-│                                                                    │
-└────────────────────────────────────────────────────────────────────┘
-```
-
-**Why waves matter:**
-- Independent plans → Same wave → Run in parallel
-- Dependent plans → Later wave → Wait for dependencies
-- File conflicts → Sequential plans or same plan
-
-This is why "vertical slices" (Plan 01: User feature end-to-end) parallelize better than "horizontal layers" (Plan 01: All models, Plan 02: All APIs).
-
-**Creates:** `{phase_num}-{N}-SUMMARY.md`, `{phase_num}-VERIFICATION.md`
-
----
-
-### 5. Verify Work
-
-```
-/sdd:verify-work 1
-```
-
-**This is where you confirm it actually works.**
-
-Automated verification checks that code exists and tests pass. But does the feature *work* the way you expected? This is your chance to use it.
-
-The system:
-
-1. **Extracts testable deliverables** — What you should be able to do now
-2. **Walks you through one at a time** — "Can you log in with email?" Yes/no, or describe what's wrong
-3. **Diagnoses failures automatically** — Spawns debug agents to find root causes
-4. **Creates verified fix plans** — Ready for immediate re-execution
-
-If everything passes, you move on. If something's broken, you don't manually debug — you just run `/sdd:execute-phase` again with the fix plans it created.
-
-**Creates:** `{phase_num}-UAT.md`, fix plans if issues found
-
----
-
-### 6. Repeat → Ship → Complete → Next Milestone
-
-```
-/sdd:discuss-phase 2
-/sdd:plan-phase 2
-/sdd:execute-phase 2
-/sdd:verify-work 2
-/sdd:ship 2                  # Create PR from verified work
-...
-/sdd:complete-milestone
-/sdd:new-milestone
+/sdd-execute-phase 1
 ```
 
-Or let SDD figure out the next step automatically:
+Plans run in parallel waves. Each executor gets a fresh 200k-token context. Each task gets its own atomic commit. Walk away, come back to completed work with a clean git history.
 
-```
-/sdd:next                    # Auto-detect and run next step
-```
-
-Loop **discuss → plan → execute → verify → ship** until milestone complete.
-
-If you want faster intake during discussion, use `/sdd:discuss-phase <n> --batch` to answer a small grouped set of questions at once instead of one-by-one.
-
-Each phase gets your input (discuss), proper research (plan), clean execution (execute), and human verification (verify). Context stays fresh. Quality stays high.
-
-When all phases are done, `/sdd:complete-milestone` archives the milestone and tags the release.
-
-Then `/sdd:new-milestone` starts the next version — same flow as `new-project` but for your existing codebase. You describe what you want to build next, the system researches the domain, you scope requirements, and it creates a fresh roadmap. Each milestone is a clean cycle: define → build → ship.
+Your main context window stays at 30–40%. The work happens in the subagents.
 
----
-
-### Quick Mode
+### 5. Verify
 
+```bash
+/sdd-verify-work 1
 ```
-/sdd:quick
-```
-
-**For ad-hoc tasks that don't need full planning.**
-
-Quick mode gives you SDD guarantees (atomic commits, state tracking) with a faster path:
-
-- **Same agents** — Planner + executor, same quality
-- **Skips optional steps** — No research, no plan checker, no verifier by default
-- **Separate tracking** — Lives in `.planning/quick/`, not phases
 
-**`--discuss` flag:** Lightweight discussion to surface gray areas before planning.
+Walk through what was built. Anything broken gets a diagnosed fix plan — ready for immediate re-execution. You don't debug manually; you just run execute again.
 
-**`--research` flag:** Spawns a focused researcher before planning. Investigates implementation approaches, library options, and pitfalls. Use when you're unsure how to approach a task.
+### 6. Repeat → Ship
 
-**`--full` flag:** Enables plan-checking (max 2 iterations) and post-execution verification.
-
-Flags are composable: `--discuss --research --full` gives discussion + research + plan-checking + verification.
-
-```
-/sdd:quick
-> What do you want to do? "Add dark mode toggle to settings"
+```bash
+/sdd-ship 1
+/sdd-complete-milestone
+/sdd-new-milestone
 ```
 
-**Creates:** `.planning/quick/001-add-dark-mode-toggle/PLAN.md`, `SUMMARY.md`
+Loop discuss → plan → execute → verify → ship until the milestone is done. Then archive, tag, and start the next one fresh.
 
 ---
 
-## Why It Works
+## Getting Started
 
-### Context Engineering
-
-Claude Code is incredibly powerful *if* you give it the context it needs. Most people don't.
-
-SDD handles it for you:
-
-| File | What it does |
-|------|--------------|
-| `PROJECT.md` | Project vision, always loaded |
-| `research/` | Ecosystem knowledge (stack, features, architecture, pitfalls) |
-| `REQUIREMENTS.md` | Scoped v1/v2 requirements with phase traceability |
-| `ROADMAP.md` | Where you're going, what's done |
-| `STATE.md` | Decisions, blockers, position — memory across sessions |
-| `PLAN.md` | Atomic task with XML structure, verification steps |
-| `SUMMARY.md` | What happened, what changed, committed to history |
-| `todos/` | Captured ideas and tasks for later work |
-| `threads/` | Persistent context threads for cross-session work |
-| `seeds/` | Forward-looking ideas that surface at the right milestone |
-
-Size limits based on where Claude's quality degrades. Stay under, get consistent excellence.
-
-### XML Prompt Formatting
-
-Every plan is structured XML optimized for Claude:
-
-```xml
-<task type="auto">
-  <name>Create login endpoint</name>
-  <files>src/app/api/auth/login/route.ts</files>
-  <action>
-    Use jose for JWT (not jsonwebtoken - CommonJS issues).
-    Validate credentials against users table.
-    Return httpOnly cookie on success.
-  </action>
-  <verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify>
-  <done>Valid credentials return cookie, invalid return 401</done>
-</task>
+```bash
+npx @bhargavvc/sdd-cc@latest
 ```
 
-Precise instructions. No guessing. Verification built in.
-
-### Multi-Agent Orchestration
-
-Every stage uses the same pattern: a thin orchestrator spawns specialized agents, collects results, and routes to the next step.
-
-| Stage | Orchestrator does | Agents do |
-|-------|------------------|-----------|
-| Research | Coordinates, presents findings | 4 parallel researchers investigate stack, features, architecture, pitfalls |
-| Planning | Validates, manages iteration | Planner creates plans, checker verifies, loop until pass |
-| Execution | Groups into waves, tracks progress | Executors implement in parallel, each with fresh 200k context |
-| Verification | Presents results, routes next | Verifier checks codebase against goals, debuggers diagnose failures |
-
-The orchestrator never does heavy lifting. It spawns agents, waits, integrates results.
-
-**The result:** You can run an entire phase — deep research, multiple plans created and verified, thousands of lines of code written across parallel executors, automated verification against goals — and your main context window stays at 30-40%. The work happens in fresh subagent contexts. Your session stays fast and responsive.
-
-### Atomic Git Commits
-
-Each task gets its own commit immediately after completion:
+The installer prompts for your runtime (Claude Code, OpenCode, Gemini CLI, Kilo, Codex, Copilot, Cursor, Windsurf, and more) and whether to install globally or locally.
 
 ```bash
-abc123f docs(08-02): complete user registration plan
-def456g feat(08-02): add email confirmation flow
-hij789k feat(08-02): implement password hashing
-lmn012o feat(08-02): create registration endpoint
+claude --dangerously-skip-permissions
 ```
 
-> [!NOTE]
-> **Benefits:** Git bisect finds exact failing task. Each task independently revertable. Clear history for Claude in future sessions. Better observability in AI-automated workflow.
-
-Every commit is surgical, traceable, and meaningful.
-
-### Modular by Design
+SDD is built for frictionless automation. Skip-permissions is how it's intended to run.
 
-- Add phases to current milestone
-- Insert urgent work between phases
-- Complete milestones and start fresh
-- Adjust plans without rebuilding everything
+Install only the skills you need with `--profile=core` (six core-loop skills), `--profile=standard` (core + phase management), or the default full install. Profiles compose: `--profile=core,audit`. `--minimal` is an alias for `--profile=core`. See **[docs/USER-GUIDE.md](docs/USER-GUIDE.md)** for the full walkthrough, non-interactive install flags for all 15 runtimes, and permissions configuration. See [ADR-0011](docs/adr/0011-skill-surface-budget-module.md) for the profile model and runtime surface control.
 
-You're never locked in. The system adapts.
+Current release highlights are in [docs/RELEASE-v1.42.1.md](docs/RELEASE-v1.42.1.md): package legitimacy checks, safer installer migrations, runtime surface control, custom ship PR sections, reviewer defaults, fallow structural review, and quota-aware execution recovery.
 
 ---
 
 ## Commands
 
-### Core Workflow
-
-| Command | What it does |
-|---------|--------------|
-| `/sdd:new-project [--auto]` | Full initialization: questions → research → requirements → roadmap |
-| `/sdd:discuss-phase [N] [--auto] [--analyze]` | Capture implementation decisions before planning (`--analyze` adds trade-off analysis) |
-| `/sdd:plan-phase [N] [--auto] [--reviews]` | Research + plan + verify for a phase (`--reviews` loads codebase review findings) |
-| `/sdd:execute-phase <N>` | Execute all plans in parallel waves, verify when complete |
-| `/sdd:verify-work [N]` | Manual user acceptance testing ¹ |
-| `/sdd:ship [N] [--draft]` | Create PR from verified phase work with auto-generated body |
-| `/sdd:next` | Automatically advance to the next logical workflow step |
-| `/sdd:fast <text>` | Inline trivial tasks — skips planning entirely, executes immediately |
-| `/sdd:audit-milestone` | Verify milestone achieved its definition of done |
-| `/sdd:complete-milestone` | Archive milestone, tag release |
-| `/sdd:new-milestone [name]` | Start next version: questions → research → requirements → roadmap |
-| `/sdd:forensics [desc]` | Post-mortem investigation of failed workflow runs (diagnoses stuck loops, missing artifacts, git anomalies) |
-| `/sdd:milestone-summary [version]` | Generate comprehensive project summary for team onboarding and review |
-
-### Workstreams
-
-| Command | What it does |
-|---------|--------------|
-| `/sdd:workstreams list` | Show all workstreams and their status |
-| `/sdd:workstreams create <name>` | Create a namespaced workstream for parallel milestone work |
-| `/sdd:workstreams switch <name>` | Switch active workstream |
-| `/sdd:workstreams complete <name>` | Complete and merge a workstream |
-
-### Multi-Project Workspaces
-
-| Command | What it does |
-|---------|--------------|
-| `/sdd:new-workspace` | Create isolated workspace with repo copies (worktrees or clones) |
-| `/sdd:list-workspaces` | Show all SDD workspaces and their status |
-| `/sdd:remove-workspace` | Remove workspace and clean up worktrees |
-
-### UI Design
-
-| Command | What it does |
-|---------|--------------|
-| `/sdd:ui-phase [N]` | Generate UI design contract (UI-SPEC.md) for frontend phases |
-| `/sdd:ui-review [N]` | Retroactive 6-pillar visual audit of implemented frontend code |
-
-### Navigation
-
-| Command | What it does |
-|---------|--------------|
-| `/sdd:progress` | Where am I? What's next? |
-| `/sdd:next` | Auto-detect state and run the next step |
-| `/sdd:help` | Show all commands and usage guide |
-| `/sdd:update` | Update SDD with changelog preview |
-| `/sdd:join-discord` | Join the SDD Discord community |
-| `/sdd:manager` | Interactive command center for managing multiple phases |
-
-### Brownfield
-
-| Command | What it does |
-|---------|--------------|
-| `/sdd:map-codebase [area]` | Analyze existing codebase before new-project |
-
-### Phase Management
+The main loop:
 
 | Command | What it does |
 |---------|--------------|
-| `/sdd:add-phase` | Append phase to roadmap |
-| `/sdd:insert-phase [N]` | Insert urgent work between phases |
-| `/sdd:remove-phase [N]` | Remove future phase, renumber |
-| `/sdd:list-phase-assumptions [N]` | See Claude's intended approach before planning |
-| `/sdd:plan-milestone-gaps` | Create phases to close gaps from audit |
+| `/sdd-new-project` | Questions → research → requirements → roadmap |
+| `/sdd-discuss-phase [N]` | Capture implementation decisions before planning |
+| `/sdd-plan-phase [N]` | Research + plan + verify |
+| `/sdd-execute-phase <N>` | Execute plans in parallel waves |
+| `/sdd-verify-work [N]` | Manual acceptance testing |
+| `/sdd-ship [N]` | Create PR from verified phase work |
+| `/sdd-progress --next` | Auto-detect and run the next step |
+| `/sdd-complete-milestone` | Archive milestone and tag release |
+| `/sdd-new-milestone` | Start next version |
+| `/sdd:surface` | Enable/disable skill clusters at runtime without reinstall |
+
+For ad-hoc tasks, autonomous mode, codebase analysis, forensics, and the full command surface — see **[docs/COMMANDS.md](docs/COMMANDS.md)**.
 
-### Session
-
-| Command | What it does |
-|---------|--------------|
-| `/sdd:pause-work` | Create handoff when stopping mid-phase (writes HANDOFF.json) |
-| `/sdd:resume-work` | Restore from last session |
-| `/sdd:session-report` | Generate session summary with work performed and outcomes |
-
-### Workstreams
-
-| Command | What it does |
-|---------|--------------|
-| `/sdd:workstreams` | Manage parallel workstreams (list, create, switch, status, progress, complete) |
+---
 
-### Code Quality
+## Why It Works
 
-| Command | What it does |
-|---------|--------------|
-| `/sdd:review` | Cross-AI peer review of current phase or branch |
-| `/sdd:pr-branch` | Create clean PR branch filtering `.planning/` commits |
-| `/sdd:audit-uat` | Audit verification debt — find phases missing UAT |
+Three things most AI-coding setups get wrong:
 
-### Backlog & Threads
+**1. Context bloat.** As a session grows, quality degrades. SDD keeps your main context clean by doing the heavy work in fresh subagent contexts. Researchers, planners, and executors each start fresh with exactly what they need.
 
-| Command | What it does |
-|---------|--------------|
-| `/sdd:plant-seed <idea>` | Capture forward-looking ideas with trigger conditions — surfaces at the right milestone |
-| `/sdd:add-backlog <desc>` | Add idea to backlog parking lot (999.x numbering, outside active sequence) |
-| `/sdd:review-backlog` | Review and promote backlog items to active milestone or remove stale entries |
-| `/sdd:thread [name]` | Persistent context threads — lightweight cross-session knowledge for work spanning multiple sessions |
+**2. No shared memory.** SDD maintains structured artifacts that survive session boundaries: `PROJECT.md` (vision), `REQUIREMENTS.md` (scope), `ROADMAP.md` (where you're going), `STATE.md` (current position and decisions), `CONTEXT.md` (per-phase implementation decisions). Every new session loads these and knows exactly where things stand.
 
-### Utilities
+**3. No verification.** Code that "runs" isn't code that "works." SDD's verify step walks you through what was built, diagnoses failures with dedicated debug agents, and generates fix plans before you declare a phase done.
 
-| Command | What it does |
-|---------|--------------|
-| `/sdd:settings` | Configure model profile and workflow agents |
-| `/sdd:set-profile <profile>` | Switch model profile (quality/balanced/budget/inherit) |
-| `/sdd:add-todo [desc]` | Capture idea for later |
-| `/sdd:check-todos` | List pending todos |
-| `/sdd:debug [desc]` | Systematic debugging with persistent state |
-| `/sdd:do <text>` | Route freeform text to the right SDD command automatically |
-| `/sdd:note <text>` | Zero-friction idea capture — append, list, or promote notes to todos |
-| `/sdd:quick [--full] [--discuss] [--research]` | Execute ad-hoc task with SDD guarantees (`--full` adds plan-checking and verification, `--discuss` gathers context first, `--research` investigates approaches before planning) |
-| `/sdd:health [--repair]` | Validate `.planning/` directory integrity, auto-repair with `--repair` |
-| `/sdd:stats` | Display project statistics — phases, plans, requirements, git metrics |
-| `/sdd:profile-user [--questionnaire] [--refresh]` | Generate developer behavioral profile from session analysis for personalized responses |
-
-<sup>¹ Contributed by reddit user OracleGreyBeard</sup>
+See **[docs/ARCHITECTURE.md](docs/ARCHITECTURE.md)** for how the multi-agent orchestration and context engineering work in detail.
 
 ---
 
 ## Configuration
 
-SDD stores project settings in `.planning/config.json`. Configure during `/sdd:new-project` or update later with `/sdd:settings`. For the full config schema, workflow toggles, git branching options, and per-agent model breakdown, see the [User Guide](docs/USER-GUIDE.md#configuration-reference).
-
-### Core Settings
-
-| Setting | Options | Default | What it controls |
-|---------|---------|---------|------------------|
-| `mode` | `yolo`, `interactive` | `interactive` | Auto-approve vs confirm at each step |
-| `granularity` | `coarse`, `standard`, `fine` | `standard` | Phase granularity — how finely scope is sliced (phases × plans) |
-
-### Model Profiles
-
-Control which Claude model each agent uses. Balance quality vs token spend.
-
-| Profile | Planning | Execution | Verification |
-|---------|----------|-----------|--------------|
-| `quality` | Opus | Opus | Sonnet |
-| `balanced` (default) | Opus | Sonnet | Sonnet |
-| `budget` | Sonnet | Sonnet | Haiku |
-| `inherit` | Inherit | Inherit | Inherit |
-
-Switch profiles:
-```
-/sdd:set-profile budget
-```
-
-Use `inherit` when using non-Anthropic providers (OpenRouter, local models) or to follow the current runtime model selection (e.g. OpenCode `/model`).
-
-Or configure via `/sdd:settings`.
-
-### Workflow Agents
-
-These spawn additional agents during planning/execution. They improve quality but add tokens and time.
-
-| Setting | Default | What it does |
-|---------|---------|--------------|
-| `workflow.research` | `true` | Researches domain before planning each phase |
-| `workflow.plan_check` | `true` | Verifies plans achieve phase goals before execution |
-| `workflow.verifier` | `true` | Confirms must-haves were delivered after execution |
-| `workflow.auto_advance` | `false` | Auto-chain discuss → plan → execute without stopping |
-| `workflow.research_before_questions` | `false` | Run research before discussion questions instead of after |
-| `workflow.discuss_mode` | `'discuss'` | Discussion mode: `discuss` (interview), `assumptions` (codebase-first) |
-| `workflow.skip_discuss` | `false` | Skip discuss-phase in autonomous mode |
-| `workflow.text_mode` | `false` | Text-only mode for remote sessions (no TUI menus) |
+Settings live in `.planning/config.json`. Configure during `/sdd-new-project` or update with `/sdd-settings`.
 
-Use `/sdd:settings` to toggle these, or override per-invocation:
-- `/sdd:plan-phase --skip-research`
-- `/sdd:plan-phase --skip-verify`
+Key dials:
 
-### Execution
+| Setting | What it controls |
+|---------|-----------------|
+| `mode` | `interactive` (confirm each step) or `yolo` (auto-approve) |
+| Model profiles | `quality` / `balanced` / `budget` — controls which model each agent uses |
+| `workflow.research` / `plan_check` / `verifier` | Toggle the quality agents that add tokens and time |
+| `parallelization.enabled` | Run independent plans simultaneously |
 
-| Setting | Default | What it controls |
-|---------|---------|------------------|
-| `parallelization.enabled` | `true` | Run independent plans simultaneously |
-| `planning.commit_docs` | `true` | Track `.planning/` in git |
-| `hooks.context_warnings` | `true` | Show context window usage warnings |
+Optional structural review: set `code_quality.fallow.enabled` to `true` to add a fallow pre-pass to `/sdd-code-review`. SDD writes `.planning/phases/<phase>/FALLOW.json` and surfaces a `Structural Findings (fallow)` section in `REVIEW.md`. Install with `npm install -D fallow@^2.70.0` (or system-wide via `cargo install fallow`; note that the Rust binary's JSON schema must match the documented v2.70+ contract — older versions may produce silent zero-finding output).
 
-### Agent Skills
+Package legitimacy checks are built into the research, planning, and execution path: recommended dependencies get audited, unverified packages require a human checkpoint, and failed installs stop instead of trying similarly named alternatives.
 
-Inject project-specific skills into subagents during execution.
-
-| Setting | Type | What it does |
-|---------|------|--------------|
-| `agent_skills.<agent_type>` | `string[]` | Paths to skill directories loaded into that agent type at spawn time |
-
-Skills are injected as `<agent_skills>` blocks in agent prompts, giving subagents access to project-specific knowledge.
-
-### Git Branching
-
-Control how SDD handles branches during execution.
-
-| Setting | Options | Default | What it does |
-|---------|---------|---------|--------------|
-| `git.branching_strategy` | `none`, `phase`, `milestone` | `none` | Branch creation strategy |
-| `git.phase_branch_template` | string | `sdd/phase-{phase}-{slug}` | Template for phase branches |
-| `git.milestone_branch_template` | string | `sdd/{milestone}-{slug}` | Template for milestone branches |
-
-**Strategies:**
-- **`none`** — Commits to current branch (default SDD behavior)
-- **`phase`** — Creates a branch per phase, merges at phase completion
-- **`milestone`** — Creates one branch for entire milestone, merges at completion
-
-At milestone completion, SDD offers squash merge (recommended) or merge with history.
+For the full configuration reference — all settings, git branching strategies, per-runtime model overrides, workstream config inheritance, agent skills injection — see **[docs/CONFIGURATION.md](docs/CONFIGURATION.md)**.
 
 ---
 
-## Security
+## Documentation
 
-### Built-in Security Hardening
-
-SDD includes defense-in-depth security since v1.27:
-
-- **Path traversal prevention** — All user-supplied file paths (`--text-file`, `--prd`) are validated to resolve within the project directory
-- **Prompt injection detection** — Centralized `security.cjs` module scans for injection patterns in user-supplied text before it enters planning artifacts
-- **PreToolUse prompt guard hook** — `sdd-prompt-guard` scans writes to `.planning/` for embedded injection vectors (advisory, not blocking)
-- **Safe JSON parsing** — Malformed `--fields` arguments are caught before they corrupt state
-- **Shell argument validation** — User text is sanitized before shell interpolation
-- **CI-ready injection scanner** — `prompt-injection-scan.test.cjs` scans all agent/workflow/command files for embedded injection vectors
-
-> [!NOTE]
-> Because SDD generates markdown files that become LLM system prompts, any user-controlled text flowing into planning artifacts is a potential indirect prompt injection vector. These protections are designed to catch such vectors at multiple layers.
-
-### Protecting Sensitive Files
-
-SDD's codebase mapping and analysis commands read files to understand your project. **Protect files containing secrets** by adding them to Claude Code's deny list:
-
-1. Open Claude Code settings (`.claude/settings.json` or global)
-2. Add sensitive file patterns to the deny list:
-
-```json
-{
-  "permissions": {
-    "deny": [
-      "Read(.env)",
-      "Read(.env.*)",
-      "Read(**/secrets/*)",
-      "Read(**/*credential*)",
-      "Read(**/*.pem)",
-      "Read(**/*.key)"
-    ]
-  }
-}
-```
-
-This prevents Claude from reading these files entirely, regardless of what commands you run.
-
-> [!IMPORTANT]
-> SDD includes built-in protections against committing secrets, but defense-in-depth is best practice. Deny read access to sensitive files as a first line of defense.
+| Doc | What's in it |
+|-----|-------------|
+| [User Guide](docs/USER-GUIDE.md) | End-to-end walkthrough, install options, all runtime flags, configuration reference |
+| [Commands](docs/COMMANDS.md) | Every command with flags and examples |
+| [Configuration](docs/CONFIGURATION.md) | Full config schema, model profiles, git branching |
+| [Architecture](docs/ARCHITECTURE.md) | How the multi-agent orchestration works |
+| [CLI Tools](docs/CLI-TOOLS.md) | `sdd-sdk query` and programmatic SDK dispatch seams |
+| [Features](docs/FEATURES.md) | Complete feature index |
+| [Changelog](CHANGELOG.md) | What changed in each release |
 
 ---
 
 ## Troubleshooting
 
-**Commands not found after install?**
-- Restart your runtime to reload commands/skills
-- Verify files exist in `~/.claude/commands/sdd/` (global) or `./.claude/commands/sdd/` (local)
-- For Codex, verify skills exist in `~/.codex/skills/sdd-*/SKILL.md` (global) or `./.codex/skills/sdd-*/SKILL.md` (local)
+**Commands not showing up?** Restart your runtime after install. SDD installs to `~/.claude/skills/sdd-*/` (Claude Code), `~/.codex/skills/sdd-*/` (Codex), or the equivalent for your runtime.
 
-**Commands not working as expected?**
-- Run `/sdd:help` to verify installation
-- Re-run `npx @bhargavvc/sdd-cc` to reinstall
-
-**Updating to the latest version?**
+**Something broken?** Re-run the installer — it's idempotent:
 ```bash
 npx @bhargavvc/sdd-cc@latest
 ```
 
-**Using Docker or containerized environments?**
-
-If file reads fail with tilde paths (`~/.claude/...`), set `CLAUDE_CONFIG_DIR` before installing:
+**Containers or Docker?** Set `CLAUDE_CONFIG_DIR` before installing to avoid tilde-expansion issues:
 ```bash
 CLAUDE_CONFIG_DIR=/home/youruser/.claude npx @bhargavvc/sdd-cc --global
 ```
-This ensures absolute paths are used instead of `~` which may not expand correctly in containers.
-
-### Uninstalling
 
-To remove SDD completely:
-
-```bash
-# Global installs
-npx @bhargavvc/sdd-cc --claude --global --uninstall
-npx @bhargavvc/sdd-cc --opencode --global --uninstall
-npx @bhargavvc/sdd-cc --gemini --global --uninstall
-npx @bhargavvc/sdd-cc --codex --global --uninstall
-npx @bhargavvc/sdd-cc --copilot --global --uninstall
-npx @bhargavvc/sdd-cc --cursor --global --uninstall
-npx @bhargavvc/sdd-cc --windsurf --global --uninstall
-npx @bhargavvc/sdd-cc --antigravity --global --uninstall
-
-# Local installs (current project)
-npx @bhargavvc/sdd-cc --claude --local --uninstall
-npx @bhargavvc/sdd-cc --opencode --local --uninstall
-npx @bhargavvc/sdd-cc --gemini --local --uninstall
-npx @bhargavvc/sdd-cc --codex --local --uninstall
-npx @bhargavvc/sdd-cc --copilot --local --uninstall
-npx @bhargavvc/sdd-cc --cursor --local --uninstall
-npx @bhargavvc/sdd-cc --windsurf --local --uninstall
-npx @bhargavvc/sdd-cc --antigravity --local --uninstall
-```
-
-This removes all SDD commands, agents, hooks, and settings while preserving your other configurations.
+Full troubleshooting and uninstall instructions in **[docs/USER-GUIDE.md](docs/USER-GUIDE.md#troubleshooting)**.
 
 ---
 
-## Community Ports
-
-OpenCode, Gemini CLI, and Codex are now natively supported via `npx @bhargavvc/sdd-cc`.
-
-These community ports pioneered multi-runtime support:
+## Community
 
-| Project | Platform | Description |
-|---------|----------|-------------|
-| [sdd-opencode](https://github.com/rokicool/sdd-opencode) | OpenCode | Original OpenCode adaptation |
-| sdd-gemini (archived) | Gemini CLI | Original Gemini adaptation by uberfuzzy |
+| Project | Platform |
+|---------|----------|
+| [sdd-opencode](https://github.com/rokicool/sdd-opencode) | Original OpenCode port |
+| [Discord](https://discord.gg/mYgfVNfA2r) | Community support |
 
 ---
 
 ## Star History
 
-<a href="https://star-history.com/#gsd-build/sdd&Date">
+<a href="https://star-history.com/#bhargavvc/sdd-cc&Date">
  <picture>
-   <source media="(prefers-color-scheme: dark)" srcset="https://api.star-history.com/svg?repos=gsd-build/sdd&type=Date&theme=dark" />
-   <source media="(prefers-color-scheme: light)" srcset="https://api.star-history.com/svg?repos=gsd-build/sdd&type=Date" />
-   <img alt="Star History Chart" src="https://api.star-history.com/svg?repos=gsd-build/sdd&type=Date" />
+   <source media="(prefers-color-scheme: dark)" srcset="https://api.star-history.com/svg?repos=bhargavvc/sdd-cc&type=Date&theme=dark" />
+   <source media="(prefers-color-scheme: light)" srcset="https://api.star-history.com/svg?repos=bhargavvc/sdd-cc&type=Date" />
+   <img alt="Star History Chart" src="https://api.star-history.com/svg?repos=bhargavvc/sdd-cc&type=Date" />
  </picture>
 </a>