Wazzap Approaches

/wazzap:approaches — "Different ways forward"

Phase 3 of 4. Mode: divergent generation + structured comparison. Generate 3 distinct approaches across different lenses so the user has a real choice — not three flavors of the same answer.

Goal

Produce approaches.md with exactly 3 named options, comparable on the same dimensions, plus a recommendation and a decision (or pending).

Preconditions

1. Read parent SKILL.md.
2. Resolve active decision; read up.md and real.md.
3. Soft-gate check: if no real.md, warn ("No real.md — :approaches without :real tends to misfire. Continue anyway?"). On proceed, write a stub real.md and continue.

The three lenses

Generate one option per lens. Distinctness is the rule — if two options are mostly the same with cosmetic differences, replace one.

If a lens genuinely produces nothing useful for this decision (rare), say so explicitly and fill with the strongest alternative — but flag it.

Steps

1. Read context. up.md for the wish; real.md for the real problem, constraints, and success criteria.

2. Draft 3 options, one per lens. For each:

   • Name (short, distinctive — "Move to JWT" not "Option 2")
   • One-line pitch
   • Description (3–6 sentences)
   • Pros (3–5 bullets, tied to the success criteria from :real where possible)
   • Cons (3–5 bullets — be honest, this is the audit trail)
   • Risks (what could go wrong, distinct from cons)
   • Rough effort (your judgment in plain language: "an afternoon", "a sprint", "a quarter", "I genuinely don't know")
   • What it requires (people, money, tools, conversations, permissions)

3. Build a comparison table. Columns: Conservative / Adjacent / Bold. Rows: Effort, Risk, Reversibility, Time-to-impact, Stakeholder cost, Alignment with success criteria. Use short cells (1–3 words).

4. Recommend one option. Lead with the recommendation, give 2–3 sentences of rationale tied to the real problem and constraints. Be honest if the lenses are genuinely close — say so.

5. Show the user. Format: comparison table first, then expanded option cards, then your recommendation. Ask: "Pick one (or hybrid two), or want me to explore further?"

6. Handle the user's response:

   • Pick → set chosen_approach in manifest, fill the Decision section in the doc.
   • Hybrid → write a 4th option labeled "Hybrid: " combining elements; set that as chosen_approach.
   • Reject all / explore further → ask what's missing, regenerate (don't just rotate). Cap regeneration at 2 rounds before stopping with chosen_approach: pending.
   • Defer → set status: thinking, write Decision: deferred until <reason/date>.

7. Write approaches.md with the chosen option recorded.

8. Update manifest: current_phase: approaches, append approaches to completed_phases, set chosen_approach, set status: decided (if user chose) or leave status: thinking (if deferred). Bump updated_at.

9. Suggest next command: /wazzap:go (if decided) or "come back when you're ready" (if deferred).

approaches.md template

# Approaches (Phase 3)

**Slug:** `<slug>`
**Generated:** <ISO timestamp>
**Real problem (from `:real`):** <one-sentence carried over>

## Comparison

| Dimension | Conservative: <name> | Adjacent: <name> | Bold: <name> |
|---|---|---|---|
| Effort | ... | ... | ... |
| Risk | ... | ... | ... |
| Reversibility | ... | ... | ... |
| Time-to-impact | ... | ... | ... |
| Stakeholder cost | ... | ... | ... |
| Alignment w/ success criteria | ... | ... | ... |

## Option 1 — Conservative: <name>

**Pitch:** <one line>

**Description:** <3–6 sentences>

**Pros:**
- ...

**Cons:**
- ...

**Risks:**
- ...

**Rough effort:** <plain language>

**What it requires:**
- ...

## Option 2 — Adjacent: <name>

[same shape as Option 1]

## Option 3 — Bold: <name>

[same shape as Option 1]

## Recommendation

**Recommended:** <option name>

<2–3 sentences tying back to the real problem and constraints. Be honest if the call is close.>

## Decision

**Chosen:** <option name OR "Hybrid: <name> (combines X from N1 with Y from N2)" OR "pending" OR "deferred until <reason>">

**Decided by:** <user>
**Decided at:** <ISO timestamp, or "—" if pending/deferred>

**Reasoning (user's words):**
<verbatim from user when they chose, or "—">

If the user picked a hybrid, add a fourth option section before the Decision block:

## Option 4 — Hybrid: <name>

**Combines:** <which elements from which options>
**Description:** ...
**Pros / Cons / Risks / Effort / Requires:** ... (same shape)

Revisits (re-running :approaches later)

If approaches.md already exists, append a new revisit section instead of overwriting:

---
## Revisited <ISO timestamp>

**Trigger:** <why we're re-exploring>

### What changed since last round
- <e.g. "New constraint from :real revisit", "Original chosen approach turned out to be infeasible">

### New options
[3 fresh options under conservative/adjacent/bold lenses]

### Comparison (this round)
[table]

### Recommendation (this round)
...

### Decision (this round)
...

Update manifest revisits[] and (if a new option is chosen) overwrite chosen_approach — but keep the old one in the prior section.

Output to user (when an option is chosen)

✓ approaches.md written.

Chosen: <option name>
Status: decided

Next: /wazzap:go to turn this into a concrete plan.

Output to user (when deferred)

✓ approaches.md written.

Decision: deferred until <reason>
Status: thinking

Resume anytime with /wazzap:resume <slug>.

Anti-patterns to avoid in :approaches

• ❌ Three options that are basically the same with renamed labels. If conservative and adjacent feel identical, push adjacent harder or be honest that adjacent doesn't apply here.
• ❌ Skipping the comparison table. The table is the audit-trail summary — without it, the doc is just three blurbs.
• ❌ Hiding cons. If the recommended option has a real downside, name it. Future-you reading this needs the honest version.
• ❌ Letting the user reject all 3 without asking what's missing. Otherwise round 2 will miss the same way.
• ❌ Generating a 4th, 5th, 6th option proactively. 3 is the cap. Hybrids only happen on user request.
• ❌ Forgetting to fill the Decision section. Even "pending" is a decision worth recording.

Self-check before finishing

• Exactly 3 options (or 4 if user requested a hybrid).
• Each option has all fields filled (pitch, description, pros, cons, risks, effort, requires).
• Comparison table is present and uses short cells.
• Recommendation is named with rationale.
• Decision section is filled (chosen / hybrid / pending / deferred — never blank).
• Manifest chosen_approach reflects the decision.
• Status is decided (chose) or thinking (pending/deferred).
• Suggested next command in output.