Start Plugin - The Agentic Startup

Workflow orchestration plugin for spec-driven development in Claude Code.

The start plugin provides ten user-invocable workflow skills, five autonomous skills, and two output styles to transform how you build software with Claude Code.

For quick start, workflow guide, and skill selection, see the main README.

Table of Contents

• User-Invocable Skills — specify, implement, validate, test, review, document, analyze, refactor, debug, constitution
• Autonomous Skills — 5 context-activated skills
• Documentation Structure — specs, domain, patterns, interfaces
• Output Styles — The Startup, The ScaleUp
• Typical Development Workflow — primary and maintenance flows
• Skills in Action — real-world examples
• Templates — PRD, SDD, Factory/Manifest, DOR, DOD
• Philosophy — spec-driven development principles

User-Invocable Skills

These skills are invoked by the user via slash commands (e.g., /specify). Unlike autonomous skills which activate automatically based on context, user-invocable skills wait for explicit invocation.

/specify <description>

Create comprehensive specifications from brief descriptions through deep research and specialist agent coordination, then route to one of three decomposition tiers based on complexity.

Purpose: Transform ideas into implementation-ready specifications with product requirements, solution design, and a tier-appropriate decomposition (Direct, Incremental, or Factory)

Usage:

/specify Build a real-time notification system with WebSocket support
/specify 001  # Resume existing specification work

Key Features:

• Auto-incrementing Spec IDs - Automatically creates numbered directories (001, 002, etc.)
• Resume Capability - Can resume work on existing specifications by ID
• Complexity Classifier - Inspects requirements.md and solution.md and recommends Direct, Incremental, or Factory tier with rationale
• Three-Tier Routing - User confirms or overrides; orchestrator dispatches to the matching decomposition skill
• Pattern Documentation - Automatically documents discovered patterns in docs/patterns/
• Interface Documentation - Captures external service contracts in docs/interfaces/
• Domain Documentation - Records business rules in docs/domain/
• Quality Gates - Requires user approval between major phases

Tier selection at step 6:

flowchart TD
    A([Your Feature Idea]) --> |initialize| B{Check<br>Existing}
    B --> |exists| C[Review and Refine]
    C --> END[Ready for /implement 001]
    B --> |new| D[Requirements Gathering<br/>Create requirements.md if needed]
    D --> E[Technical Research<br/>Create solution.md if needed, document patterns, interfaces]
    E --> F[Classify Complexity<br/>Direct vs Incremental vs Factory]
    F --> |Direct| END
    F --> |Incremental| G[Incremental Decomposition<br/>Create plan/README.md + phase-N.md]
    F --> |Factory| H[Factory Decomposition<br/>Create units/, scenarios/, manifest.md]
    G --> END
    H --> END

/implement <spec-id>

Execute a specification by autodetecting the decomposition tier and dispatching to the matching execution sub-skill.

Purpose: Transform validated specifications into working code via the tier-appropriate orchestrator — Direct (no plan), Incremental (phase loop), or Factory (parallel units with information-barrier agents and retry).

Usage:

/implement 001
/implement path/to/custom/spec/

How dispatch works:

The /implement entry point inspects the spec directory and routes to the matching sub-skill:

Key Features (across tiers):

• Tier-appropriate orchestration - Each sub-skill is optimized for its complexity bracket
• Resumability - All tiers support pausing and resuming (Incremental via frontmatter status, Factory via manifest checkboxes)
• Drift Detection - All tiers run Skill(start:validate) drift checks
• Constitution Enforcement - L1/L2 violations block completion in all tiers
• Real-time Updates - TodoWrite or TaskList tracking shows live progress

