@thierrynakoa/fire-flow 10.0.0

package/skills-library/specialists/workflow/feature-forge.md

@@ -0,0 +1,65 @@
+---
+name: feature-forge
+description: Use when defining new features, gathering requirements, or writing structured specifications. Invoke for requirements elicitation, EARS format, acceptance criteria, feature specs.
+license: MIT
+source: jeffallan/claude-skills (MIT)
+metadata:
+  author: https://github.com/Jeffallan
+  version: "1.0.0"
+  domain: product
+  triggers: feature spec, requirements, user story, acceptance criteria, EARS, product analysis, specification
+  role: specialist
+  scope: analysis
+  output-format: document
+---
+
+# Feature Forge
+
+Senior product analyst with dual PM and Dev perspectives — delivering structured, testable feature specifications ready for implementation.
+
+## When to Use This Skill
+
+- Defining a new feature from a rough idea
+- Conducting requirements elicitation interviews
+- Writing formal specifications with EARS-format requirements
+- Generating acceptance criteria in Given/When/Then format
+- Producing implementation checklists from requirements
+
+## Core Workflow
+
+1. **Discover** - Identify user goals, target audience, success metrics
+2. **Interview** - Structured questions from both PM Hat (value/goals) and Dev Hat (feasibility/security)
+3. **Document** - Write requirements in EARS format
+4. **Validate** - Confirm acceptance criteria with stakeholders
+5. **Deliver** - Final spec saved as `specs/{feature_name}.spec.md`
+
+## Must Do
+
+- Use structured elicitation (questions tool or numbered list) — not open-ended prompts
+- Complete the full interview before writing any specification
+- Include both functional (EARS) and non-functional requirements (performance, security)
+- Provide testable acceptance criteria: Given / When / Then
+- Include error handling and edge case tables
+
+## Must Not Do
+
+- Write specs before requirements are fully understood
+- Skip security or error handling requirements
+- Use vague, untestable acceptance criteria
+- Omit non-functional requirements
+
+## Spec Output Format
+
+```
+specs/{feature_name}.spec.md
+  - Overview (problem, goal, audience)
+  - Functional Requirements (EARS format)
+  - Non-Functional Requirements (perf, security, accessibility)
+  - Acceptance Criteria (Given/When/Then)
+  - Error Handling Table
+  - Implementation TODO checklist
+```
+
+## Knowledge Reference
+
+EARS syntax (Event-Action-Response-State), user story mapping, BDD/Given-When-Then, non-functional requirement categories, security requirements (OWASP), accessibility (WCAG), performance budgets.

package/skills-library/specialists/workflow/prompt-engineer.md

@@ -0,0 +1,54 @@
+---
+name: prompt-engineer
+description: Use when designing, optimizing, or evaluating prompts for LLMs. Invoke for chain-of-thought, few-shot learning, structured outputs, system prompts, prompt evaluation frameworks.
+license: MIT
+source: jeffallan/claude-skills (MIT)
+metadata:
+  author: https://github.com/Jeffallan
+  version: "1.0.0"
+  domain: data-ml
+  triggers: prompt engineering, LLM, chain-of-thought, few-shot, system prompt, structured output, evaluation, prompt optimization
+  role: specialist
+  scope: implementation
+  output-format: document
+---
+
+# Prompt Engineer
+
+Expert prompt engineer specializing in designing, optimizing, and evaluating prompts that maximize LLM performance across diverse use cases.
+
+## When to Use This Skill
+
+- Designing prompts for new LLM-powered features
+- Optimizing underperforming prompts
+- Implementing advanced techniques (chain-of-thought, few-shot, ReAct)
+- Building structured output schemas (JSON mode, tool calling)
+- Creating evaluation frameworks to measure prompt quality
+- Debugging inconsistent or low-quality LLM outputs
+
+## Core Workflow
+
+1. **Understand requirements** - Task definition, model, success criteria, failure modes
+2. **Design prompts** - Role definition, instructions, examples, output format
+3. **Test outputs** - Diverse realistic inputs including edge cases
+4. **Iterate** - Refine based on failure analysis
+5. **Document for deployment** - Final prompt, rationale, eval results
+
+## Must Do
+
+- Test prompts with diverse, realistic inputs including edge cases
+- Measure performance with quantitative metrics (accuracy, format compliance, latency)
+- Version prompts and track changes with eval results
+- Use system prompts to establish role and constraints
+- Provide few-shot examples for complex output formats
+
+## Must Not Do
+
+- Deploy prompts without systematic evaluation on test cases
+- Rely on a single test case to validate a prompt
+- Mix instructions with examples without clear structure
+- Assume a prompt that works on GPT-4 will work unchanged on Claude or vice versa
+
+## Knowledge Reference
+
+Chain-of-thought prompting, few-shot and zero-shot techniques, ReAct pattern, structured outputs (JSON mode, tool/function calling), system prompt design, prompt injection mitigations, evaluation frameworks (LLM-as-judge, human eval), model-specific quirks (Claude, Gemini, GPT-4), temperature and sampling parameters.

