/go-no-go

name: go-no-go
description: Use BEFORE any spec, plan, or code exists — the Stage 0 gate that decides whether a project should start at all. NO-GO is the default. GO requires passing five framework checks (Differentiation · Audience–Market Fit · Acquisition Channel · Capacity · 7-Factor Wedge), a memory check against your own prior attempts, and a 24-hour pattern-interrupt if enthusiasm-high is detected. Output is a public commitment artifact with pre-mortemed kill criteria (D14/D30/D60/D90 review gates). Triggered by "/go-no-go [project]", any "I want to build / start / take on X" intent, or before opening any new repo or signing any new contract. Pairs with spec-driven-dev (this is Stage 0, that is Stage 1).

Go / No-Go — Stage 0

> **NO-GO is the default. GO requires evidence.**

Most AI coding skills help you build. This one helps you **not** build.

Half the cost of solo work is starting the wrong thing. Once a repo exists, sunk cost and identity-protection make it hard to quit. So you grind 3–6 months before admitting the start itself was wrong.

`go-no-go` is the gate before any `/spec`, `/plan`, `/build`. It runs five framework checks (configurable), a memory check against your own past attempts, and a 24-hour cooldown if your enthusiasm is too high. The output is a public commitment doc with pre-mortemed kill criteria. If anything fails, the default is NO-GO.

It is a deliberately **stronger** instrument than a generic intent-extraction interview: it stores memory, fails by default, requires structural overrides, and produces a dated artifact you publish.

When to Use

Run `/go-no-go` when:

• You catch yourself thinking "I should build X" / "I want to start Y" /

"I should take on Z client"

• Before opening any new git repo
• Before signing any client contract or partnership
• Before any commitment with attention budget > 14 days
• Before invoking `/spec`, `/plan`, or `/build` on a **new** thing
• When you feel sudden enthusiasm — *especially* then

When NOT to Use

• Continuing existing committed projects (use `/spec` directly)
• Tactical pivots within an already-confirmed project
• Pure information requests ("how does X work?")
• Daily journaling or routine work
• Reactive content (writing about a news event, not a project commitment)
• One-off tasks under ~4 hours

How It Differs From Other Pre-Build Skills

| | Plain intent interview | `go-no-go` | |---|---|---| | Default outcome | Continue | **NO-GO** | | Memory of past attempts | None | **Mandatory pre-flight search** | | Framework checks | Generic restate | **5 fail-by-default gates** | | Time gate | None | **24h pattern-interrupt** if enthusiasm-high | | Output | Confirmed restate | **Public commitment doc** with kill criteria | | Override semantics | "Yes/no" | **Structured override with named reason** | | Lifecycle | One session | **D14/D30/D60/D90 review schedule** | | Composability | Standalone | **Stage 0 of any SDLC** (pairs with spec-driven-dev) |

If your situation calls for a softer instrument, use a generic intent interview. If you have a pattern of starting and not finishing, use this.

Loading Constraints

• Needs a live, responsive user — **do not invoke in CI, scheduled runs,

`/loop`, or autonomous loops**

• Needs read/write access to the configured memory store (default:

`~/.go-no-go/journal.md`)

• Needs at least one prior journal entry OR an explicit "first run"

acknowledgment from the user

The Eight Steps

Step 0: Pre-flight Memory Check (MANDATORY)

Before asking anything, search the configured memory store for prior similar attempts.

PRE-FLIGHT:
- Topic: <extracted from user pitch>
- Searched: <memory store path>
- Found N prior similar attempts:
  - <date> <name> → <outcome>
  - <date> <name> → <outcome>

If `N ≥ 1`, state explicitly:

> "You attempted [similar X] in [date]. It ended because [reason from journal]. > **What is structurally different this time?**"

Wait for an answer. Reject these answers as non-structural:

• "I'm older / wiser now"
• "I'll try harder this time"
• "I learned my lesson"
• "I have more discipline now"

Accept these as structural:

• "The market changed — specifically: [verifiable change]"
• "I have a new asset — specifically: [named asset]"
• "I have a partner now — specifically: [named partner with role]"
• "I'm not solo anymore — specifically: [team of N]"

If the answer is non-structural → **automatic NO-GO**. Document the attempted override in the commitment doc so the user can see they tried.

Step 1: Hypothesis with Confidence Number

Write one sentence describing what you think the user wants, with an honest confidence number.

HYPOTHESIS: You want to <restated intent>, and you reached for <stated approach>
            because <conventional reason>.
CONFIDENCE: ~XX%

The number forces honesty. If you can't predict the user's reaction to the next three questions you'd ask, lower the number.

Step 2: One Question at a Time, Each with a Guess

Format:

Q: <focused question>
GUESS: <your hypothesis for the answer, with reasoning>

Wait for the user before asking the next. Why one-at-a-time, why guess attached:

• Reacting to a wrong guess is faster than generating from scratch
• Batching encourages skim-answers
• Each guess commits you to a hypothesis you can be visibly wrong about

Step 3: Listen for "want vs. should-want"

Watch for buzzword answers ("scalable", "modern", "robust", "clean") and convention-talk ("the standard approach", "best practice"). The wildcard question, used when you hear those:

> *"If you didn't have to justify this to anyone — not even your future self > on Twitter — what would you actually want?"*

That one question often surfaces more than the previous five.

Step 4: The Five Mandatory Framework Checks

Run all five. **Any FAIL = automatic NO-GO** unless the user explicitly overrides with a named structural reason (recorded in commitment doc).

The default ch