flowchart TD
    A([manifest.md]) --> |load| B[Initialize Factory<br/>Discover units and order]
    B --> C{Execution Groups<br>Remaining?}
    C --> |yes| D[Spawn Code Agents<br/>Parallel for independent units<br/>Unit spec + AGENTS.md only]
    D --> E[Evaluate Sequentially<br/>Scenarios + running service<br/>No source code access]
    E --> F{Satisfaction<br>Threshold Met?}
    F --> |no| G[Retry with Filtered<br/>Failure Summaries]
    G --> D
    F --> |yes| C
    C --> |no| H[Final Validation<br/>Run full test suite<br/>Verify all requirements]
    H --> END[Implementation Complete]

flowchart TD
    A([plan/README.md]) --> |parse phase checklist| B[Discover phases]
    B --> C{Phase pending?}
    C --> |yes| D[Mark phase in_progress<br/>Read phase-N.md]
    D --> E[Delegate tasks<br/>parallel + sequential subagents]
    E --> F[Drift + Constitution check]
    F --> G[Mark phase completed<br/>Flip README checkbox]
    G --> H{User: continue?}
    H --> |yes| C
    H --> |pause| END[Resumable]
    C --> |no| I[Complete]
    I --> END

flowchart TD
    A([requirements.md + solution.md]) --> B[Decompose into 1–3 delivery units]
    B --> C{>3 units?}
    C --> |yes| D[Recommend re-run /specify<br/>at higher tier]
    C --> |no| E[Delegate units to subagents<br/>TDD: failing test → code → refactor]
    E --> F[Drift + Constitution check]
    F --> END[Complete]

/validate <target>

Validate specifications, implementations, or understanding through intelligent context detection and the 3 Cs framework (Completeness, Consistency, Correctness).

Purpose: Quality gate that works at any lifecycle stage - during specification, before implementation, or after completion

Usage:

/validate 001                                          # Validate spec by ID
/validate .start/specs/001/solution.md                  # Validate specific file
/validate Check the auth implementation against SDD    # Compare implementation to spec
/validate drift                                        # Check for spec-implementation drift
/validate constitution                                 # Validate constitution compliance
/validate Is my caching approach correct?              # Validate understanding

Key Features:

• Intelligent Mode Detection - Automatically determines validation type from input
• The 3 Cs Framework - Checks Completeness, Consistency, and Correctness
• Ambiguity Detection - Scans for vague language ("should", "various", "etc.")
• Cross-Document Traceability - Verifies requirements to solution to manifest alignment
• Drift Detection - Checks spec-implementation alignment
• Constitution Enforcement - Validates L1/L2/L3 governance rules
• Advisory Only - Provides recommendations without blocking
• Comparison Validation - Compares implementations against specifications

flowchart TD
    A([Validation Request]) --> |parse| B{Detect Mode}
    B --> |spec ID| C[Specification Validation<br/>3 Cs + Ambiguity + Readiness]
    B --> |file path| D[File Validation<br/>Quality + Completeness]
    B --> |drift| E[Drift Detection<br/>Spec vs Implementation]
    B --> |constitution| F[Constitution Validation<br/>L1/L2/L3 Rule Enforcement]
    B --> |against| G[Comparison Validation<br/>Implementation vs Spec]
    B --> |freeform| H[Understanding Validation<br/>Approach Correctness]
    C --> I[Report<br/>Findings + Recommendations]
    D --> I
    E --> I
    F --> I
    G --> I
    H --> I

/test [target]

Run tests with strict code ownership enforcement — no "pre-existing failures" excuses allowed.

Purpose: Discover and execute tests, ensure the codebase is left in a passing state, and enforce ownership of any failures encountered

Usage:

/test                            # Run full test suite
/test all                        # Run full test suite (explicit)
/test src/auth/                  # Run tests for specific path
/test baseline                   # Capture current test state

Key Features:

• Test Discovery - Automatically finds test runner, config, and test files
• Code Ownership - If tests fail, you own the fix — no blaming pre-existing issues
• Baseline Capture - Record current passing/failing state before changes
• Multi-Agent Parallel - Can distribute test suites across parallel agents
• Targeted Execution - Run specific test files, directories, or the full suite

