the-startup

Ship faster. Ship better. Ship with The Agentic Startup.

Table of Contents

• 🤖 What is The Agentic Startup?
• 🚀 Quick Start
• 📖 The Complete Workflow
• 🎯 Which Skill Should I Use?
• 📦 Plugins
• 🎨 Output Styles
• 📊 Statusline
• 💡 Why The Agentic Startup?
• 🎯 Philosophy
• 📚 Documentation

New in v3: Agent Teams (experimental) — enable multi-agent collaboration where specialized agents coordinate and work together on complex tasks. The installer now offers to configure this automatically.

🤖 What is The Agentic Startup?

The Agentic Startup is a multi-agent AI framework that makes Claude Code work like a startup team. Create comprehensive specifications before coding, then execute with parallel specialist agents — expert developers, architects, and engineers working together to turn your ideas into shipped code.

10 slash commands across 3 phases. Specify first, then build with confidence.

Key Features:

• Spec-Driven Development — PRD → SDD → task plan → Code
• One Implementation Loop — /implement runs the plan's tasks through a barriered code→eval retry loop on Claude Code's dynamic-workflow runtime
• Parallel Agent Execution — Multiple specialists work simultaneously
• Quality Gates — Built-in validation at every stage
• Zero Configuration — Marketplace plugins, one-line install

Installation

Requirements: Claude Code v2.0+ with marketplace support

curl -fsSL https://raw.githubusercontent.com/rsmdt/the-startup/main/install.sh | sh

This installs the core plugins, configures the default output style, and sets up the statusline with a customizable config file.

Manual Installation

Start claude and run the following:

# Add The Agentic Startup marketplace
/plugin marketplace add rsmdt/the-startup

/plugin install start@the-startup  # Install the Start plugin (core workflows)
/plugin install team@the-startup   # (Optional) Install the Team plugin (specialized agents)

After installation:

# (Optional) Create project governance rules
/constitution                      # Auto-enforced during specify, implement, review

# Switch output styles anytime
/output-style "start:The Startup"   # High-energy, fast execution (default)
/output-style "start:The ScaleUp"   # Calm confidence, educational

🚀 Quick Start

Create a specification and implement it:

# Create a specification
/specify Add user authentication with OAuth support

# Execute the implementation
/implement 001

That's it! You're now using spec-driven development.

📖 The Complete Workflow

The Agentic Startup follows spec-driven development: comprehensive specifications before code, ensuring clarity and reducing rework.

All Skills at a Glance

┌──────────────────────────────────────────────────────────┐
│                    SETUP (optional)                      │
│                                                          │
│  /constitution ► Create project governance rules         │
│                  (auto-enforced in BUILD workflow)       │
└──────────────────────────────────────────────────────────┘
                            │
                            ▼
┌──────────────────────────────────────────────────────────┐
│                    BUILD (primary flow)                  │
│                                                          │
│  /specify ────► Create specs (Requirements + Solution + Plan) │
│      │           ↳ Plan = ordered task sequence          │
│      │           ↳ Constitution checked on SDD           │
│      ▼                                                   │
│  /validate ───► Check quality (3 Cs framework)           │
│      │           ↳ Constitution mode available           │
│      ▼                                                   │
│  /implement ──► Run the task loop (dynamic-workflow)     │
│      │           ↳ barriered code→eval retry per task    │
│      │           ↳ Constitution enforced                 │
│      ▼                                                   │
│  /test ───────► Run tests, enforce ownership             │
│      │           ↳ No "pre-existing" excuses             │
│      ▼                                                   │
│  /review ─────► Multi-agent code review                  │
│      │           ↳ Constitution compliance checked       │
│      ▼                                                   │
│  /document ───► Generate/sync documentation              │
└──────────────────────────────────────────────────────────┘
                            │
                            ▼
┌──────────────────────────────────────────────────────────┐
│                    MAINTAIN (as needed)                  │
│                                                          │
│  /analyze ────► Discover patterns & rules                │
│                                                          │
│  /refactor ───► Improve code (preserve behavior)         │
│                                                          │
│  /debug ──────► Fix bugs (root cause analysis)           │
└──────────────────────────────────────────────────────────┘

