@thierrynakoa/fire-flow 10.0.0 → 12.2.1

package/skills-library/_general/methodology/AUTONOMOUS_ORCHESTRATION.md

@@ -0,0 +1,182 @@
+---
+name: AUTONOMOUS_ORCHESTRATION
+category: methodology
+description: Industry patterns for autonomous AI agent orchestration — Planner/Worker/Judge separation, scope manifests, DORA metrics, phase-gate hybrids, and supervised autonomy tiers
+version: 1.0.0
+tags: [autonomous, orchestration, agents, planner-worker-judge, dora, phase-gate, scope]
+sources:
+  - "Mike Mason — AI Coding Agents in 2026: Coherence Through Orchestration"
+  - "Anthropic Engineering — Effective Harnesses for Long-Running Agents"
+  - "OpenHands SDK — arxiv 2511.03690"
+  - "Google DORA — State of DevOps 2025"
+  - "Robert Cooper — Agile-Stage-Gate Hybrids"
+  - "AWS — Agentic AI Security Scoping Matrix (TBAC)"
+  - "SWE-Bench Pro — Can AI Agents Solve Long-Horizon Tasks?"
+---
+
+# Autonomous Orchestration Patterns
+
+> **Core insight:** "You don't trust; you instrument." (Boris Cherny) — Verification stays active. Verdicts auto-route to fix cycles. The human reviews the finished product, not intermediate steps.
+
+---
+
+## 1. Planner / Worker / Judge Separation
+
+The architecture that consistently outperforms alternatives in autonomous coding research:
+
+| Role | Can Do | Cannot Do | Dominion Flow Equivalent |
+|------|--------|-----------|------------------------|
+| **Planner** | Read codebase, decompose tasks, set scope | Write code, modify files | fire-planner |
+| **Worker** | Execute scoped tasks, write code | Plan, verify own work, exceed scope | fire-executor |
+| **Judge** | Run verification, read output, report findings | Fix what it finds broken, modify code | fire-verifier |
+
+**Why this matters:** The most dangerous failure mode in autonomous AI is the agent judging its own work. The worker cannot declare itself done. The judge cannot fix what it finds. This separation is load-bearing architecture, not process overhead.
+
+**Anti-pattern:** "The executor also checks if things work" — this is the worker judging itself. SWE-Bench Pro data shows agents that self-verify have significantly lower success rates than those with independent verification.
+
+---
+
+## 2. Scope Manifests (Task-Based Access Control)
+
+Every task should include a scope boundary:
+
+```yaml
+scope:
+  allowed_files:
+    - "server/routes/auth.js"
+    - "server/middleware/auth.js"
+    - "server/models/User.js"
+  allowed_operations:
+    - create_file
+    - modify_file
+    - run_tests
+  forbidden:
+    - modify files outside allowed_files
+    - install new dependencies without plan approval
+    - delete existing tests
+  max_file_changes: 5
+```
+
+**Why explicit scope:** Agents drift without manifest enforcement. Conversational instructions ("only change the auth files") are less reliable than tool-level constraints. The circuit breaker should trip if the agent attempts out-of-scope actions.
+
+**Agent action:** fire-planner includes scope in BLUEPRINT frontmatter. fire-executor reads scope before starting. fire-verifier checks that changes stayed within scope.
+
+---
+
+## 3. External Structured State > Long Context
+
+From Anthropic's engineering blog: context window amnesia is solved by structured external state, not by longer context windows.
+
+### The Pattern
+```
+Session start:
+  1. Read CONSCIENCE.md → current phase/status
+  2. Read latest WARRIOR handoff → prior session context
+  3. Read RECORD.md → what was done, what's pending
+  4. Read FAILURES.md → dead ends to avoid
+
+Session end:
+  1. Update CONSCIENCE.md → new status
+  2. Write WARRIOR handoff → structured state for next session
+  3. Update RECORD.md → what was accomplished
+  4. Commit checkpoint
+```
+
+**Why:** A 200K context window that includes irrelevant history is worse than a 50K window with precisely structured state. External state files are the memory — the context window is the working space.
+
+**Key from OpenHands:** Use an append-only event log for mutable state. When history approaches context limits, summarize old events while preserving the full log. Reduced API costs 2x with no performance degradation.
+
+---
+
+## 4. Supervised Autonomy Tiers
+
+The industry is converging on three tiers:
+
+| Tier | Risk Level | Oversight | Dominion Flow Mode |
+|------|-----------|-----------|-------------------|
+| **Human-in-the-loop** | High | Approval required before action | Manual `/fire-3-execute` |
+| **Human-on-the-loop** | Medium | Autonomous with monitoring + escalation | `/fire-autonomous` |
+| **Human-out-of-the-loop** | Low | Fully autonomous, periodic audit | Future: batch mode |
+
+**Confidence thresholds drive tier assignment:**
+- Routine tasks (boilerplate, config): 80% confidence → auto-proceed
+- Business logic tasks: 85% confidence → auto-proceed, flag for review
+- Architecture decisions: 90% confidence → require explicit approval
+
+**Industry benchmark:** Operational escalation rates above 15% indicate confidence thresholds are miscalibrated — too much is being auto-approved or too little.
+
+---
+
+## 5. DORA Metrics for AI-Assisted Development
+
+The 2025 DORA Report finding: **AI adoption improves throughput but increases delivery instability.** Faster output with more failures.
+
+| Metric | What It Measures | AI-Agent Equivalent |
+|--------|-----------------|-------------------|
+| **Deployment Frequency** | How often to production | Phases completed per session |
+| **Change Lead Time** | Commit → production | Plan → verified output |
+| **Change Failure Rate** | % of deploys causing incidents | % of phases requiring re-execution |
+| **Recovery Time** | Mean time to restore | Time from verification FAIL to PASS |
+
+**The key insight:** Optimizing throughput (more phases faster) without measuring stability (failure rate, recovery time) produces more bugs faster. Both dimensions must be tracked.
+
+**Agent action:** The autonomous log should track both: phases completed AND phases that needed retry. A session that completes 3 phases cleanly is better than one that completes 5 phases with 3 retries each.
+
+---
+
+## 6. Phase-Gate + Agile Hybrid
+
+The sweet spot for AI-assisted development:
+
+```
+MACRO: Phase-gate discipline at boundaries
+  Plan → [GATE] → Execute → [GATE] → Verify → [GATE] → Handoff
+
+  Gates are non-negotiable. The project cannot advance
+  without passing verification.
+
+MICRO: Agile flexibility within phases
+  Within Execute: iterate freely on tasks
+  Within Verify: scope-adaptive checks
+  Within Plan: explore alternatives
+```
+
+**Definition of Ready (before starting a phase):**
+- [ ] Phase requirements clear (MEMORY.md populated)
+- [ ] Dependencies from prior phase resolved
+- [ ] Scope bounded in BLUEPRINT
+- [ ] Kill conditions defined for high-risk tasks
+
+**Definition of Done (before declaring phase complete):**
+- [ ] All BLUEPRINT tasks executed
+- [ ] Verification APPROVED or CONDITIONAL
+- [ ] Review completed (no BLOCK findings)
+- [ ] RECORD.md updated
+- [ ] CONSCIENCE.md advanced
+
+---
+
+## 7. What Fails in Autonomous Mode
+
+From SWE-Bench Pro and industry analysis — failure modes to watch for:
+
+| Failure Mode | Symptom | Prevention |
+|-------------|---------|-----------|
+| **Premature termination** | Agent declares "done" before end-to-end verification | Judge must verify, not worker |
+| **Scope creep** | Agent fixes "related" issues outside scope | Scope manifest enforcement |
+| **Context overflow** | Endless file reading, losing track | Condensation + structured state |
+| **Quality degradation at scale** | More output but more bugs | Track change failure rate alongside throughput |
+| **Semantic misunderstanding** | Solution passes tests but misses the point | Verify against requirements, not just tests |
+| **Self-certification** | Agent says "looks good" without running checks | Mandatory verification gates |
+
+**The hardest failure:** Semantic misunderstanding — the agent produces code that is technically correct but doesn't solve the actual problem. Tests pass because the tests test the wrong thing. This is only caught by requirements-level verification, not code-level verification.
+
+---
+
+## When Agents Should Reference This Skill
+
+- **fire-autonomous:** Apply supervised autonomy tiers, track DORA metrics in autonomous log
+- **fire-planner:** Include scope manifests and kill conditions in BLUEPRINTs
+- **fire-executor:** Respect scope boundaries, never self-verify
+- **fire-verifier:** Independent judge role — verify against requirements, not just tests
+- **fire-5-handoff:** Structure handoff as external state for next session (not narrative)