flowchart TD
    A([Test Request]) --> |discover| B[Find Test Runner<br/>Config, scripts, test files]
    B --> |execute| C[Run Tests<br/>Full suite or targeted]
    C --> |check| D{Tests Pass?}
    D --> |yes| E[All Clear<br/>Report results]
    D --> |no| F[Own the Failures<br/>Investigate and fix each one]
    F --> |fixed| C

/review [target]

Multi-agent code review with specialized perspectives running in parallel.

Purpose: Comprehensive code review before merging, with specialized agents examining different concerns simultaneously

Usage:

/review                          # Review staged changes
/review 123                      # Review PR number
/review feature/auth             # Review branch changes
/review src/auth/ src/users/     # Review specific files/directories
/review staged                   # Explicitly review staged changes

Key Features:

• Parallel Specialists - Security, Performance, Quality, and Test agents review simultaneously
• Conditional Perspectives - Concurrency, Dependencies, Compatibility, Accessibility activate when relevant
• Target Auto-Detection - Detects PR number, staged changes, file path, or branch diffs
• Confidence Scoring - Each finding includes confidence level (HIGH/MEDIUM/LOW)
• Severity Classification - CRITICAL, HIGH, MEDIUM, LOW findings
• Standard or Team Mode - Fire-and-forget subagents or persistent teammates with coordination

flowchart TD
    A([Review Request]) --> |detect| B{Detect Target}
    B --> |PR number| C[Load PR Diff]
    B --> |staged| D[Load Staged Changes]
    B --> |branch| E[Load Branch Diff]
    B --> |files| F[Load File Contents]
    C --> G[Launch Parallel Agents<br/>Security, Performance<br/>Quality, Tests + conditionals]
    D --> G
    E --> G
    F --> G
    G --> |merge| H[Consolidate Findings<br/>Deduplicate, rank by severity]
    H --> I[Verdict + Next Steps]

/document [target]

Generate and sync documentation including API docs, READMEs, JSDoc comments, and documentation audits.

Purpose: Keep documentation current with code, generate missing docs, and identify staleness

Usage:

/document src/api/               # Generate API documentation
/document readme                 # Update project README
/document src/utils/             # Add JSDoc to code files
/document audit                  # Audit documentation coverage

Key Features:

• Multiple Documentation Modes - Code, API, README, Audit, Module
• Staleness Detection - Identifies outdated documentation
• Coverage Metrics - Reports documentation completeness percentage
• OpenAPI Generation - Creates OpenAPI/Swagger specs from API code
• Multi-Agent Parallel - Multiple documentation agents work simultaneously

flowchart TD
    A([Document Request]) --> |detect| B{Detect Mode}
    B --> |file path| C[JSDoc Generation<br/>Functions, types, exports]
    B --> |api| D[API Documentation<br/>OpenAPI, endpoints, schemas]
    B --> |readme| E[README Update<br/>Features, usage, examples]
    B --> |audit| F[Coverage Audit<br/>Find gaps, staleness]
    C --> G[Generate Documentation<br/>Parallel agents when possible]
    D --> G
    E --> G
    F --> G
    G --> H[Sync and Report<br/>Coverage metrics<br/>Staleness warnings]

/analyze <area>

Discover and document business rules, technical patterns, and system interfaces through iterative exploration.

Purpose: Extract organizational knowledge from existing codebase and create reusable documentation

Usage:

/analyze security patterns in authentication
/analyze business rules for user permissions
/analyze technical patterns in our microservices architecture

flowchart TD
    A([Analysis Request]) --> |initialize| B[Scope Definition<br/>Clarify analysis area<br/>Set cycle plan]
    B --> |start cycle| C[Discovery Phase<br/>Specialist analysis<br/>Pattern identification]
    C --> |document| D[Documentation Phase<br/>Create domain docs<br/>Create pattern docs<br/>Create interface docs]
    D --> |review| E[Review and Validation<br/>Check completeness<br/>Identify gaps]
    E --> |continue?| F{More Cycles<br>Needed?}
    F --> |yes| C
    F --> |no| G[Final Summary<br/>Analysis report<br/>Recommendations<br/>Next steps]

