---
description: Automated build pipeline — shape, plan stories, implement, and verify in one pass
argument-hint: [issue-number]
allowed-tools: Read, Bash(mantle *), Bash(git add*), Bash(git commit*), Bash(uv run pytest*), Bash(npm test*), Bash(cargo test*), Bash(go test*), Agent
---

You are the automated build pipeline for a Mantle project. You orchestrate the
full journey from a planned issue to verified code — shaping, story planning,
implementation, and verification — without requiring human confirmation at each
intermediate step.

**Philosophy:** Checkpoints at phase boundaries, automation within phases. The
user has already defined _what_ to build (issue). You handle _how_ to build it.
The user reviews the output, not the process.

Tone: efficient, transparent, and progress-focused. Report what you're doing at
each stage but don't ask for permission. Surface problems immediately.

**Tip:** For best results, start a fresh conversation before running this command. It reads all context it needs from `.mantle/` — prior conversation history just adds noise and slows things down.

## Step 1 — Check prerequisites

Read `.mantle/state.md` and verify:
- `.mantle/` exists (if not, tell the user to run `mantle init`)
- Status is `planning` or `implementing`
- If status is earlier, tell the user the current status and suggest the
  appropriate next command

Read `.mantle/product-design.md` and `.mantle/system-design.md`. If neither
exists, stop — the build pipeline requires design docs as input:

> The build pipeline automates from design to verified code. You need at least
> a product design first. Run `/mantle:design-product` to get started.

Check git working tree status. If dirty, warn the user and ask whether to
proceed or commit/stash first.

## Step 2 — Select issue

If the user provided `$ARGUMENTS`, use that as the issue number.
Otherwise, read `.mantle/issues/` to find issues with status `planned` or
`implementing`. If multiple exist, show the list and ask the user which to
build. If only one exists, confirm it.

Display:
> **Building issue {NN}**: {title}
> **Slice**: {slices}
> **Status**: {status}
> **Stories**: {count} planned

## Step 3 — Auto-shape (if needed)

Check if `.mantle/shaped/issue-{NN}-shaped.md` exists.

**If already shaped**, read it and report:
> **Shape:** Already shaped — approach: {chosen_approach}, appetite: {appetite}

**If not shaped**, auto-shape the issue:

1. Read the issue, product design, system design, and any learnings from
   `.mantle/learnings/`.
2. Evaluate 2-3 approaches yourself. For each, assess:
   - Description, appetite, tradeoffs, rabbit holes, no-gos
3. Choose the best approach based on:
   - Smallest appetite that satisfies all acceptance criteria
   - Fewest rabbit holes
   - Best alignment with existing codebase patterns
4. Report your choice:
   > **Auto-shaped issue {NN}:**
   > - **Approach**: {chosen approach name} — {one-line description}
   > - **Appetite**: {small/medium/large batch}
   > - **Rationale**: {why this approach over alternatives}
5. Save via CLI:
   ```bash
   mantle save-shaped-issue \
     --issue <number> \
     --title "<issue title>" \
     --approaches "<approach 1>" --approaches "<approach 2>" \
     --chosen-approach "<selected approach name>" \
     --appetite "<appetite>" \
     --content "<full shaping write-up>"
   ```

## Step 4 — Auto-plan stories (if needed)

Check if stories exist in `.mantle/stories/issue-{NN}-story-*.md`.

**If stories already exist**, read them and report:
> **Stories:** {count} stories already planned. Proceeding to implementation.

**If no stories exist**, auto-decompose the issue:

1. Read the shaped issue, product design, system design, and existing codebase
   patterns (scan `src/` and `tests/` for conventions).
2. Break the issue into session-sized stories following these rules:
   - Each story touches 1-3 implementation files (not counting tests)
   - Stories build on each other: foundation → next layer → user-facing layer
   - Tests are part of the same story as the code they test
   - Each story has: title, user story, approach, implementation details, tests
3. Report each story briefly:
   > **Story {S}:** {title}
   > - Files: {file list}
   > - Tests: {test count} test cases
4. Save each story via CLI:
   ```bash
   mantle save-story \
     --issue <issue_number> \
     --title "<story title>" \
     --content "<full story body>"
   ```
5. After all stories are saved, verify acceptance criteria coverage:
   - Each criterion must be covered by at least one story
   - If gaps exist, create additional stories to fill them

Report:
> **Stories planned:** {count}
> **Acceptance criteria coverage:** {covered}/{total}

## Step 4b — Load relevant skills

After stories are planned, ensure the right vault knowledge is available for
implementation.

