code-feature

Files (1)

• SKILL.md

SKILL.md (first lines)

!`bash ${CLAUDE_SKILL_DIR}/../../hooks/read-state.sh session-state`

<preflight-guard>
STOP. Before executing this skill, check: does .sweetclaude/state/sweetclaude.yaml or .sweetclaude/state/phase.yaml exist in the project directory? If NEITHER, do not proceed. Tell the user: "This project is not set up for SweetClaude. Running the pre-flight check now." Then invoke the sweetclaude master skill (Skill tool, skill: "sweetclaude:master") and run its pre-flight. Return here only after the pre-flight passes.
</preflight-guard>

# Build Feature

Build feature: $ARGUMENTS

## Process Control Gate

Before Step 3 starts, read `skills/process-controls.md` and create or update
`.sweetclaude/state/process-control-ledger.yaml`. The Level 3 pipeline may not
spawn a test writer, QA caucus, implementer, or background agent when the
ledger is missing, over budget, stale, or in a stop disposition.

If the QA caucus, RED validation, implementation, or verification step produces
repeated blockers that would require another caucus/correction loop, stop and
ask the user for a bounded decision. Do not continue autonomous patch-test-
recaucus cycles under the same story contract.

For large/high-rigor stories, Step 2 must produce or locate a frozen
`success_criteria_contract` before Step 3 starts. The handoff into TDD must
include `success_criteria_contract_hash`, `criterion_ids`, and the expected
evidence artifacts. Completion is not valid without
`success-criteria-ledger.json` showing every frozen criterion evaluated and
`all_success_criteria_passed == true`. No review, caucus, verification,
release, or completion step may add completion criteria; new concerns route to
backlog, amendment request, split story, or human escalation.

## Process

### Step 0: Story Branch Setup

```bash
git branch --show-current
```

If the output already starts with an issue ID prefix (e.g., `ISSUE-046/`, `issue-42/`) — skip this step.

Otherwise, derive the branch name:
- **ID**: extract from `$ARGUMENTS` if it contains a backlog ID (`ISSUE-NNN`, `issue-NNN`). Fall back to `active_work_item.id` from session state. If neither is found, use `feature` as the ID.
- **Slug**: take the work item title, lowercase, replace non-alphanumeric characters with hyphens, collapse consecutive hyphens, trim trailing hyphens, truncate to 40 characters.
- **Branch name**: `{ID}/{slug}` — e.g., `ISSUE-046/git-branch-discipline`

Offer via AskUserQuestion:
- **Create branch `{branch-name}`** (Recommended) — `git checkout -b {branch-name}`
- **Stay on current branch** — I'll manage branches myself
- **Something else**

If "Create branch": run `git checkout -b {branch-name}`.

### Step 1: Locate specs

Check for existing artifacts in this order:
1. Gherkin `.feature` files in `.sweetclaude/` or `features/` matching the feature name
2. User stories and issue artifacts (ISSUE-NNN) in the configured product base (`product_base`, default `.sweetclaude/product/`)
3. PRD or product brief in `docs/`

If Gherkin specs already exist → skip to Step 3.
If user stories exist but no Gherkin → go to Step 2b.
If nothing exists → go to Step 2a.

### Step 2a: Write the user story

Ask:
> "Describe the feature in one sentence: who does what, and what outcome do they get?"

Then draft a user story:
```
As a {persona}, I want to {action} so that {outcome}.

Acceptance criteria:
- Given {context}, when {action}, then {result}
- ...
```

Present and confirm before continuing.

### Step 2b: Generate Gherkin

Invoke `sweetclaude:library-load product-user-tdd-tests` with the user story as input to generate `.feature` files. Wait for completion and user approval of the Gherkin before continuing.

### Step 3: TDD Level 3

Run the full Level 3 pipeline from `sweetclaude:library-load code-tdd`:

1. **Spawn test writer subagent.** Receives: the `.feature` file, existing codebase for patterns. No knowledge of planned implementation. Writes failing tests that fully specify the Gherkin behavior.

2. **QA Caucus**. Spawn three parallel, independent review subagents:
   - `qa-caucus-service` — service/API coverage
   - `qa-caucus-component` — UI/component coverage (if applicable)
   - `qa-caucus-integration` — cross-cutting concerns
   Consolidate findings. Present gaps to user for approval. Add approved gaps to test files.

   The process-control ledger must show one available three-reviewer caucus
   budget before spawn. After the caucus, update caucus round, reviewer count,
   and blocking finding counts. A second blocking caucus failure requires user
   decision or contract reopen before more edits or reviewer dispatch.

3. **Verify RED.** Run tests. All must fail. If any pass unexpectedly, investigate before continuing.

4. **User approval.** Present the test files. Wait for explicit approval before implementation begins.

5. **Commit tests.** Git checkpoint: `test: RED - {feature-name} failing tests`

6. **Spawn implementer subagent.** Receives: test files (read-only), existing codebase. Never sees user stories, Gherkin, or test-writing reasoning. Instruction: make the tests pass with minimum code.

   Before dispatching, confirm the process-control ledger has implementer
   budget available and no active stop disposition.

   Before dispatching, offer via AskUserQuestion:
   - **Implement now (inline)** — run in this conversation; see progress in real time
   - **Implement in background** — dispatch as a background agent; continue working and get notified when tests are green

   If "Implement in background": dispatch implementer Agent with `run_in_background: true`. Confirm: "Implementer running in background. You'll be notified when tests pass." Stop — verification and refactor will follow in the next turn when the agent reports back.

From carson-sweet/sweetclaude, AGPL-3.0.

More from carson-sweet/sweetclaude