/refactor <description>

Improve code quality while strictly preserving all existing behavior through test-validated incremental changes.

Purpose: Safe, systematic refactoring with automatic rollback on test failures

Usage:

/refactor Simplify the authentication middleware for better testability
/refactor Improve the WebSocket connection manager

flowchart TD
    A([Refactoring Request]) --> |analyze| B[Goal Clarification<br/>Define objectives<br/>Analyze codebase]
    B --> |assess| C{Complexity<br>Check}
    C --> |simple| D[Direct Refactoring<br/>Run tests first<br/>Apply changes<br/>Validate each step]
    D --> |review| E[Specialist Review<br/>Code quality check<br/>Performance impact]
    E --> DONE[Refactoring Complete]
    C --> |complex| F[Create Specification<br/>Generate solution.md<br/>Generate manifest.md + units/ + scenarios/<br/>Document approach]
    F --> |defer| G[Ready for /implement<br/>Execute via factory loop]

/debug <description>

Diagnose and resolve bugs through conversational investigation with systematic root cause analysis.

Purpose: Natural language debugging partner that helps identify and fix issues through dialogue, not rigid procedures

Usage:

/debug The API returns 500 errors when uploading large files
/debug Tests are failing intermittently on CI but pass locally
/debug Users report slow page loads after the latest deployment

Key Features:

• Conversational Flow - Natural dialogue, not rigid checklists or procedures
• Progressive Disclosure - Starts with summary, reveals details on request
• Observable Actions Only - Reports only what was actually checked and found
• User-Driven - Proposes next steps, lets user guide the direction
• Hypothesis Tracking - Forms and tests ranked hypotheses systematically
• Evidence-Based - Never fabricates reasoning; all conclusions backed by evidence

flowchart TD
    A([Bug Description]) --> |understand| B[Phase 1: Understand<br/>Reproduce issue<br/>Gather context]
    B --> |isolate| C[Phase 2: Narrow Down<br/>Form hypotheses<br/>Binary search]
    C --> |investigate| D[Phase 3: Root Cause<br/>Test hypotheses<br/>Find evidence]
    D --> |fix| E[Phase 4: Fix and Verify<br/>Propose fix<br/>Run tests]
    E --> |close| F[Phase 5: Wrap Up<br/>Summarize if needed<br/>Suggest follow-ups]

    D --> |stuck| G{Need More<br/>Context?}
    G --> |yes| B
    G --> |different angle| C

/constitution [focus-areas]

Create or update a project constitution with governance rules through discovery-based pattern analysis.

Purpose: Establish checkable project rules that are enforced during implementation, review, and validation

Usage:

/constitution                                    # Create new constitution via codebase discovery
/constitution security and testing               # Focus on specific areas
/constitution Add API patterns                   # Update existing constitution

Key Features:

• Discovery-Based Rules - Analyzes actual codebase patterns, never assumes frameworks
• L1/L2/L3 Level System - L1 (blocking + autofix), L2 (blocking, manual), L3 (advisory)
• Three-Layer Enforcement - Checked during specify (SDD), implement, and review
• Pattern + Check Rules - Supports regex patterns and semantic LLM-interpreted checks
• Graceful Degradation - System works normally if no constitution exists

### No Hardcoded Secrets

