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

# 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:

---
## 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.