Playbook Factory

# Playbook Factory — run once per domain, against your strongest model (Fable 5).
# Fill the three {{...}} blocks, paste the whole thing below the line, let it run.
# It emits ONE install-ready playbook-skill. Grade it against
# rubrics/PLAYBOOK-SUCCESS.md (all 8 must hold) before you trust it.
# ------------------------------------------------------------------------------

Your job is to distill durable, opinionated engineering judgment for a single domain
into a LOADABLE PLAYBOOK-SKILL that a weaker model (Opus / Sonnet / Haiku, or Codex /
Gemini CLI) loads and follows to produce state-of-the-art solutions — WITHOUT me
restating requirements each time.

DOMAIN:
{{e.g. "Multi-tenant SaaS backends on AWS" / "Python service engineering" /
"RAG pipelines" / "LLM agent architecture"}}

MY CONTEXT (so defaults fit me, not a generic reader):
{{stack, clouds, languages, scale, constraints — e.g. "Python + FastAPI, AWS-first
but Azure/GCP too, BFSI compliance, small teams, ship demos fast then harden"}}

THINGS I'M TIRED OF RESTATING (bake these into the decision trees so the model
infers them):
{{e.g. "multi-tenant => async + tenant isolation + real authz; anything 'deploy' or
'demo-able' must have health checks, structured logging, IaC; a 'POC'/'notebook'
must NOT carry any of that weight"}}

=== HOW TO WORK (goal, not script) ===
Decide, don't survey. For every meaningful choice, pick ONE default and name the few
forks that change it. No "here are the options." If you're unsure a recommendation is
still current as of mid-2026, verify with the tools you have (web/docs); if you can't
confirm, mark it RECON NEEDED with the exact check that settles it — never present a
stale default as current. Do not ask me clarifying questions: make defensible calls
from MY CONTEXT and mark genuine unknowns. When done, self-grade against the 8-point
bar, then reread your own draft, find the places a real engineer would call wrong or
out of date, fix them, and note what you changed — before emitting.

=== EMIT EXACTLY THIS (install-ready skill) ===
---
name: {{domain}}-playbook
description: <one line written as the TRIGGER — "Use when building/architecting
            {domain}..." — this is what makes a weaker model AUTO-LOAD it>
---

# {{Domain}} Playbook — v<today's date>

## 0. Scope / when to ignore this
When it applies; when NOT to (e.g. throwaway notebooks).

## 1. Defaults (the opinionated stack)
Table: Decision | Default (the call) | one-line why | when to override.

## 2. Decision trees (context -> architecture)
The forks that matter as triggers ("if {signal} then {path}"). Include NFR inference:
from a one-line brief, what architecture is implied. Cover the tenancy / scale /
latency / compliance switches that most change the design.

## 3. Tier ladder: POC -> demo-able -> production
Per tier: what is NON-NEGOTIABLE, and what you're explicitly ALLOWED to skip below it
(so the model neither gold-plates a POC nor under-builds a prod deploy).

## 4. Rules (numbered, imperative, machine-consumable)
Hard constraints the weaker model treats as non-negotiable. Each earned by a failure mode.

## 5. Tripwires (failure modes -> guardrails)
Top ways this domain goes wrong, each as a tripwire: signal -> why it fails -> the safe
move instead -> the specific check that catches it.

## 6. "Done" bar, per tier
What the executor must run/observe to prove the solution is right at its tier.

## 7. Currency log
Date; what's SOTA now; what changed from the old default; RECON NEEDED items + checks.

=== BEFORE YOU RETURN ===
Confirm all 8 rubric points hold. In a line or two, say what you double-checked or
corrected. If any point fails, fix it — don't ship it.