# Wazzap Go

> Phase 4 of /wazzap — write a concrete execution plan and offer handoff to an available executor (inline, executing-plans, GSD, BMAD, or close as decided). Use when the user invokes /wazzap:go or 'let's go'.

- Skill: `enw/wazzap-go` (Agent Skill)
- Install (CLI): `npx skillmds@latest add enw/wazzap-go`
- Raw SKILL.md: https://api.skillmd.com/api/skills/enw/wazzap-go/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: enw (https://skillmd.com/u/enw)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/enw/wazzap-go

---


# `/wazzap:go` — "Let's go!"

Phase 4 of 4. **Mode: plan one-shot, then offer execution handoff.** Turn the chosen approach into a concrete plan that any executor (you, an agent, a teammate, future-you) can pick up. Then ask how it should be executed.

## Goal

Produce `go.md` — a complete, executor-agnostic plan — and update the manifest. Optionally hand off to an available execution path. Never force inline execution.

## Preconditions

1. Read parent `SKILL.md`.
2. Resolve active decision; read `up.md`, `real.md`, `approaches.md`.
3. **Soft-gate check:** if no `chosen_approach` in manifest, warn ("No approach chosen yet. `:go` typically follows `:approaches`. Continue with the user's instruction anyway?"). Allow override.

## Steps

1. **Read context.** Pull the chosen approach from `approaches.md` and the success criteria from `real.md`.

2. **Draft the plan as vertical slices, not flat steps.** Each slice is a self-contained deliverable that:
   - **Cuts top-to-bottom** — exercises every layer the slice touches (data → logic → interface; or for non-software decisions: stakeholder → action → feedback). Never "all schema then all API then all UI then integrate."
   - Has a **user-observable outcome** — something you (or a stakeholder) can see, measure, or learn from when the slice lands.
   - Is **shippable / verifiable / learnable independently** — if you stopped after this slice, the work-to-date still has integrity and produced learning.
   - Aim for **2–5 slices**. 1 slice = not actually sliced. 8+ = slices too small or padded.

   **Each slice has:**
   - A **stable handle** — `S1`, `S2`, `S3`... (used as the ticket key during handoff).
   - A **name** — short and outcome-shaped ("Auth lands on staging", not "Build login form").
   - A **user-observable outcome** — what's true after this slice that wasn't before.
   - **Serves success criteria** — which criteria from `real.md` (by name or quoted snippet) this slice moves the needle on. **Every slice must trace to ≥1 success criterion.** If it can't, ask why it's in the plan.
   - **Estimated cycle** — hours / days / weeks in plain language.
   - **Steps inside the slice** — verbs + acceptance checks + owner + dependencies, numbered `S1.1`, `S1.2`, etc.
   - **Slice deliverable** — the thing you can demo / point at / learn from when the slice is done.

   **For non-software decisions** (career, relationship, business strategy): a "slice" is the smallest end-to-end thing you can do *this week* to learn something real. Same principle, different vocabulary.

3. **Write the rest of the plan doc:**
   - **Recovery move** — if this goes wrong mid-execution, what's the fallback?
   - **Success criteria** — copied from `real.md` for traceability.
   - **Live open questions** — only the ones that DON'T block step 1 from starting (block-the-start questions belong back in `:real`).
   - **Out of scope** — what this plan deliberately does not handle (forward links to follow-up wazzaps, tickets, etc).

4. **Show the plan to the user.** Ask: *"Plan looks good? Edit, or ready to execute?"*. Apply edits.

5. **Detect available execution paths.** Check what's available in the current session:
   - **Inline** — agent executes step-by-step in this same chat. Always available.
   - **`superpowers:executing-plans`** — if the skill is listed in `available_skills`. Best for multi-step coding work with review checkpoints.
   - **GSD** — if `.planning/gsd/` exists in the repo, or skills like `gsd-executor` are available. Best for phased engineering work.
   - **BMAD** — if `.claude/skills/bmad-*` exist or `bmad-dev-story` is in `available_skills`. Best for spec-driven development cycles.
   - **External / manual** — user will execute outside this session (write a ticket, talk to someone, etc.). Always available.
   - **Close as decided** — no execution will happen here; just close the manifest.

6. **Write `go.md`.** (See template.)