package/skills-library/_general/methodology/BACKWARD_PLANNING_INTERVIEW.md

@@ -0,0 +1,307 @@
+---
+name: BACKWARD_PLANNING_INTERVIEW
+category: methodology
+description: Structured questioning protocol for extracting project end-state from beginners who don't know technical terminology
+version: 1.0.0
+tags: [backward-planning, interview, vision, beginners, vibe-coder]
+---
+
+# Backward Planning Interview Protocol
+
+Reference skill for `fire-vision-architect` (backward mode) and `fire-1-new` (adaptive questioning). Provides structured question sequences that extract the mission objective from users who don't know what questions to ask.
+
+> **Origin:** Military backward planning doctrine — fix the end-state first, then derive every checkpoint from it. Adapted for software project initialization.
+
+---
+
+## Mode Gate
+
+This interview activates when the user answers the mode gate question:
+
+> **"Have you already started building this, or are we starting from scratch?"**
+
+If they say "from scratch," "just an idea," or anything that reveals no existing tech context — this protocol runs. Never ask "What tech stack are you using?" — it forces beginners to bluff or freeze.
+
+---
+
+## Core Principle
+
+Beginners describe products in terms of **what they can see and do**, not in technical terms. Every question below is designed to extract a hidden technical requirement from a plain-language answer.
+
+**Never ask:** "Do you need WebSockets?" (they don't know what that is)
+**Always ask:** "Should users see changes from other people instantly, like Google Docs?" (they know exactly what that means)
+
+---
+
+## Phase 0: Visual Input (Show, Don't Tell)
+
+*Goal: Let users show what they're building instead of describing it. A picture extracts more requirements in 5 seconds than 10 minutes of questions.*
+
+### Question 0: The Visual
+> **"Do you have anything visual — a screenshot, a wireframe, a Figma link, a hand-drawn sketch, or even a photo of a napkin drawing? Drop it here and I'll extract the technical requirements from it."**
+
+*What this reveals:* UI complexity, navigation patterns, data models, feature scope — all at once.
+
+**Accepted formats:**
+| Input Type | How to Share | What Claude Extracts |
+|-----------|-------------|---------------------|
+| Screenshot of similar app | Paste image or file path | UI patterns, features to clone, complexity level |
+| Figma/design tool export | Export as PNG and share | Component hierarchy, page count, navigation flow |
+| Hand-drawn wireframe | Photo of paper sketch | Screen count, data relationships, user flow |
+| Napkin drawing | Phone photo | Core screens, rough feature scope |
+| Figma link | Share the URL (needs MCP) | Full design system, components, variants |
+| Excalidraw export | Share PNG or `.excalidraw` file | Architecture diagrams, flow charts, wireframes |
+
+**Visual Extraction Protocol:**
+
+When the user provides a visual, Claude reads the image and extracts:
+
+```markdown
+## Visual Analysis
+
+**Screens identified:** {count}
+**Screen list:**
+1. {screen name} — {what it shows}
+2. {screen name} — {what it shows}
+
+**UI Elements detected:**
+- Navigation: {sidebar / topbar / tabs / hamburger}
+- Forms: {login / signup / settings / data entry}
+- Data displays: {tables / cards / lists / charts / maps}
+- Interactive: {drag-drop / editor / canvas / video player}
+- Social: {comments / chat / feed / profiles}
+
+**Derived capabilities from visual:**
+| Visual Element | → Technical Requirement |
+|---------------|----------------------|
+| Login screen | Auth system |
+| Dashboard with charts | Data aggregation + visualization library |
+| User avatar / profile | Image upload + user profiles |
+| Chat sidebar | Real-time messaging (WebSockets) |
+| Payment/pricing page | Stripe integration |
+| Admin panel | Role-based access control |
+| Search bar | Search index (full-text or Algolia) |
+| Map view | Geolocation API + maps SDK |
+| Video player | Video hosting / streaming |
+| File list / upload area | Object storage (S3/R2/Supabase) |
+| Mobile layout visible | Responsive design required |
+```
+
+**After visual extraction:**
+- Skip any interview questions already answered by the visual
+- Use remaining questions to fill gaps the visual didn't reveal
+- Reference the visual analysis in the Capability Summary output
+
+> **Pro tip:** Even a rough sketch reveals navigation structure, screen count, and data relationships that take 5+ questions to extract verbally. Always ask for visuals first.
+
+---
+
+## Phase 1: The Walkthrough (Mission Objective)
+
+*Goal: Get the user to narrate what their finished product looks like in use.*
+
+### Question 1: The Elevator Pitch
+> **"In one sentence, what does your app do for the person using it?"**
+
+*What this reveals:* Core value proposition, primary user type, product category.
+
+| Answer Pattern | Hidden Requirement |
+|---------------|-------------------|
+| "Helps teachers manage courses" | LMS, role-based auth (teacher/student), content management |
+| "Lets people sell handmade goods" | E-commerce, payments, seller/buyer roles, product catalog |
+| "Tracks my workouts" | Personal data, mobile-friendly, charts/visualization |
+| "Connects freelancers with clients" | Marketplace, messaging, payments, reviews |
+
+### Question 2: The First 60 Seconds
+> **"A new user just signed up. Walk me through their first 60 seconds — what do they see, what do they click?"**
+
+*What this reveals:* Onboarding flow, auth requirements, initial data structure, primary navigation.
+
+| Answer Pattern | Hidden Requirement |
+|---------------|-------------------|
+| "They fill out a profile with their photo" | User profiles, image upload, storage |
+| "They see a feed of posts from people they follow" | Social graph, feed algorithm, follow system |
+| "They get a dashboard showing their stats" | Data aggregation, charts, dashboard UI |
+| "They pick a plan and enter payment" | Subscription billing, payment gateway, plan tiers |
+
+### Question 3: The Money Screen
+> **"What's the ONE screen where your app delivers the most value? Describe it like you're showing it to a friend."**
+
+*What this reveals:* Core feature complexity, data relationships, UI sophistication needed.
+
+| Answer Pattern | Hidden Requirement |
+|---------------|-------------------|
+| "A drag-and-drop board like Trello" | Complex UI interactions, state management, real-time sync |
+| "A clean editor where you write and format text" | Rich text editor (Tiptap/ProseMirror), content blocks |
+| "A map showing nearby services" | Geolocation, maps API, location-based queries |
+| "A video player with comments on the side" | Video hosting/streaming, threaded comments, timestamps |
+
+---
+
+## Phase 2: The Users (Personnel & Roles)
+
+*Goal: Discover user roles, permissions, and access patterns.*
+
+### Question 4: Who's Involved?
+> **"Besides the main user, who else uses this? Does anyone have special powers — like an admin, a manager, a teacher?"**
+
+*What this reveals:* Role-based access control (RBAC), permission tiers, multi-tenant needs.
+
+| Answer Pattern | Hidden Requirement |
+|---------------|-------------------|
+| "Just me" | Single user, no auth needed or simple auth |
+| "Users and admins" | 2-role RBAC, admin dashboard |
+| "Teachers, students, and school admins" | 3+ role RBAC, organization/tenant model |
+| "Anyone can view, only members can post" | Public/private content, auth-gated actions |
+
+### Question 5: Solo or Social?
+> **"Do users interact with each other, or is it a solo experience? Can they see each other's stuff?"**
+
+*What this reveals:* Social features, real-time needs, content visibility model.
+
+| Answer Pattern | Hidden Requirement |
+|---------------|-------------------|
+| "Totally solo, it's a personal tool" | Simple data model, no sharing infrastructure |
+| "They can share links to their work" | Public URLs, sharing permissions |
+| "They message each other" | Messaging system, notifications, possibly real-time |
+| "They collaborate on the same document" | Real-time collaboration (WebSockets/CRDT), conflict resolution |
+
+---
+
+## Phase 3: The Capabilities (Equipment & Logistics)
+
+*Goal: Discover technical requirements the user doesn't know they have.*
+
+### Question 6: The Similar App
+> **"Name 1-2 apps that feel closest to what you're building. What do you like about them? What would you change?"**
+
+*What this reveals:* Feature benchmark, UI expectations, implicit technical requirements.
+
+| Reference App | Implied Stack Needs |
+|--------------|-------------------|
+| "Like Notion" | Rich text, content blocks, flexible schema, collaborative editing |
+| "Like Shopify" | E-commerce engine, payments, inventory, multi-vendor possible |
+| "Like Duolingo" | Gamification, progress tracking, spaced repetition, mobile-first |
+| "Like Airbnb" | Marketplace, search/filter, maps, booking/calendar, reviews |
+| "Like Slack" | Real-time messaging, channels, file sharing, notifications |
+| "Like Canva" | Canvas editor, templates, asset library, export pipeline |
+
+### Question 7: The Deal-Breakers
+> **"Which of these does your app NEED to do? (Just say yes or no to each)"**
+>
+> - Users log in with email/password or Google?
+> - Accept payments or subscriptions?
+> - Users upload files (images, videos, documents)?
+> - Send emails or notifications?
+> - Work well on phones (not just desktop)?
+> - Show real-time updates (like a live chat or live dashboard)?
+
+*What this reveals:* Direct capability mapping. Each "yes" locks in a technical requirement.
+
+| "Yes" Answer | Technical Requirement |
+|-------------|---------------------|
+| Login | Auth system (Supabase Auth, NextAuth, better-auth, Passport) |
+| Payments | Stripe integration, webhook handling, subscription model |
+| File uploads | Object storage (S3, Supabase Storage, Cloudflare R2) |
+| Emails | Email service (Resend, SendGrid, AWS SES) |
+| Mobile | Responsive design (Tailwind) or React Native |
+| Real-time | WebSockets (Socket.io, Supabase Realtime) or SSE |
+
+### Question 8: The Scale Question
+> **"In your dream scenario, how many people are using this? Just you? Hundreds? Thousands? Millions?"**
+
+*What this reveals:* Infrastructure scaling needs, database choice implications, hosting tier.
+
+| Answer | Infrastructure Implication |
+|--------|--------------------------|
+| "Just me / a few people" | SQLite or free-tier Supabase, simple hosting |
+| "Hundreds" | Standard PostgreSQL, single-server hosting |
+| "Thousands" | PostgreSQL + connection pooling, CDN, caching layer |
+| "Millions" | Horizontal scaling, Redis, CDN, queue system, microservices |
+
+---
+
+## Phase 4: The Timeline (Mission Calendar)
+
+*Goal: Understand urgency and what "done" means to them.*
+
+### Question 9: The Deadline
+> **"When do you need this working? Is there a hard deadline (like a launch event) or is it flexible?"**
+
+*What this reveals:* Scope constraints, MVP vs full-build, phase prioritization.
+
+### Question 10: The MVP Gate
+> **"If you could only ship THREE features and nothing else, which three?"**
+
+*What this reveals:* True priorities stripped of nice-to-haves. This becomes Phase 1.
+
+---
+
+## Capability-to-Stack Derivation Table
+
+After the interview, map collected capabilities to stack constraints:
+
+| Collected Capabilities | Rules Out | Points Toward |
+|-----------------------|-----------|---------------|
+| Rich text editor + collaboration | Static sites, simple CRUD | Next.js + Supabase Realtime, or MERN + Socket.io |
+| Payments + subscriptions | Frontend-only, static | Full-stack with Stripe SDK (Next.js, Express, Rails) |
+| File uploads (images only) | Nothing major | Supabase Storage, S3, Cloudflare R2 |
+| File uploads (video) | Serverless-only (size limits) | Dedicated upload service, container hosting |
+| Real-time (chat/collab) | Pure REST APIs | WebSocket-capable stack (Supabase, Socket.io, Ably) |
+| Mobile-first | Desktop-heavy frameworks | React Native, or responsive Next.js/Remix |
+| 3+ user roles | Simple auth | RBAC system, role middleware, admin dashboard |
+| Multi-tenant (orgs) | Simple data model | PostgreSQL RLS, tenant isolation, org-scoped queries |
+| ML/AI features | Frontend-only | Python backend or API calls to Claude/Gemini |
+| Offline support | Server-dependent stacks | PWA, local-first (SQLite + sync), service workers |
+
+---
+
+## Interview Anti-Patterns
+
+**Don't do these:**
+
+| Anti-Pattern | Why It Fails | Do Instead |
+|-------------|-------------|------------|
+| "What's your tech stack?" | Beginners freeze or guess wrong | Ask about the product, derive the stack |
+| "Do you need a relational database?" | Jargon — they don't know | "Does your data have relationships? Like courses have lessons, lessons have students?" |
+| "SSR or CSR?" | Meaningless to beginners | "Should Google be able to find your pages? Like a blog?" (→ SSR) |
+| "REST or GraphQL?" | Implementation detail | Never ask. Derive from data complexity |
+| "Monolith or microservices?" | Architecture astronautics | Never ask. Default monolith, split later if needed |
+| Asking all 10 questions mechanically | Feels like an interrogation | Adapt — skip questions already answered in earlier responses |
+
+---
+
+## Output: Capability Summary
+
+After the interview, produce a structured summary that feeds into branch generation:
+
+```markdown
+## Capability Summary (from Backward Planning Interview)
+
+**Product:** {elevator pitch}
+**Similar to:** {reference apps}
+**Primary user:** {who}
+**User roles:** {list}
+**Visual provided:** {yes/no — if yes, include extracted screen count and key findings}
+
+### Required Capabilities
+- [ ] Auth: {type}
+- [ ] Payments: {yes/no, type}
+- [ ] File uploads: {type, size}
+- [ ] Real-time: {yes/no, what kind}
+- [ ] Email/notifications: {yes/no}
+- [ ] Mobile: {responsive or native}
+- [ ] Scale target: {users}
+
+### Derived Constraints
+| Capability | Constraint | Eliminates |
+|-----------|-----------|------------|
+| {cap} | {what this means technically} | {stacks ruled out} |
+
+### MVP Features (Phase 1)
+1. {feature}
+2. {feature}
+3. {feature}
+
+→ Feed this into fire-vision-architect Step B2 (Backward Mode)
+```

package/skills-library/_general/methodology/CIRCUIT_BREAKER_INTELLIGENCE.md

@@ -0,0 +1,163 @@
+---
+name: CIRCUIT_BREAKER_INTELLIGENCE
+category: methodology
+description: Intelligent stuck-state detection with type classification, threshold tuning, dead-end engineering from Google X and NASA, and pre-defined kill conditions
+version: 1.0.0
+tags: [circuit-breaker, stuck-detection, dead-ends, google-x, kill-conditions, recovery]
+sources:
+  - "Microsoft Azure Architecture Center — Circuit Breaker Pattern"
+  - "Martin Fowler — Circuit Breaker (bliki)"
+  - "Google X — Moonshot Factory Operating Manual (Astro Teller)"
+  - "NASA — Knowledge Transfer and Tacit Knowledge Loss"
+  - "PMC — Drug Repurposing / ReFRAME compound library"
+---
+
+# Circuit Breaker Intelligence
+
+> **Core insight:** Not all "stuck" states are the same. A syntax error, a fixation loop, and a fundamentally impossible approach each require different interventions. Classify before intervening.
+
+---
+
+## 1. Stuck-State Classification
+
+Before triggering any recovery, classify the stuck type:
+
+| Stuck Type | Symptom | Correct Intervention |
+|------------|---------|---------------------|
+| **Transient error** | Build/API failure, external dependency timeout | Wait + retry (standard circuit breaker) |
+| **Fixation** | Same approach with varied syntax, 3+ attempts | Context rotation — fresh agent with dead-end map only |
+| **Context overflow** | Endless file navigation, losing track of changes | Condensation + fresh context window |
+| **Semantic misunderstanding** | Solution passes unit tests, fails integration | Human clarification — agent misunderstands the goal |
+| **Dead end** | All viable approaches exhausted, research returned nothing | Shelf with wake conditions, escalate or pivot |
+| **Scope violation** | Agent drifting outside declared file/tool boundaries | Re-read scope manifest, constrain tools |
+
+**Agent action:** When hitting a wall, classify FIRST. Then apply the matching intervention. Don't use "retry harder" for fixation problems or "fresh eyes" for transient errors.
+
+---
+
+## 2. Three-State Circuit Breaker
+
+```
+CLOSED (normal):
+  Task executes. Error counter tracks failures.
+
+  IF same error pattern seen {threshold} times:
+    → Trip to OPEN
+
+OPEN (tripped):
+  Stop executing this approach immediately.
+  Route to: research → re-plan → or shelf
+
+  Timeout: After research completes or new session starts
+    → Move to HALF-OPEN
+
+HALF-OPEN (probing):
+  Try the researched alternative with limited scope.
+
+  IF success: → Reset to CLOSED
+  IF failure:  → Back to OPEN (shelf as dead end)
+```
+
+### Threshold Tuning
+- **Transient errors:** threshold = 3 (retries are cheap)
+- **Logic errors:** threshold = 2 (retries are expensive)
+- **Architectural errors:** threshold = 1 (retry is pointless)
+
+**Anti-pattern:** Single shared breaker for all failure types. Maintain per-strategy breakers — one broken approach shouldn't mask another healthy one.
+
+---
+
+## 3. Pre-Defined Kill Conditions (Google X Pattern)
+
+> "Run at the hardest problem first." — Astro Teller, Google X
+
+Before any task executes, define what would prove the approach unviable:
+
+```yaml
+kill_conditions:
+  - "3 consecutive verification failures on same root cause"
+  - "approach requires changing >5 files outside declared scope"
+  - "same error repeats after 2 different fix strategies"
+  - "external dependency does not support required feature"
+
+wake_conditions:
+  - "if {blocking dependency} releases version with {feature}"
+  - "if {alternative library} becomes available"
+  - "if user provides {missing credential/config}"
+```
+
+**Why define upfront:** Kill conditions defined AFTER failure are rationalizations. Kill conditions defined BEFORE execution are engineering discipline. Google X kills ~97% of projects at rapid evaluation — before significant resources are allocated.
+
+**Agent action:** fire-planner should include 2-3 kill conditions per high-risk task in BLUEPRINT frontmatter. fire-executor checks these before retrying.
+
+---
+
+## 4. Dead-End Engineering
+
+Dead ends are **first-class knowledge artifacts**, not failures to delete.
+
+### What Makes a Good Dead-End Record
+
+From NASA's knowledge loss lessons: if you only record WHAT failed but not WHY, the next agent will attempt the same approach. The "why" is the asset.
+
+```markdown
+### [DEAD-END] {title}
+
+**What:** {what was attempted}
+**Why it failed:** {root cause, not just symptom}
+**Approaches tried:** {list with expected vs actual for each}
+**Fundamental constraint:** {the thing that makes this approach unviable}
+**Wake conditions:** {what would make this worth revisiting}
+**Status:** SHELVED | ABANDONED | SUPERSEDED BY {task-id}
+```
+
+### The ReFRAME Principle (Drug Repurposing)
+Pharmaceutical R&D maintains libraries of 12,000+ compounds that "failed" in one context but succeed when retested in new contexts. A dead end in Phase 3 may become the solution in Phase 7 when constraints change.
+
+**Agent action:** Before starting a new task, grep FAILURES.md for `[DEAD-END]` entries with related tags. A prior dead end may now be viable if the context has changed.
+
+---
+
+## 5. Articulation Before Escalation (Rubber Duck Protocol)
+
+Before routing to a fresh agent, human, or research:
+
+```markdown
+## STUCK REPORT
+
+**Goal:** {what I was trying to accomplish}
+**Approaches tried:**
+  1. {approach} → Expected: {X} → Got: {Y}
+  2. {approach} → Expected: {X} → Got: {Y}
+**Current constraint:** {what is physically preventing progress}
+**What a fresh approach needs:** {information or different framing}
+**Confidence this approach is viable:** {high/medium/low + reason}
+```
+
+**Why this works:** The act of articulating the problem forces assumption reconstruction. In cognitive science research, this catches 30-40% of stuck cases before escalation — the stuck agent solves it by explaining it.
+
+---
+
+## 6. Error Discrimination
+
+Not all errors carry equal signal:
+
+| Error Type | Signal Strength | Action |
+|------------|----------------|--------|
+| Syntax/typo | Low (weight: 0.25) | Auto-fix, minimal signal toward threshold |
+| Import/dependency missing | Medium (weight: 0.5) | Install/resolve, moderate signal |
+| Logic error (wrong output) | High (weight: 1.0) | Count fully, consider re-plan after 2 |
+| Architecture mismatch | Very high (weight: 2.0) | Count as 2, consider kill condition |
+| Cross-phase contract break | Critical (weight: 3.0) | Stop immediately, investigate integration failure |
+
+**Agent action:** Weight errors by type when evaluating circuit breaker thresholds. Three typos ≠ three architectural failures.
+
+---
+
+## When Agents Should Reference This Skill
+
+- **fire-executor:** Classify stuck states, check kill conditions, write stuck reports
+- **fire-planner:** Define kill conditions in BLUEPRINT frontmatter for high-risk tasks
+- **fire-verifier:** Flag recurring failure patterns as potential dead ends
+- **fire-researcher:** Read dead-end records before researching — avoid repeating prior approaches
+- **fire-autonomous:** Use error budgets + kill conditions to decide retry vs. shelf vs. escalate