Go No Go

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

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 checks are below. Users override or add to these via ~/.go-no-go/config.yml (see templates/config.yml).

Check 1 — Differentiation

Can a competent operator clone 80% of this in 2 weeks?

• PASS condition: structural moat (proprietary asset / exclusive relationship / regulatory advantage / network effect / data accumulation)
• FAIL condition: effort-based ("I'll work harder") or taste-based ("my version will be better") moat only

Check 2 — Audience–Market Fit

Who pays for this? Who follows your work?

• Estimate income/budget bracket for both
• PASS: within ~2–3× of each other
• FAIL: more than 3× apart

Demand strength does not compensate for audience–market mismatch.

Check 3 — Acquisition Channel

Where do the FIRST 100 customers/users come from? Be specific.

• PASS: confirmed warm channel with named reach
• PASS: shipped track record on a specific platform that this audience reads
• PASS: named partner with confirmed introductions
• FAIL: "I'll post on social media" (without specific hook + 90-day cadence)
• FAIL: "Build it and they will come"
• FAIL: Marketplace as discovery (Gumroad / App Store / Etsy are checkout, not traffic)

Check 4 — Capacity

Which capacity does this require? Do you have it free?

Capacities: creative · analytical · operational · social · executional.

• PASS: required capacity is in user's currently-available set
• FAIL: required capacity is currently saturated
• HARD LIMIT: max 2 parallel projects requiring the same capacity type

Check 5 — 7-Factor Wedge

For each factor, mark PASS or FAIL:

1. asset_match — leverages an existing asset you own?
2. day_zero_warm_channel — specific source for first 100 users?
3. domain_authority_fit — your reputation transfers to this domain?
4. solo_executable — you can ship V0 alone in < 30 days?
5. moat_compounds — does the moat strengthen with usage?
6. cash_horizon — break-even < 12 months OR funded by an independent stream?
7. exit_optionality — can you stop in 30 days with reusable salvage?

Any 2 factors fail → AUTOMATIC NO-GO.

Step 5: Enthusiasm Detector → 24-Hour Pattern Interrupt

Scan the conversation for enthusiasm-high signals:

• "I'm so excited"
• "I just want to start"
• "let's go" / "let's do this"
• "I can already see how this works"
• "This is genius"
• User skipping or rushing through framework checks
• User rationalizing every NO

If detected:

PATTERN INTERRUPT TRIGGERED.

Enthusiasm signal: HIGH.
This is NOT a NO. This is a PAUSE.

Action:
- Draft the commitment doc now (Step 6).
- Save it to runs/<YYMMDD-HHMM>-go-no-go-<slug>/draft.md
- Tomorrow at this time, re-open it and answer:
  1. Re-read the draft. Still want to commit?
  2. What did you forget yesterday that you remember now?
  3. Which framework check feels weaker now than yesterday?

Only after that will Step 7 confirmation run.

This step is configurable but on by default. The cooldown duration is pattern_interrupt.cooldown_hours in config (default 24).

Step 6: Write the Commitment Doc

This is the public artifact. The full template lives in templates/commitment.md. Required sections:

• Date, decision (GO / NO-GO / PAUSED)
• What I'm doing (one sentence, no buzzwords)
• Why I'm doing this (actual reason, not rationalized)
• Kill criteria — pre-mortemed BEFORE the start:
  • D14 metric + threshold
  • D30 metric + threshold
  • D60 metric + threshold
  • D90 hard-sunset review
• What I'm explicitly NOT doing (out of scope)
• 5 specific failure modes (pre-mortem)
• What I'll tell people who ask why I'm doing this
• What I'll tell people IF this fails (pre-written post-mortem narrative)
• Pre-flight check results (with reasons)
• Override section (if any check failed but going anyway)
• Public commitment checklist (when posted, where)
• Signature