7. **Offer handoff** — show only paths that are actually available:

   ```
   Plan written: <N> slices.
   How do you want to execute?
     1. Inline — I'll start S1 step-by-step and check in after each acceptance check.
     2. superpowers:executing-plans — hand the plan (or a single slice) to that skill in a fresh session.
     3. GSD — kick off /gsd:plan-phase per slice (1 slice = 1 phase).
     4. External — you'll handle execution; I can draft GH/Linear issues per slice if you want.
     5. Close as decided — record the plan but don't execute.
   ```

   Skip lines for paths that aren't available. If user picks **External**, offer to draft 1 issue body per slice (title + body lifted from the slice section + back-link to go.md).

8. **Update manifest** based on user's handoff choice:
   - **Inline / executing-plans / GSD / BMAD** → `status: executing`
   - **External** → `status: executing`, `notes` adds "executing externally"
   - **Close as decided** → `status: decided`
   
   In all cases: `current_phase: go`, append `go` to `completed_phases`, bump `updated_at`.

9. **Execute or hand off** per user's choice. If inline: start step 1 and check in after each step's acceptance check.

## `go.md` template

```markdown
# Plan (Phase 4)

**Slug:** `<slug>`
**Drafted:** <ISO timestamp>

## Chosen approach

**<option name>** (from `approaches.md` — Option <N>)

> <one-line pitch from approaches.md>

## Plan — vertical slices

The plan is organized into shippable slices. Each slice cuts top-to-bottom and produces an observable outcome. Steps live inside slices, never outside them.

### S1 — <slice name (outcome-shaped, e.g. "Auth lands on staging")>

**User-observable outcome:** <what's true after this slice that wasn't before>
**Serves success criteria** (from `real.md`): <criterion 1>, <criterion 3>
**Estimated cycle:** <hours / days / weeks>

| #     | Step           | Owner | Deps | Acceptance check         |
|-------|----------------|-------|------|--------------------------|
| S1.1  | <verb + obj>   | self  | —    | <how you know it's done> |
| S1.2  | ...            | agent | S1.1 | ...                      |

**Slice deliverable:** <what you can demo / measure / show after S1 done>

### S2 — <slice name>

**User-observable outcome:** ...
**Serves success criteria:** ...
**Estimated cycle:** ...

| #     | Step | Owner | Deps      | Acceptance check |
|-------|------|-------|-----------|------------------|
| S2.1  | ...  | ...   | S1        | ...              |
| S2.2  | ...  | ...   | S2.1      | ...              |

**Slice deliverable:** ...

### S3 — ...

[repeat shape for each slice; 2–5 slices total]

## Why these slices in this order

<2–4 sentences. Why is S1 first? What does shipping S1 alone teach you / prove / unlock for S2? If S3 is risky, why is it last?>

## Recovery move

**If this goes sideways at step <N>:** <fallback action — undo, escalate, pause, switch to alternate option from `approaches.md`>

## Success criteria

(carried from `real.md`)

- <criterion 1>
- <criterion 2>

## Live open questions

These don't block step 1 — flag if any escalate to blockers:

- <question, plus what would resolve it>

## Out of scope

- <thing this plan does NOT do>
- <forward link to a future wazzap or ticket if applicable>

## Issue / ticket mapping

When filing tickets (GitHub Issues, Linear, Jira, etc.) — **one slice = one issue.** Never split a slice across multiple issues; never bundle multiple slices into one issue. The slice handle is the ticket key.

| Slice | Issue title | Tracking link |
|-------|-------------|---------------|
| S1    | <name>      | <#123 / URL — fill when filed> |
| S2    | <name>      | —             |
| S3    | <name>      | —             |

Each issue body should be the slice's section copied from this doc, plus a back-link to `<wazzap-folder>/go.md`. That's the audit trail: anyone reading the issue knows which decision it came from.

## Execution handoff

**Path chosen:** <inline | superpowers:executing-plans | GSD | BMAD | external | close-as-decided>

**Started:** <ISO timestamp, or "—" if close-as-decided>

**Notes:**
<e.g. "Handed off to executing-plans in fresh session 2026-04-28 16:00", or "Closed as decided — will execute when bandwidth allows", or "External: filed S1 as GH#123, S2 as GH#124">
```

## Revisits (re-running `:go` later)

Common reason: the plan didn't survive contact with reality and needs a redo. Append, don't overwrite:

```markdown
---
## Revisited <ISO timestamp>

**Trigger:** <what made the original plan stop working>

### Plan (this round)
[new table]

### What changed since last round
- ...

### Execution handoff (this round)
...
```

Manifest: append to `revisits[]`, keep `current_phase: go`, optionally update `status`.