package/skills-library/specialists/workflow/the-fool.md

@@ -0,0 +1,62 @@
+---
+name: the-fool
+source: jeffallan/claude-skills (MIT)
+description: Use when you need critical reasoning, stress testing ideas, or conducting pre-mortems. Invoke to play devil's advocate, challenge this, expose assumptions, poke holes.
+triggers: challenge this, poke holes, devil's advocate, stress test, pre-mortem, red team, expose assumptions, critical thinking
+---
+
+# The Fool
+
+Critical reasoning specialist who stress-tests ideas, decisions, and plans through structured challenge modes.
+
+## Role
+
+Critical thinking specialist, 12+ years challenging plans, ideas, and assumptions. Operates as a professional skeptic who uses five distinct reasoning modes to expose flaws, test evidence, and strengthen positions. Challenges constructively, always driving toward better decisions.
+
+## When to Use
+
+- Testing whether a plan has fatal flaws
+- Challenging architectural or technical decisions
+- Conducting pre-mortems for new initiatives
+- Red teaming proposals before implementation
+- Exposing hidden assumptions in reasoning
+- Risk assessment for major changes
+
+## Challenge Modes
+
+| Mode | Purpose | When to Use |
+|------|---------|------------|
+| Expose Assumptions | Uncover unstated beliefs and dependencies | Early planning, design validation |
+| Argue the Other Side | Steelman opposing viewpoints | Decision validation, bias detection |
+| Find Failure Modes | Identify how this could go wrong | Pre-mortem for risky initiatives |
+| Attack This | Adversarial red team analysis | Security, threat modeling, competition |
+| Test the Evidence | Scrutinize logic and evidence quality | Research, claims, justifications |
+
+## Core Workflow
+
+1. **Position** — Understand the user's proposal, decision, or assumption
+2. **Select Mode** — Choose challenge mode via structured questioning
+3. **Challenge** — Apply chosen method to generate strong objections
+4. **Present** — Provide 3-5 strongest challenges with supporting logic
+5. **Synthesize** — Develop stronger position that addresses challenges
+
+## MUST DO
+
+- Steel man opposing views before challenging
+- Use structured reasoning for each challenge
+- Ground challenges in concrete logic
+- Present strongest objections (top 3-5)
+- Offer mitigation or strengthened position
+- Drive toward synthesis, not destruction
+
+## MUST NOT DO
+
+- Use unfounded criticism
+- Strawman opposing arguments
+- Leave challenges without context
+- Use personal attacks or dismissiveness
+- Create analysis paralysis
+
+## Knowledge
+
+Critical thinking, Socratic questioning, Hegelian dialectic, pre-mortem analysis, red teaming, threat modeling, logical fallacies, assumption mapping, SWOT analysis, devil's advocacy, evidence evaluation

package/templates/ASSUMPTIONS.md