Step-by-Step Walkthrough

Step 1: Create Your Specification

/specify Add real-time notification system with WebSocket support

This creates a specification directory with one document in three parts plus its holdout scenarios:

.start/specs/001-notification-system/
├── spec.md                  # Requirements (what and why), Solution (how), Plan (phases + outcomes), Ledger
├── review.md                # Solution review report
└── .tracker/                 # The implementation tasks /implement runs
    ├── <phase + slice tasks> # phase = one evaluated outcome; slice = one deliverable, code brief in its body
    └── <scenario tasks>      # holdout acceptance evidence, per slice

The spec cycle may take 15-30 minutes. Claude will research your codebase, ask clarifying questions, and produce comprehensive documents. The process naturally involves multiple back-and-forth exchanges.

The plan: a narrative + tracker tasks

The Plan part of spec.md is the high-level approach — phases and their achievable outcomes, plus a link to the tracker. The operational units are tasks in the spec's tracker (.start/specs/NNN/.tracker/, via task.js): one phase task per plan phase and, under it, one slice task per vertical deliverable, whose body correlates:

Its acceptance scenarios are separate scenario child tasks (holdout evidence — the eval agent reads them, the code agent never does). Slices declare dependencies (--depends-on) — that graph is the whole parallelization contract. There is no tier or strategy to choose: a 1-slice plan is a short loop, a 40-slice plan fans out. You always invoke /specify and /implement; the spec sub-skills (specify-requirements, specify-solution, specify-plan, specify-meta) are dispatched internally.

Step 2: Handle Context Limits (Resume Pattern)

Large specifications may approach Claude's context window limits. When this happens:

# Start a new conversation and resume where you left off
/specify 001

The resume pattern:

• Pass the spec ID (e.g., 001) instead of a description
• Claude reads the existing spec files and continues from there
• You can reset context as many times as needed
• Each document (PRD → SDD → PLAN) can be completed in separate sessions if needed

Pro tip: If Claude suggests "you may want to reset context", do it! The quality of output improves with fresh context.

Step 3: Validate Before Implementation

/validate 001

This quality gate checks:

• Completeness - All sections filled, no missing details
• Consistency - No contradictions between documents
• Correctness - Requirements are testable and achievable

Validation is advisory—it provides recommendations but doesn't block you.

Step 4: Execute the Implementation

/implement 001

Claude will:

1. Read the spec's slice tasks from the tracker and topologically sort them by their --depends-on edges
2. Author and run one dynamic workflow — each slice driven through a barriered code→eval loop (a code agent builds it reading the slice task, blind to its scenarios; an eval agent proves it against the slice's scenario child tasks, blind to the slice and the source; failures retry until the satisfaction threshold)
3. Run independent slices concurrently and dependent ones in order

Large implementations may also need context resets. Simply run /implement 001 again in a fresh conversation—Claude tracks progress in the tracker.

Step 5: Review and Ship

/review

Four parallel specialists review your code:

• 🔒 Security - Authentication, authorization, input validation
• ⚡ Performance - Query optimization, memory management
• ✨ Quality - Code style, design patterns, maintainability
• 🧪 Tests - Coverage gaps, edge cases

🎯 Which Skill Should I Use?

Decision Tree

What do you need to do?
│
├─ Want project-wide guardrails? ─────────► /constitution
│
├─ Build something new? ──────────────────► /specify
│                                           Then: /validate → /implement
│
├─ Understand existing code? ─────────────► /analyze
│   └─ Want to improve it? ───────────────► Then: /refactor
│
├─ Something is broken? ──────────────────► /debug
│
├─ Need to run tests? ───────────────────► /test
│
├─ Code ready for merge? ─────────────────► /review
│
├─ Need documentation? ───────────────────► /document
│
└─ Check constitution compliance? ────────► /validate constitution

Skill Reference