\```yaml
level: L1
pattern: "(api_key|secret|password)\\s*[:=]\\s*['\"][^'\"]{8,}['\"]"
scope: "**/*.{ts,js}"
exclude: "**/*.test.*, .env.example"
message: Hardcoded secret detected. Use environment variables.
\```

Secrets must never be committed to source control.

flowchart TD
    A([/constitution]) --> |check| B{Constitution<br>Exists?}
    B --> |no| C[Discovery Phase<br/>Explore codebase patterns]
    C --> D[Rule Generation<br/>Create L1/L2/L3 rules]
    D --> E[User Confirmation<br/>Present proposed rules]
    E --> F[Write CONSTITUTION.md<br/>At project root]
    B --> |yes| G{Update or<br>Validate?}
    G --> |update| H[Add new rules<br/>Focus on specified areas]
    H --> E
    G --> |validate| I[Run /validate constitution]
    F --> END[Constitution Created]

Installation

Install The Agentic Startup framework with the interactive installer:

npx the-startup

What it does:

• Supports both Claude marketplace installs and file-based installs for other harnesses
• Prompts for plugin multi-select
• Prompts for harness + installation path when using file install mode
• Copies file-install artifacts from the remote GitHub repository

Flags:

• --help - Show usage information

Note: Output styles are available immediately via /output-style - no additional setup required.

Autonomous Skills

The start plugin includes five autonomous skills that activate automatically based on context. You never need to explicitly invoke them — they work when needed.

Specification Skills

Implementation Skills

Methodology Skills

Documentation Structure

The plugin encourages structured knowledge management:

.start/
└── specs/
    └── [3-digit-number]-[feature-name]/
        ├── README.md                        # Decisions and progress
        ├── requirements.md                  # What to build
        ├── solution.md                      # How to build it
        ├── manifest.md                      # Decomposition manifest
        ├── units/                           # Factory-sized specs
        │   └── [unit-name].md               # One per unit of work
        └── scenarios/                       # Holdout evaluation scenarios
            └── [unit-name]/                 # Scenarios per unit

docs/
├── domain/                                  # Business rules
│   ├── user-permissions.md
│   ├── order-workflow.md
│   └── pricing-rules.md
│
├── patterns/                                # Technical patterns
│   ├── authentication-flow.md
│   ├── caching-strategy.md
│   └── error-handling.md
│
└── interfaces/                              # External integrations
    ├── stripe-payments.md
    ├── sendgrid-webhooks.md
    └── oauth-providers.md

Auto-Documentation

The document skill's Capture perspective automatically creates files in the correct location when patterns, interfaces, or domain rules are discovered during:

• Specification creation (/specify)
• Implementation (/implement)
• Analysis (/analyze)

Deduplication

The capture workflow always checks existing documentation before creating new files, preventing duplicates.

Output Styles

The start plugin includes two output styles for different working preferences. Both share the same operational fundamentals (verification, code ownership, scope management) but express them differently.

Activate via: /output-style start:The Startup or /output-style start:The ScaleUp

The Startup

High-energy execution with structured momentum.

Personality:

• The Visionary Leader - "We'll figure it out" - execute fast, iterate faster
• The Rally Captain - Turn challenges into team victories
• The Orchestrator - Run parallel execution like a conductor
• The Pragmatist - MVP today beats perfect next quarter

Best for:

• Fast-paced development sprints
• High-energy execution mode
• When you want momentum and celebration

The ScaleUp

Calm confidence with educational depth.

Personality:

• The Seasoned Leader - We've been through the fire. Now we build to last.
• The Strategist - Think two steps ahead. Today's shortcut is tomorrow's outage.
• The Multiplier - Your job is to make the whole team better, not just ship code.
• The Guardian - Reliability isn't optional. Customers trust us with their business.

Unique feature - Educational Insights:

The ScaleUp provides contextual explanations as it works:

I've added the retry logic to the API client:

await retry(fetchUser, { maxAttempts: 3, backoff: 'exponential' });

Insight: I used exponential backoff here because this endpoint has rate limiting. The existing src/utils/retry.ts helper already implements this pattern - I'm reusing it rather than adding a new dependency.

Best for:

• Learning while building
• Understanding codebase patterns
• When you want explanations with your code
• Onboarding to unfamiliar codebases

Comparison

Typical Development Workflow

Setup (Optional)

/constitution ──> Create project governance rules
                  L1/L2/L3 rules auto-enforced in BUILD flow
                  CONSTITUTION.md at project root

Primary Workflow: Specify > Validate > Implement > Review

/specify ──> /validate ──> /implement ──> /review
   |              |              |              |
Create specs  Check quality  Factory loop  Code review
PRD+SDD+Factory  3 Cs framework  Factory loop  Security+Perf
   |              |              |              |
Constitution  Constitution   Constitution   Constitution
checked on    mode available + drift enforced compliance
SDD

Optional: /document after implementation for documentation sync

If CONSTITUTION.md exists, rules are automatically checked at each stage.

1. Create Specification

/specify Add real-time notification system with WebSocket support

What happens:

• Creates .start/specs/001-notification-system/
• Generates requirements.md, solution.md, manifest.md, units/, scenarios/
• Documents discovered patterns/interfaces
• Optional: Creates spec/001-notification-system git branch

2. Validate Before Implementation (Recommended)

/validate 001

What happens:

• Checks completeness, consistency, correctness (3 Cs)
• Detects ambiguities and vague language
• Security scanning for common vulnerabilities
• Verifies cross-document traceability

3. Execute Implementation

/implement 001

What happens:

• Optional: Creates feature/001-notification-system git branch
• Reads manifest.md, spawns code agents per execution group
• Evaluation agents validate against holdout scenarios
• Retries with filtered failure summaries until threshold met
• Optional: Creates PR at completion

4. Review Before Merge

/review

What happens:

• Parallel specialists review (Security, Performance, Quality, Tests + conditionals)
• Generates consolidated report with severity rankings

5. Generate Documentation (Optional)

/document src/notifications/

What happens:

• Adds JSDoc/TSDoc comments
• Updates README if needed
• Reports documentation coverage

Maintenance Workflows

Understand Existing Code

/analyze security patterns in authentication

Documents findings in docs/patterns/, docs/domain/, docs/interfaces/

Refactoring

/refactor Restructure the authentication module for better testability

For architectural changes - creates specs, plans migration, handles breaking changes.

Fix Bugs

/debug The notification system stops working after 100 concurrent users

Conversational investigation with observable evidence and user-driven direction.

Audit Documentation

/document audit

Reports documentation coverage and identifies stale or missing docs.

Skills in Action

Example: Knowledge Capture via Document Skill

Scenario: During implementation, an agent discovers a pattern

Agent output: "I implemented a retry mechanism with exponential backoff for API calls"

What happens automatically:

1. Document skill's Capture perspective activates
2. Checks docs/patterns/ for existing retry patterns
3. Not found — Creates docs/patterns/api-retry-strategy.md
4. Uses pattern template
5. Reports: "Created docs/patterns/api-retry-strategy.md"

You didn't have to: Manually request documentation or specify the path

Templates

Rich templates for structured documentation, co-located with their skills:

plugins/start/skills/
├── specify-requirements/template.md     # Product requirements structure
├── specify-solution/template.md         # Solution design structure
├── specify-incremental/template.md         # Incremental plan manifest (plan/README.md)
├── specify-incremental/templates/phase.md  # Per-phase template (plan/phase-N.md)
├── specify-factory/SKILL.md             # Factory decomposition (units, scenarios, manifest)
└── document/templates/                  # Knowledge capture templates
    ├── domain-template.md               # Business rules
    ├── pattern-template.md              # Technical patterns
    └── interface-template.md            # External integrations

Usage: Automatically used by /specify and /document when creating documentation

Philosophy

Spec-Driven Development

The problem: Features built without clear requirements lead to technical debt, rework, and inconsistency.

Our approach:

1. Specify First - Comprehensive specifications before code
2. Review & Refine - Validate with stakeholders
3. Implement with Confidence - Execute validated plans
4. Document & Learn - Capture patterns for reuse

Core Principles

• Measure twice, cut once - Upfront planning saves time
• Documentation as code - Specs evolve with your codebase
• Parallel execution - Multiple specialists, clear boundaries
• Quality gates - DOR/DOD enforce standards
• Progressive disclosure - Load details only when needed

Further Reading

• Main README - Project overview and installation