@@ -0,0 +1,125 @@
+# ASSUMPTIONS.md Template
+
+> **Origin:** Dominion Flow v2.0 - Assumption tracking and validation.
+> **Enhanced in v3.2:** Added cross-phase contradiction detection, phase-gate validation,
+> and deferred-item impact analysis. Research basis: Gap analysis found assumptions
+> accumulate across phases without systematic tracking, leading to contradictions.
+> See: references/research-improvements.md (GAP-1, GAP-2, BLIND-SPOT-B)
+
+Template for `.planning/ASSUMPTIONS.md` — created by `/fire-1-new`.
+
+---
+
+## File Template
+
+```markdown
+# Project Assumptions
+
+## Summary
+| Status | Count |
+|--------|-------|
+| Validated | 0 |
+| Unvalidated | 0 |
+| Invalidated | 0 |
+
+---
+
+## Phase Assumptions
+
+### Phase XX: [Phase Name]
+
+#### ASSUMPTION-001: [Short description]
+- **Category:** Technical | Business | Infrastructure | Integration
+- **Statement:** [The specific assumption being made]
+- **Impact if wrong:** [What breaks if this assumption is false]
+- **Validation method:** [How to verify - test, research, user confirmation]
+- **Status:** VALIDATED | UNVALIDATED | INVALIDATED
+- **Validated by:** [evidence or "pending"]
+- **Phase:** [which phase relies on this]
+- **Plan:** [which plan relies on this]
+
+---
+
+## Invalidated Assumptions
+
+[Assumptions proven false - with impact assessment and remediation]
+
+### ASSUMPTION-XXX: [description] (INVALIDATED)
+- **Original assumption:** [what was assumed]
+- **Reality:** [what turned out to be true]
+- **Impact:** [what broke or needs changing]
+- **Remediation:** [how it was addressed]
+- **Blocker created:** [BLOCKER-XXX if applicable]
+```
+
+---
+
+## Common Assumption Categories
+
+| Category | Examples |
+|----------|---------|
+| Technical | "PostgreSQL supports JSON columns", "Next.js 15 has server actions" |
+| Business | "Users will register with email", "Free tier limited to 3 projects" |
+| Infrastructure | "Vercel supports WebSockets", "Redis available for caching" |
+| Integration | "Stripe supports the currency", "OAuth provider supports PKCE" |
+
+---
+
+## When to Create Assumptions
+
+- During `/fire-1a-discuss` (questioning phase)
+- During `/fire-2-plan` (plan creation)
+- During execution when uncertainty surfaces (honesty checkpoints)
+- When research reveals "it should work but I haven't verified"
+
+---
+
+## Validation Triggers
+
+- Before plan execution: validate UNVALIDATED assumptions for that plan
+- During honesty pre-check: surface assumptions being relied on
+- After phase completion: audit all assumptions for accuracy
+
+---
+
+## Cross-Phase Contradiction Detection (v3.2)
+
+> Research finding: Phase 6 can contradict Phase 1 assumptions buried in old handoffs.
+> This section prevents assumption drift across long-running projects.
+
+### Phase-Gate Validation Protocol
+
+At the START of each new phase, the planner MUST:
+
+1. **List all ACTIVE assumptions** from previous phases that this phase relies on
+2. **Check for contradictions** between existing assumptions and new plan requirements
+3. **Flag stale assumptions** — any UNVALIDATED assumption older than 2 phases
+4. **Verify invalidated assumptions** were actually remediated (not just flagged)
+
+### Contradiction Detection Checklist
+
+```markdown
+## Phase N Pre-Flight: Assumption Validation
+
+- [ ] Read all ACTIVE assumptions from Phases 1 through N-1
+- [ ] No contradictions between existing assumptions and Phase N plan
+- [ ] No UNVALIDATED assumptions older than 2 phases that affect this work
+- [ ] All INVALIDATED assumptions have completed remediation
+- [ ] New assumptions for Phase N are documented below
+```
+
+### Deferred Items Impact Analysis
+
+> Research finding: Deferred items multiply without tracking their compound impact.
+> Track each deferred item's blast radius to prevent Phase N from discovering
+> all deferred items must be done immediately.
+
+```markdown
+### DEFERRED-001: [Short description]
+- **Deferred in:** Phase N
+- **Impact if deferred further:** CRITICAL | HIGH | MEDIUM | LOW
+- **Blocking future phases:** [Phase X, Phase Y]
+- **Compound risk:** [What happens if this + other deferrals combine]
+- **Decision needed by:** Phase N+2 at latest
+- **Owner:** [who should resolve this]
+```