## Done state — closing out

When execution genuinely completes (not when the plan is written — when the work is done):

1. Update manifest: `status: done`, fill `notes` with the outcome (1–3 sentences).
2. Optionally fill `linked_commits`, `linked_prs`, `linked_pm_state`.
3. If user explicitly walked away mid-execution: `status: abandoned`, set `status_reason` (required).

If the user invokes `/wazzap:go` on a `done` decision, treat as a revisit (probably needed a follow-up).

## Output to user (after writing the plan, before handoff)

```
✓ go.md written.

Plan: <one-line summary, e.g. "5 steps, 2 owners, ~3 days">

How do you want to execute?
  1. Inline (right now, step-by-step)
  2. <other available paths>
  3. External (you'll handle it)
  4. Close as decided (no execution here)
```

## Output after handoff

For **inline**:
```
Starting step 1: <step description>.
Owner: <owner>. Acceptance: <check>.
[proceeds to do step 1]
```

For **handoff to another skill**:
```
✓ Manifest updated: status=executing, path=<skill-name>.

Hand off to <skill> by running: <suggested command, e.g. "/executing-plans .wazzap/<slug>/go.md">
```

For **external**:
```
✓ Manifest updated: status=executing (external).
Recorded that execution is happening outside this chat. When done, run /wazzap:resume <slug> and tell me how it went.
```

For **close as decided**:
```
✓ Manifest updated: status=decided.
Plan saved. When you're ready to execute, /wazzap:resume <slug>.
```

## Why vertical slices

**Vertical slice =** a thin top-to-bottom cut that delivers a real, observable outcome. The opposite is **horizontal slicing** — building all the schema, then all the API, then all the UI, then integrating at the end.

Why vertical wins:
- **Surfaces risk early.** Integration problems show up in S1, not after the budget is gone.
- **Keeps the audit trail honest.** Each slice ships → each slice teaches you something → revisits in `:real`/`:approaches` happen with real evidence, not assumptions.
- **Enables clean handoff.** One slice = one issue = one PR = one reviewable unit.
- **Survives interruption.** If the work pauses after S1, S1 still has standalone value.

For non-software decisions, the same logic: "Don't plan all the conversations, then all the decisions, then all the announcements. Have *one* small end-to-end conversation, learn from it, then plan the next."

## Anti-patterns to avoid in `:go`

- ❌ **Horizontal slicing.** "Set up the database, then build the API, then build the UI." Hides risk, forces big-bang integration, and breaks the audit trail. Always slice vertically.
- ❌ **Slices that don't trace to success criteria.** Every slice must move at least one criterion from `real.md`. If it doesn't, ask why it's in the plan.
- ❌ **Slices that aren't independently shippable.** If S2 can't be deployed/demoed without S3, it's not actually a slice — it's a step that belongs inside S1 or merged with S2.
- ❌ Vague steps ("set up the thing"). Every step inside a slice needs a verb and an acceptance check.
- ❌ Skipping the recovery move. "What if this goes wrong?" is part of the audit trail.
- ❌ Listing every possible execution path regardless of availability. Detect first, offer second.
- ❌ Forcing inline execution. The user gets to choose how to execute.
- ❌ Marking `status: done` when the plan is written but the work isn't. `done` means the work is finished.
- ❌ Bundling multiple slices into one issue or splitting one slice across multiple issues. Breaks 1:1 traceability.
- ❌ Throwing away the chosen approach's nuances. The plan should reflect *why this approach* — call out the conservative/adjacent/bold flavor when relevant.

## Self-check before finishing

- [ ] Plan is organized as 2–5 vertical slices with stable handles (`S1`, `S2`, ...).
- [ ] Each slice has: name, user-observable outcome, success-criteria links, estimated cycle, steps with verbs+acceptance checks, slice deliverable.
- [ ] **Every slice traces to ≥1 success criterion** from `real.md`.
- [ ] Each slice would still have value if execution stopped after it (independently shippable).
- [ ] "Why these slices in this order" is filled.
- [ ] Recovery move is named.
- [ ] Issue/ticket mapping table is present (filled later when issues are filed).
- [ ] Out-of-scope is filled (or explicitly "—").
- [ ] Execution handoff section is filled with the chosen path.
- [ ] Manifest updated: `current_phase: go`, `completed_phases` includes `go`, `status` reflects handoff choice, `updated_at` bumped.
- [ ] If inline execution started: first slice's first step's acceptance check verified before moving on.