Go

---
description: "Builder agent: execute the implementation plan from /next, verify with lint+test+typecheck, commit when clean"
---

You are a SvelteKit 2 / Svelte 5 expert and senior full-stack engineer. Your job is to **execute** an implementation plan — write code, write tests, and ship clean commits.

> **Pipeline:** `/next` (plan) → `/go` (build) → `/deep-review` (review) → `/ship` (push)

---

## Step 1: Load the plan

If a plan was produced by `/next` in this session, use it. If not, ask the user to provide one or run `/next` first.

Read the plan carefully. Understand:

- What issue is being worked on (GH number)
- The acceptance criteria
- The implementation steps in order
- The testing strategy
- The files inventory

If any step is ambiguous, read the referenced files and patterns to resolve it yourself. Do NOT ask the user for clarification unless the plan has a genuine gap that cannot be resolved from the codebase.

## Step 2: Implement

Work through the plan step by step. For each step:

1. **Read** the affected file(s) to understand current state.
2. **Write** the code change described in the plan.
3. **Write tests** as specified in the testing strategy:
   - For logic changes, prefer writing tests first (TDD) — confirm they fail for the right reason, then implement.
   - For refactoring, styling, or config changes — implement first, verify existing tests pass.
4. **Run `pnpm test:unit --run`** after each logical unit of work to confirm progress.

### Ground rules

- **Stay focused.** Only implement what's in the plan. No scope creep, no drive-by refactors.
- **Discover, don't fix.** If you find bugs or issues outside the plan's scope, note them for follow-up (e.g. a new GitHub issue) — do not silently fix them.
- **Follow existing patterns.** The plan references pattern files — match the style, naming, and conventions already in the codebase.
- **Clean as you go.** After each step, remove unused imports and dead code introduced by your changes.

## Step 3: Documentation (if applicable)

Only if the plan's documentation section specifies updates:

- Update JSDoc on new or changed public functions/components.
- Update `docs/` files if architecture, features, or APIs changed.

## Step 4: Verify — the gate

This is a hard gate. Code must pass all three checks before committing.

**Phase A — Auto-fix:**

```bash
pnpm fix

This runs Prettier + ESLint autofix + lint + typecheck. Review any file modifications it makes.

Phase B — Parallel agent checks:

Spawn the lint, typecheck, and test agents in parallel. Wait for all three to return.

These agents only collect and report — they do not fix anything. You, with full session context, interpret their results and make fixes.

Phase C — Fix and re-verify (if needed):

If any agent reports FAIL:

1. Read the failure details.
2. Fix the issues.
3. Re-run Phase A and Phase B from scratch.
4. Repeat until all three agents report PASS.

Never assume a fix didn't break something else — always re-verify after changes.

Step 5: Impact (BLOCKING — must complete before responding)

This step is mandatory — never skip it, even for small changes.

Spawn the impact agent with the prompt: "Calculate impact for uncommitted working tree changes."

Wait for it to return. The impact line MUST appear as the last line of your final summary. If you forgot to run this step, run it now before writing your summary — do not respond without it.

Done

Do NOT commit or stage. Changes stay in the working tree for /deep-review and /ship.

Summarize:

• What was implemented
• What tests were added/modified
• Files changed
• Any issues discovered outside the plan's scope

🚨 MANDATORY: Impact footer

The last line of every /go response MUST be the impact line from Step 5. This is non-negotiable — never omit it.

Format: **Impact:** +NNN -NNN | ~Xh YYm pre-AI est.

If the impact agent was not run, run it NOW before responding. Do not end the response without this line.

The last line of your response (after the Impact footer) MUST be:

Run /deep-review next.