package/templates/BLOCKERS.md

@@ -0,0 +1,73 @@
+# BLOCKERS.md Template
+
+> **Origin:** NEW for Dominion Flow v2.0 - Centralized blocker tracking.
+
+Template for `.planning/BLOCKERS.md` — created by `/fire-1-new`.
+
+---
+
+## File Template
+
+```markdown
+# Project Blockers
+
+## Summary
+| Status | P0 | P1 | P2 | P3 | Total |
+|--------|----|----|----|----|-------|
+| Open   | 0  | 0  | 0  | 0  | 0     |
+| Resolved | 0 | 0 | 0 | 0 | 0    |
+
+---
+
+## Open Blockers
+
+[None currently]
+
+---
+
+## Resolved Blockers
+
+[None yet]
+
+---
+
+## Deferred Blockers
+
+[None yet]
+```
+
+---
+
+## Blocker Entry Format
+
+```markdown
+### BLOCKER-[NNN] [P0/P1/P2/P3] [Short description]
+- **Phase:** [phase identifier]
+- **Plan:** [plan identifier]
+- **Task:** [task identifier]
+- **Opened:** [date]
+- **Blocks:** [what this prevents - tasks, plans, or phases]
+- **Description:** [detailed description of the obstacle]
+- **Root Cause:** [identified root cause or "investigating"]
+- **Workaround:** [temporary workaround if available, or "None"]
+- **Assigned:** [who/what will resolve - "Next session", "User action required", etc.]
+```
+
+## Resolved Entry Addition
+
+```markdown
+- **Resolved:** [date]
+- **Resolution:** [how it was fixed]
+- **Skill Created:** [if solution was extracted to skills library]
+```
+
+---
+
+## Priority Guide
+
+| Priority | Criteria | Response Time |
+|----------|----------|---------------|
+| P0 | Blocks entire phase/milestone | Immediate - stop everything |
+| P1 | Blocks 2+ tasks or downstream plans | Fix before continuing blocked work |
+| P2 | Blocks 1 task, workaround exists | Document workaround, continue |
+| P3 | Quality concern, not blocking | Track for later |

package/templates/DECISION_LOG.md

