bootstrap-feature

Command: Bootstrap Feature

Arguments

The feature to document is $feature (also available as $ARGUMENTS). When it is empty, ask the user what to document before Step 1 — do NOT infer a feature from surrounding context.

Literal-token flag rule: a documented flag is active ONLY if its literal token appears in $ARGUMENTS. Never infer that a flag was passed because the documentation describes it.

Preflight: Memory Layer Check

Run this FIRST, before Step 1. It takes one Read.

1. Check that ~/.claude/claude.md exists and contains the marker heading ## Autonomous Development Workflow (MANDATORY).

2. If the file is missing, or the marker is absent, print this warning verbatim and continue anyway:

   WARNING: the SDLC memory layer is not installed. ~/.claude/claude.md is missing or does not contain the pipeline instruction, so the autonomous workflow is not active for unprefixed requests in this session. Installing the plugin alone is not sufficient — run bash install.sh from the claude-code-sdlc repo to install the memory layer.

3. Never block on this check. A missing memory layer degrades autonomy; it does not invalidate this run. Warn once and proceed to Step 1.

Known limitation: this preflight only fires when this skill is invoked explicitly. An unprefixed natural-language feature request bypasses it entirely, because nothing runs. That gap closes when the SessionStart hook lands (roadmap F2a).

Agency Documentation Pipeline

Every feature follows this pipeline before any code is written. Each step is performed by a specialized agent role.

Step 1: Product Manager — PRD Documentation

Delegate to prd-writer agent:

• Read docs/PRD.md to understand the existing format
• Add a new section documenting the feature's requirements
• Include: feature description, user story, functional/non-functional requirements, acceptance criteria, affected endpoints, schema changes, UI changes

Step 2: Business Analyst — Use Cases

Delegate to ba-analyst agent:

• Read docs/PRD.md for the feature requirements just documented
• Create docs/use-cases/<feature-slug>_use_cases.md
• Document ALL scenarios: primary flows, alternative flows, error flows, edge cases
• Include actors, preconditions, postconditions, data requirements
• This document becomes the blueprint for E2E testing

Step 3: Software Architect — Architecture Review

Delegate to architect agent:

• Read PRD and use-case documents
• Validate the approach against project structure defined in CLAUDE.md
• Check module boundaries
• Review any schema changes for data integrity
• Verify API design follows REST conventions
• Flag components needing security pre-review during implementation

If Architecture Review FAILS:

1. Read the architect's specific objections
2. Revise the approach to address each violation
3. Re-submit to architect for review
4. Retry up to 2 times
5. If still rejected: document the architectural concern in scratchpad as a blocker and ask the user

Step 4: QA Lead — Test Case Documentation

Delegate to qa-planner agent:

• Read docs/PRD.md AND docs/use-cases/<feature-slug>_use_cases.md
• Create docs/qa/<feature-slug>_test_cases.md
• Map every use-case scenario to test cases (UC-1 → TC-1.1, UC-1-E1 → TC-1.2, etc.)
• Cover: happy path, alternative flows, errors, edge cases, auth boundaries, concurrency

Step 5: Tech Lead — Implementation Planning

Delegate to planner agent:

• Read ALL documentation created above: PRD, use cases, architecture review, test cases
• Read the project's CLAUDE.md for file structure and conventions
• Break the feature into 5-9 testable implementation slices
• Each slice references which use-case scenarios it implements (UC-X.Y)
• Flag slices needing architect or security pre-review
• Reference actual project files discovered during exploration

Step 5a: Plan Critic — Adversarial Plan Review

After the planner agent produces the plan and before Step 6 (Git Setup), invoke plan-critic against the plan file. This is the first point at which a plan produced entirely by /bootstrap-feature (no interactive plan-mode involved) is critiqued at all.

Run the same critique-and-fix loop src/claude.md's plan-mode "Plan Critic Pass" section uses:

1. Invoke plan-critic against the plan file (loop 1).
2. Fix the plan file for every BLOCKER and every WARNING finding. This fix pass always runs whenever there is at least one BLOCKER or WARNING — it is NOT conditional on a BLOCKER being present. WARNING is where Scope Reduction Detection lands, and hedging findings must be fixed rather than merely noted. 2b. Re-invoke only if a BLOCKER was found in the loop just completed (loop 2) — the loop repeats on BLOCKERs, the fixing covers WARNINGs too.
3. Repeat once more if needed (loop 3).
4. If zero BLOCKER findings remain after any loop, proceed to Step 6 — having already applied the step-2 fixes. Any WARNING deliberately not fixed is recorded with its justification.
5. If a BLOCKER finding still remains after loop 3, escalate per Rule 4 (error-recovery.md): stop, present the remaining BLOCKER findings verbatim, state the decision needed, and present the options. Do NOT proceed to Step 6 with an unresolved BLOCKER.

If plan-critic cannot be resolved (memory-layer-only install with no plugin agents present), warn — naming plan-critic explicitly as unresolvable — and proceed to Step 6 without a critique. Never skip the critic pass silently.

Step 6: Git Setup

• Verify git status is clean
• Create feature branch: feat/<feature-slug>

Step 7: Initialize Scratchpad

Update .claude/scratchpad.md with the full feature context:

• Feature name and branch
• Status: "implementing wave 1 slice 1/N" (when plan has Wave: fields) or "implementing slice 1/N" (when no wave assignments)
• Full plan with slices grouped by wave: each wave as a ### Wave N subheading with its slices listed as "pending". When plan has no Wave: fields, list slices as a flat numbered list under ### Wave 1 (sequential)
• Empty blockers section

This is CRITICAL for surviving context compaction during long sessions.

Output Format

## PRD
- Section added/updated in docs/PRD.md: [section number and title]

## Use Cases
- Created: docs/use-cases/<feature>_use_cases.md
- Primary flows: [count]
- Alternative flows: [count]
- Error flows: [count]
- Edge cases: [count]

## Architecture Review
- Verdict: PASS/FAIL
- Action items: [list if any]
- Slices flagged for security review: [list if any]

## QA Test Cases
- Created: docs/qa/<feature>_test_cases.md
- Total test cases: [count]
- Use-case coverage: [all UC-X mapped / gaps]

## Plan Critique
- Verdict: PASS (zero BLOCKER findings) / ESCALATED (unresolved BLOCKER after 3 loops) / SKIPPED (plan-critic unresolvable)
- Loops run: [1-3]
- Findings: [count] BLOCKER, [count] WARNING, [count] INFO
- Unresolved BLOCKERs (if escalated): [list]

## Plan (5-9 slices across N waves)
### Wave 1
1. [slice description] — covers UC-X.Y
2. [slice description] — covers UC-X.Z

### Wave 2
3. [slice description] — covers UC-X.W
...

## Acceptance Criteria
- [verifiable condition]
- ...

## Files to Modify
- [file paths]

## Git
- Branch: feat/<feature-slug>
- Base: main

Constraints

• NEVER skip the PRD step — every feature gets documented first
• NEVER skip the Use Cases step — all scenarios must be documented
• NEVER skip the QA step — test cases are documented before code
• Steps MUST run in order: PRD → Use Cases → Architecture → QA → Plan
• Follow existing patterns in the codebase
• Read the project's CLAUDE.md for tech stack and architecture