Bootstrap Feature

---
description: Run the documentation phase of the SDLC pipeline for a feature — PRD, use cases, architecture review, QA test cases, implementation plan, feature branch and scratchpad. Produces no code.
argument-hint: "<feature description>"
arguments: [feature]
allowed-tools: Read, Glob, Grep, Edit, Write, Bash, Agent, TodoWrite
---

# 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