@@ -0,0 +1,116 @@
+# DECISION_LOG.md Template
+
+> **Origin:** Dominion Flow v3.2 - Research-backed improvement.
+> **Research basis:** Gap analysis found architectural decisions are implicit in git history;
+> cross-phase contradictions occur when rationale is buried in old handoffs.
+> See: references/research-improvements.md (GAP-1, GAP-3, BLIND-SPOT-A)
+
+Template for `.planning/DECISION_LOG.md` — created by `/fire-1-new`.
+
+---
+
+## Why This Exists
+
+Without an explicit decision log:
+- Session 4 can contradict Session 1 decisions without realizing it
+- "Why did we choose X?" requires reverse-engineering git history
+- Deferred decisions get lost between phases
+- Assumption conflicts across phases go undetected
+
+---
+
+## File Template
+
+```markdown
+# Decision Log
+
+> Tracks architectural and design decisions across all phases.
+> Each entry captures WHAT was decided, WHY, and WHAT IT AFFECTS.
+> Review this log at the start of each new phase to catch contradictions.
+
+## Quick Reference
+
+| ID | Date | Decision | Phase | Status |
+|----|------|----------|-------|--------|
+<!-- Auto-populated as decisions are added below -->
+
+---
+
+## Decisions
+
+### DEC-001: [Short title]
+- **Date:** YYYY-MM-DD
+- **Phase:** Phase N - [name]
+- **Plan:** Plan N-NN (if applicable)
+- **Category:** Architecture | Database | API | Auth | UI | Infrastructure | Integration
+- **Decision:** [What was decided]
+- **Options Considered:**
+  1. [Option A] - [pros/cons]
+  2. [Option B] - [pros/cons]
+  3. [Option C] - [pros/cons]
+- **Rationale:** [Why this option was chosen]
+- **Trade-offs Accepted:** [What we gave up]
+- **Affects:**
+  - Phases: [which future phases depend on this]
+  - Files: [key files implementing this decision]
+  - Assumptions: [ASSUMPTION-XXX if linked]
+- **Status:** ACTIVE | SUPERSEDED by DEC-XXX | DEFERRED to Phase N
+- **Owner:** [who made the decision - human or agent]
+
+---
+
+## Superseded Decisions
+
+> Decisions that were later overridden. Kept for audit trail.
+
+### DEC-XXX: [title] (SUPERSEDED)
+- **Superseded by:** DEC-YYY
+- **Reason for change:** [what changed]
+- **Migration needed:** [yes/no - what needs updating]
+
+---
+
+## Deferred Decisions
+
+> Decisions postponed to a future phase. Review before that phase starts.
+
+### DEC-XXX: [title] (DEFERRED)
+- **Deferred to:** Phase N
+- **Reason:** [not enough information / not critical yet / blocked by X]
+- **Impact of delay:** [what happens if we defer too long]
+- **Decision needed by:** [deadline or trigger event]
+```
+
+---
+
+## When to Add Entries
+
+- During `/fire-1a-discuss` — when architectural questions are resolved
+- During `/fire-2-plan` — when plan requires technology/approach choices
+- During `/fire-3-execute` — when executor makes runtime decisions
+- During `/fire-debug` — when root cause reveals a design choice was wrong
+- During `/fire-4-verify` — when verification finds gaps requiring decisions
+
+---
+
+## Cross-Phase Validation
+
+At the start of each new phase, the planner should:
+
+1. Read all ACTIVE decisions
+2. Check for contradictions with the new plan
+3. Verify no DEFERRED decisions have reached their deadline
+4. Flag any SUPERSEDED decisions that still have unreversed code
+
+---
+
+## Integration Points
+
+| Command | How it uses Decision Log |
+|---------|------------------------|
+| `/fire-1a-discuss` | Creates initial architectural decisions |
+| `/fire-2-plan` | Reviews existing decisions, adds new ones |
+| `/fire-3-execute` | Executor references decisions, adds runtime decisions |
+| `/fire-4-verify` | Verifier checks code matches documented decisions |
+| `/fire-5-handoff` | Handoff references key decisions from this session |
+| `/fire-debug` | Links root causes to original decisions |

package/templates/UAT.md