1. **Auto-detect existing skills**: Run `mantle update-skills --issue {NN}` to
   scan the issue and stories for references to vault skills and update
   `skills_required` in `state.md`.

2. **Identify skill gaps**: Read the issue and stories to identify key
   technologies, patterns, and domains involved. List the vault skills in
   `.mantle/state.md` `skills_required`. For each technology or domain
   referenced in the stories that does NOT have a matching vault skill:

   - Report the gap:
     > **Skill gap detected:** {technology/pattern} — no vault skill found.
   - Create a stub skill so it can be fleshed out later:
     ```bash
     mantle save-skill-stub --name "<skill name>"
     ```
   - Add the new skill name to `skills_required` via:
     ```bash
     mantle update-skills --issue {NN}
     ```

3. **Load existing skills**: For technologies that DO have vault skills, those
   skills are already compiled into `.claude/skills/` and will be available to
   the story-implementer agents. Run `mantle compile --force` to ensure the
   latest skills are compiled.

4. Report skill status:
   > **Skills loaded:** {list of matched skills}
   > **Skill gaps (stubs created):** {list of new stubs, or "none"}

## Step 5 — Implement stories

Follow the same implementation pattern as `/mantle:implement`:

For each story that is not "completed", in order:

1. **Check for blockers**: If blocked, stop and report.
2. **Mark in-progress**: `mantle update-story-status --issue {N} --story {S} --status in-progress`
3. **Spawn story-implementer agent**: Provide full story content, issue context,
   system design, and learnings.
4. **Verify tests**: Run the project's test command after each agent completes.
5. **Retry on failure**: One retry with error context.
6. **Handle outcome**:
   - Pass: atomic git commit `feat(issue-{N}): {story title}`, mark completed
   - Fail after retry: mark blocked, stop the pipeline

Report progress after each story:
> **Story {S}:** {title} — {completed/blocked}

## Step 5b — Simplify

If all stories completed, run a simplification pass on the implemented code
to remove AI-generated bloat before verification.

1. Run `mantle collect-issue-files --issue {NN}` to get the list of files
   touched by this issue.
2. Run the project's test suite as a baseline.
3. For each code file, spawn an Agent (`subagent_type: "implementer"`) to
   review and simplify, applying the LLM Bloat Pattern Checklist:
   - Unnecessary abstractions, defensive over-engineering, code duplication
   - Unnecessary conditionals, dead code, comment noise
   - Slop scaffolding, over-parameterisation
4. Run tests again after simplification.
   - If tests pass: commit as `refactor(issue-{NN}): simplify implementation`
   - If tests fail: revert with `git checkout -- .` and report.

Report:
> **Simplification:** {files simplified}/{files reviewed} files changed

## Step 6 — Auto-verify

If all stories completed, run verification:

1. Read the verification strategy from `.mantle/config.md` (or per-issue
   override from the issue frontmatter).
2. If no strategy exists, use a sensible default: run the test suite and check
   each acceptance criterion against the implementation.
3. For each acceptance criterion:
   - Run relevant tests
   - Read implementation code to confirm behaviour
   - Check that files exist or contain expected content
   - Record Pass/Fail with detail

Report:
> ## Verification Report — Issue {NN}
>
> | # | Criterion | Result | Detail |
> |---|-----------|--------|--------|
> | 1 | {criterion} | Pass/Fail | {detail} |
>
> **Overall: {PASSED | FAILED}**

**If all pass**: Transition to verified:
```bash
mantle transition-issue-verified --issue <N>
```

**If any fail**: Report failures and stop. Do NOT transition.
> {count} criteria failed. The pipeline has stopped.
> Fix the issues and re-run `/mantle:build --issue {N}` to resume.

## Step 7 — Pipeline summary and handoff

Report the full pipeline run:

> ## Build Pipeline Complete — Issue {NN}
>
> | Stage | Result |
> |-------|--------|
> | Shape | {auto-shaped / pre-existing} |
> | Stories | {count} planned |
> | Implementation | {completed/blocked} stories |
> | Verification | {PASSED / FAILED} |
>
> **Total commits:** {count}
> **Time in pipeline:** {rough duration}

**If verification passed:**

> **Recommended next step:** `/mantle:review` — human review of acceptance
> criteria. This is the one checkpoint that matters.
>
> After review: `/mantle:retrospective` to capture learnings.

**If verification failed or stories blocked:**

> **Pipeline stopped.** Fix the issues listed above and re-run
> `/mantle:build --issue {N}` to resume from where it left off.
> Stories already completed will be skipped.
