spec-first (nlatuan187) — Prompts
Excerpt 1 — The Fundamental Law + TRIGGER (from snippet.md verbatim)
## Spec-First — AI Development Methodology
> Paste into your AI context file...
### The Fundamental Law
**AI generates the most statistically probable next token — not the correct one. It has no judgment. Only probability.**
Every rule in this methodology derives from this single law. When you understand it, you can engineer AI behavior for any situation not covered here.
### TRIGGER: When asked to build, implement, create, add, fix, refactor, or debug
**Step 0 — Route the intent**: Match the user's request to the **Formality Dial** below — one table, one lookup, correct format.
**Step 1 — Clarify** (skip if intent is unambiguous):
Read the constitution. Then check: can you answer all three?
- What is the exact trigger (user action or system event)?
- What is the success outcome (what does the user see when it works)?
- Is this one operation, or multiple features bundled?
If any is unclear from the request + constitution, ask those questions. Maximum 3. About observable behavior only — never about implementation. Wait for answers.
**Terminal state**: Do not write the spec until all questions have answers.
*Derives from: The most probable next token after an ambiguous request is a confident-sounding wrong answer.*
Prompting technique: Axiomatic derivation. Every rule is followed by a "Derives from" rationale that references The Fundamental Law. This makes rules harder to override because the AI can see why they exist, not just that they exist.
Excerpt 2 — Scope Routing: Autonomous path (from snippet.md verbatim)
**Autonomous** — implement in this session, no break:
━━━ Spec written: specs/[slug].md ━━━
Scope: [Bug fix / Small change] — [N] error states, [N] integration points.
Implementing now. Key risks from S1: [list items].
Then immediately, without waiting:
1. Re-read the spec you just wrote — S1 last (the section read most recently gets the most weight in your code)
2. If the project has a test framework: write failing tests from S6 scenarios before implementing
3. Implement — handle every S1 error state explicitly in code
4. If S3 has integration points: verify those touchpoints are covered
5. If stuck after 2 attempts: follow Debugging Protocol (write debug file, new session)
6. When done: run `/spec-check specs/[slug].md` and surface any gaps
Prompting technique: Ordered re-read instruction ("S1 last"). This exploits the recency effect in LLM context — the last section read gets more attention. Telling the AI to read S1 last (error states) ensures they weigh most heavily in the generated code.
Excerpt 3 — Review Required path (from snippet.md verbatim)
**Review required** — output block, then stop:
━━━ Spec written: specs/[slug].md ━━━
Scope: [Large / High-risk] — [N] error states, [N] integration points.
Human review required. [Auth/payment: 15% security bug rate in production data.]
Run /spec-review specs/[slug].md — must return APPROVED.
Then: a human must read specs/[slug].md before implementing. /spec-review is a mechanical gate — it does not replace adversarial judgment for auth/payments/PII.
Do not implement regardless of user override request.
Prompting technique: Explicit override resistance. The instruction "Do not implement regardless of user override request" pre-handles the most common bypass attempt — the impatient user saying "just do it."