@@ -0,0 +1,96 @@
+# UAT Template (Dominion Flow Enhanced)
+
+> **Origin:** Ported from Dominion Flow `UAT.md` with parallel diagnosis integration.
+
+Template for conversational User Acceptance Testing via `/fire-verify-uat`.
+
+---
+
+## UAT Session Format
+
+```markdown
+# UAT Session: Phase XX - [Phase Name]
+
+## Session Info
+- **Phase:** XX-name
+- **Date:** [date]
+- **Tester:** [user/AI]
+- **Environment:** [local/staging/production]
+
+## Critical Flows to Test
+
+| # | Flow | Priority | Status | Notes |
+|---|------|----------|--------|-------|
+| 1 | [User registration] | Must Pass | [PASS/FAIL] | |
+| 2 | [User login] | Must Pass | [PASS/FAIL] | |
+| 3 | [Core feature A] | Must Pass | [PASS/FAIL] | |
+| 4 | [Edge case B] | Should Pass | [PASS/FAIL] | |
+
+## Test Execution
+
+### Flow 1: [User Registration]
+
+**Steps:**
+1. Navigate to /register
+2. Fill in email: test@example.com
+3. Fill in password: SecurePass123!
+4. Click "Register"
+
+**Expected:** Redirect to /dashboard, welcome message displayed
+**Actual:** [result]
+**Status:** [PASS/FAIL]
+
+### Flow 2: [User Login]
+[...]
+
+## Issues Found
+
+| # | Severity | Description | Flow | Diagnosis |
+|---|----------|-------------|------|-----------|
+| 1 | Critical | [description] | Flow 1 | [root cause if known] |
+| 2 | Minor | [description] | Flow 3 | [root cause if known] |
+
+## Diagnosis Results (if failures found)
+
+For each FAIL, `/fire-diagnose` runs parallel investigation:
+- Agent 1: [Component where symptom appears]
+- Agent 2: [Component that triggers it]
+- Agent 3: [Working reference pattern]
+
+## UAT Verdict
+
+- **Overall:** [PASS / CONDITIONAL PASS / FAIL]
+- **Blocking Issues:** [count]
+- **Non-Blocking Issues:** [count]
+- **Recommendation:** [Proceed to next phase / Fix and retest / Major rework needed]
+```
+
+---
+
+## Conversational UAT Protocol
+
+1. **Present flows** - Show user the critical flows to test
+2. **Guide testing** - Walk through each flow step by step
+3. **Record results** - PASS/FAIL for each flow
+4. **On failure** - Immediately spawn parallel diagnosis agents
+5. **Report** - Generate UAT report with verdict
+6. **Route** - If PASS: `/fire-transition`. If FAIL: fix and retest.
+
+---
+
+## Automatic Diagnosis on Failure
+
+When a UAT flow fails, automatically spawn 3 parallel agents:
+
+```javascript
+// Agent 1: Where the symptom appears
+Task({ subagent_type: "fire-debugger", prompt: "Investigate [component with failure]..." });
+
+// Agent 2: What triggers it
+Task({ subagent_type: "fire-debugger", prompt: "Investigate [parent/caller component]..." });
+
+// Agent 3: Working reference
+Task({ subagent_type: "Explore", prompt: "Find working pattern in [similar component]..." });
+```
+
+This matches the parallel debugging pattern documented in CLAUDE.md.

package/templates/blueprint.md

@@ -0,0 +1,94 @@
+---
+phase: {phase_number}-{phase_name}
+plan: {plan_number}
+breath: {wave_number}
+autonomous: {autonomous}
+depends_on: [{depends_on}]
+files_modified: [{files_modified}]
+skills_to_apply:
+{skills_to_apply_yaml}
+validation_required:
+{validation_required_yaml}
+must_haves:
+  truths:
+{truths_yaml}
+  artifacts:
+{artifacts_yaml}
+  warrior_validation:
+{warrior_validation_yaml}
+---
+
+# Plan {phase_number}-{plan_number}: {plan_title}
+
+## Objective
+{objective}
+
+## Context
+@.planning/CONSCIENCE.md
+@.planning/VISION.md
+@.planning/phases/{phase_number}-{phase_name}/{phase_number}-RESEARCH.md
+
+## Honesty Pre-Check
+
+**What I know:**
+{what_i_know}
+
+**What I'm uncertain about:**
+{what_im_uncertain_about}
+
+**Skills to reference:**
+{skills_to_reference}
+
+## Tasks
+
+{tasks}
+
+## Verification
+
+### Must-Haves
+```bash
+{musthave_commands}
+```
+
+### WARRIOR Validation
+```bash
+{warrior_validation_commands}
+```
+
+## Success Criteria
+- [ ] All tasks complete
+- [ ] Must-Haves verified
+- [ ] WARRIOR validation passed ({warrior_check_count}/{warrior_check_total} checks)
+- [ ] Human verification approved (if required)
+
+## Rollback Plan
+{rollback_plan}
+
+---
+
+## Task Template Reference
+
+Use this format for each task:
+
+```markdown
+<task type="auto|checkpoint:human-verify|checkpoint:pause">
+**Action:** {action_description}
+**Skills:** {skill_references}
+**Steps:**
+1. {step_1}
+2. {step_2}
+3. {step_3}
+
+**Verification:**
+```bash
+{verification_command}
+```
+
+**Done Criteria:** {done_criteria}
+</task>
+```
+
+---
+
+*Plan created: {created_date}*
+*Estimated duration: {estimated_duration}*