@ckelsoe/prompt-architect 3.3.1 → 3.5.0

package/skills/prompt-architect/references/frameworks/least-to-most.md

@@ -4,6 +4,8 @@
 
 Least-to-Most (LtM) prompting is a decomposition-first framework that breaks a complex problem into an ordered sequence of simpler subproblems, then solves them sequentially — using each prior answer as context for the next. Unlike Chain of Thought (which reasons through a problem in one pass), LtM explicitly separates decomposition from execution, and the subproblems are sequenced from simplest to most complex.
 
+When the prompt is emitted, its section headers — PROBLEM, SOURCE MATERIAL, DECOMPOSE, SOLVE SEQUENTIALLY — are stripped and the model receives a flat block; the decomposition and solving instructions are written as complete sentences, and the `Subproblem 1:` / `Final:` labels survive as literal labels inside the protocol, so the ordered structure is preserved without the headers.
+
 **Research basis:** "Least-to-Most Prompting Enables Complex Reasoning in Large Language Models" (Zhou et al., Google Brain, arXiv:2205.10625, ICLR 2023). On SCAN compositional generalization: LtM achieves 99.7% vs. CoT's 16%. On GSM8K math: matches or exceeds CoT with fewer errors.
 
 ## Why LtM Differs from Chain of Thought
@@ -19,7 +21,7 @@ Least-to-Most (LtM) prompting is a decomposition-first framework that breaks a c
 ## Components
 
 ### Phase 1: Decomposition
-**Purpose:** Break the original problem into an ordered list of subproblems, from simplest to most complex. The key: later subproblems should build on earlier ones.
+**Purpose:** Break the original problem into an ordered list of subproblems, from simplest to most complex. The key: later subproblems should build on earlier ones. The DECOMPOSE header is stripped at emission, so the instruction that opens this phase must be a complete sentence; the numbered `Subproblem 1:`, `Subproblem 2:`, `Final:` labels are literal labels in the protocol and survive the stripping, which is what preserves the ordering once the header is gone.
 
 **Trigger:** "To solve [problem], we need to first solve: [list subproblems in order]"
 
@@ -29,29 +31,39 @@ Least-to-Most (LtM) prompting is a decomposition-first framework that breaks a c
 - What is the correct ordering — which must come first?
 
 ### Phase 2: Sequential Solving
-**Purpose:** Solve each subproblem in order, explicitly using prior answers as context.
+**Purpose:** Solve each subproblem in order, explicitly using prior answers as context. Once the SOLVE SEQUENTIALLY header is removed, the only thing telling the model to reuse earlier answers is this instruction, so it ships as an explicit sentence — carry each answer forward as context for the next subproblem — rather than resting on the header.
 
 **Pattern:** Answer subproblem 1 → use that answer when solving subproblem 2 → use both when solving subproblem 3 → ... → solve original problem.
 
 ## Template Structure
 
+Section headers — `PROBLEM:`, `SOURCE MATERIAL:`, `DECOMPOSE:`, `SOLVE SEQUENTIALLY:` —
+are stripped at emission, so the instruction beneath each one carries its meaning, and the
+`Subproblem N:` / `Final:` labels stay as literal labels rather than headings. The
+`SOURCE MATERIAL` block is optional: it names the artifact the subproblems reason over and
+is deleted when the problem is self-contained.
+
 ```
 PROBLEM:
 [The full, complex problem to solve]
 
+SOURCE MATERIAL:
+[Optional — paste the source material this problem depends on here (the dataset, figures, code, or document the subproblems must reason over). Delete this line and the one below it if the problem above is self-contained.]
+Every subproblem below must be answered against the material above, not from assumption.
+
 DECOMPOSE:
-Break this problem into ordered subproblems, from simplest to most complex.
+Break this problem into ordered subproblems, from simplest prerequisite to most complex.
 Each later subproblem should build on the answer to the previous.
 
-Subproblem 1: [Simplest prerequisite]
-Subproblem 2: [Next level, may depend on #1]
-Subproblem 3: [More complex, depends on #1-2]
-...
+Subproblem 1: [Simplest prerequisite — must be answered first]
+Subproblem 2: [Builds on #1]
+Subproblem 3: [Builds on #1-2]
+[Add subproblems as needed]
 Final: [The original problem, now solvable using all prior answers]
 
 SOLVE SEQUENTIALLY:
-Solve each subproblem in order. Use prior answers as context for each
-subsequent subproblem. Show each solution before moving to the next.
+Solve each subproblem in order. Use prior answers explicitly as context
+for each subsequent subproblem. Show each solution before moving to the next.
 ```
 
 ### Single-Pass Trigger (model decomposes and solves itself):
@@ -66,12 +78,17 @@ Problem: [your problem]
 
 ## Complete Examples
 
+Every example below is shown in emitted form. Where the subproblems reason over an existing
+artifact, the `SOURCE MATERIAL` block carries it and later subproblems refer to "the
+material above"; where the problem is self-contained, that block is deleted.
+
 ### Example 1: Multi-Hop Reasoning
 
 **Before LtM:**
 "What would the tax implications be for a US remote employee working from Portugal for 3 months?"
 
-**After LtM:**
+**After LtM** (no source material — the problem is self-contained, so the `SOURCE MATERIAL`
+block is deleted):
 ```
 PROBLEM:
 What are the tax implications for a US citizen employed by a US company who
@@ -102,7 +119,8 @@ SOLVE SEQUENTIALLY:
 **Before LtM:**
 "How do I add real-time notifications to my Django app?"
 
-**After LtM:**
+**After LtM** (no source material — the problem is self-contained, so the `SOURCE MATERIAL`
+block is deleted):
 ```
 PROBLEM:
 I need to add real-time push notifications to a Django app with PostgreSQL.
@@ -132,12 +150,16 @@ SOLVE SEQUENTIALLY:
 **Before LtM:**
 "Should we expand to the European market?"
 
-**After LtM:**
+**After LtM** (source material supplied):
 ```
 PROBLEM:
 Our B2B SaaS has strong US traction. Should we expand to the European market
 now, given our current 20-person team and 18 months of runway?
 
+SOURCE MATERIAL:
+[Paste the current financials, team breakdown, and US traction metrics here]
+Every subproblem below must be answered against the material above, not from assumption.
+
 DECOMPOSE:
 Subproblem 1: What are the key differences between US and European B2B SaaS
 markets that affect a US-native product? (GDPR, sales cycles, localization needs)
@@ -148,7 +170,7 @@ Subproblem 2: What resources are typically required for a credible EU market ent
 Subproblem 3: What are the signals that a company is or isn't ready for
 international expansion?
 
-Subproblem 4: Given our specific constraints (20 people, 18 months runway),
+Subproblem 4: Given the team size, runway, and traction shown in the material above,
 how do our resources map to those requirements?
 
 Final: Should we expand to Europe now, wait, or explore a different

package/skills/prompt-architect/references/frameworks/plan-and-solve.md

@@ -4,6 +4,8 @@
 
 Plan-and-Solve (PS+) is a zero-shot prompting technique that improves upon standard Chain of Thought by instructing the model to explicitly plan the solution approach before executing it — and to be careful about extracting variables and calculating intermediate results. It requires no examples or demonstrations and consistently outperforms Zero-Shot CoT ("Let's think step by step") on reasoning tasks.
 
+When the prompt is emitted, the `PROBLEM:` and `SOURCE MATERIAL:` headers are stripped and the instruction reaches the model as a flat block. The plan-and-solve trigger is already a complete sentence, so it survives the stripping intact and needs no carrier sentence; the optional `SOURCE MATERIAL` block names the figures the calculation runs on and ties them to the problem in prose, and is deleted when the problem already states every value.
+
 **Research basis:** "Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models" (Wang et al., ACL 2023, arXiv:2305.04091). Tested across 10 reasoning datasets — consistently outperforms Zero-Shot-CoT and is competitive with few-shot CoT.
 
 ## The Core Trigger Phrases
@@ -29,11 +31,22 @@ The PS+ additions over PS:
 
 ## Template Structure
 
+Section headers — `PROBLEM:` and `SOURCE MATERIAL:` — are stripped at emission, so the
+trigger that follows is written as a complete sentence and survives on its own; it was
+already prose, not a header, which is why PS+ needs no carrier sentence for it. The template
+drops the old `INSTRUCTION:` header for the same reason: a header there would only be
+stripped anyway, so the trigger now sits as bare prose. The `SOURCE MATERIAL` block is
+optional — it names the dataset or table the calculation runs on and is deleted when the
+problem already states every value needed.
+
 ```
 PROBLEM:
-[Your problem or question]
+[Your question, calculation, or reasoning problem]
+
+SOURCE MATERIAL:
+[Optional — paste the source data the problem depends on here (the dataset, table, figures, or constraint list the calculation runs on). Delete this line and the one below it if the problem above already states every value needed.]
+The figures and constraints in the material above are authoritative — extract from them rather than from assumed or recalled values.
 
-INSTRUCTION:
 Let's first understand the problem, extract relevant variables and their
 corresponding numerals, and devise a complete plan. Then, let's carry out
 the plan, calculate intermediate values, pay attention to computation,
@@ -50,12 +63,19 @@ step by step.
 
 ## Complete Examples
 
+Every example below is shown in emitted form. The plan-and-solve trigger is the same
+complete sentence in each — it is what survives header stripping. Where the calculation runs
+on a pasted dataset or constraint list, the `SOURCE MATERIAL` block carries it and the
+problem refers to "the material above"; where every value is already in the problem
+statement, that block is deleted.
+
 ### Example 1: Math / Calculation
 
 **Before PS+:**
 "If a SaaS company has 500 customers at $200/month each, 5% monthly churn, and adds 30 new customers per month, what is the MRR in 6 months?"
 
-**After PS+:**
+**After PS+** (no source material — every value is stated in the problem, so the
+`SOURCE MATERIAL` block is deleted):
 ```
 PROBLEM:
 A SaaS company has 500 customers paying $200/month each. Monthly churn
@@ -98,13 +118,16 @@ Final answer: Month 6 MRR = $X
 **Before PS+:**
 "Our API is returning responses in 800ms average. We want to get it under 200ms. What should we do?"
 
-**After PS+:**
+**After PS+** (source material supplied):
 ```
 PROBLEM:
 Our REST API averages 800ms response time. Target is under 200ms.
 The API serves product catalog queries (read-heavy), is Node.js with
-PostgreSQL, and currently has no caching layer. Database queries are
-the main bottleneck (600ms average per request).
+PostgreSQL, and currently has no caching layer.
+
+SOURCE MATERIAL:
+[Paste the endpoint's profiling output and the current server and database configuration here]
+The figures and constraints in the material above are authoritative — extract from them rather than from assumed or recalled values.
 
 Let's first understand the problem, extract relevant variables and their
 corresponding numerals, and devise a complete plan. Then, let's carry out
@@ -116,7 +139,8 @@ the plan and solve step by step.
 **Before PS+:**
 "What's our payback period if CAC is $1,200 and average MRR per customer is $150 with 70% gross margin?"
 
-**After PS+:**
+**After PS+** (no source material — every value is stated in the problem, so the
+`SOURCE MATERIAL` block is deleted):
 ```
 PROBLEM:
 Customer Acquisition Cost (CAC): $1,200
@@ -136,10 +160,15 @@ and solve the problem step by step.
 **Before PS+:**
 "Given these constraints [complex scheduling problem], is there a valid schedule?"
 
-**After PS+:**
+**After PS+** (source material supplied):
 ```
 PROBLEM:
-[Complex scheduling problem with constraints]
+Determine whether a valid schedule exists that satisfies every constraint,
+or prove that none does.
+
+SOURCE MATERIAL:
+[Paste the full list of scheduling constraints — resources, time windows, and dependencies — here]
+The figures and constraints in the material above are authoritative — extract from them rather than from assumed or recalled values.
 
 Let's first understand the problem, extract all constraints and their
 relationships, and devise a complete plan for finding a valid schedule

package/skills/prompt-architect/references/frameworks/pre-mortem.md

@@ -16,6 +16,9 @@ The mechanism: committing to the failure frame bypasses optimism bias and elicit
 
 ## Components
 
+### Source Material (optional)
+**Purpose:** The project plan, proposal, or decision document the analysis works from. Supplying it grounds the failure causes in what the plan actually says rather than in the model's assumptions about a project of that description. The template's slot is optional and self-deleting: if there is nothing to paste, the bracketed block and the sentence directly below it both come out.
+
 ### Project/Decision Description
 **Purpose:** What is being analyzed. Include enough context for the model to generate specific (not generic) failure causes.
 
@@ -27,6 +30,8 @@ The mechanism: committing to the failure frame bypasses optimism bias and elicit
 
 **Standard framing:** *"It is [future date] and [project/decision] has completely and catastrophically failed."*
 
+**The frame has to be defended, not just stated.** A model given only the assumption will drift back into probabilistic language within a few sentences — "adoption may have lagged", "the integration could have slipped" — which collapses the pre-mortem back into ordinary forward risk analysis and throws away the entire mechanism. The template therefore opens by declaring the failure settled fact rather than a possibility, and closes that opening with an explicit prohibition: *do not hedge with "could," "might," or "may."* Keep both. Per SKILL.md step 5, a prohibition the user relies on must survive into the emitted prompt as explicit instruction text — it cannot be left to a section header, because headers are stripped at emission.
+
 ### Domain Analysis
 **Purpose:** The specific dimensions to analyze for failure causes. More dimensions = more comprehensive coverage.
 
@@ -41,102 +46,206 @@ The mechanism: committing to the failure frame bypasses optimism bias and elicit
 ### Warning Signs
 **Purpose:** For each failure cause, identify the earliest observable warning sign. This is what makes pre-mortem actionable — not just "this could fail" but "this is what we'd see 30 days before it fails."
 
-### Mitigation Pass (optional)
-**Purpose:** A second pass ranking the failure causes by likelihood × preventability and suggesting pre-emptive actions.
+### Priority Assessment
+**Purpose:** A closing pass over the causes already listed, singling out three things: the 3 most LIKELY to be what actually happened, the 3 most PREVENTABLE — where action taken today would have made the most difference — and any single point of failure that could have killed the project on its own.
+
+These are two separate top-3 lists, not one ranking by a combined likelihood-and-preventability score. A cause can be near-certain and unpreventable, or unlikely and trivially preventable; collapsing them into a single ranking buries both. The preventable list is the one that converts the analysis into action. Unlike Source Material above, this slot is unconditional — the template gives it no bracketed block and no deletion instruction.
 
 ## Template Structure
 
+Section headers are stripped at emission, so every slot's meaning is carried by the prose around and inside it rather than by the header above it. The opening paragraph is not a title — it is the instruction that establishes the settled-failure frame, and it ships with the prompt.
+
 ```
-PRE-MORTEM ANALYSIS
+You are conducting a pre-mortem on the project described below. The failure stated further
+down is settled fact, not a possibility — work backwards from it and explain why it happened.
+Do not hedge with "could," "might," or "may."
+
+SOURCE MATERIAL:
+[Optional — paste the project plan, proposal, or decision document here. If you have nothing
+to paste, delete this bracketed block along with the sentence directly below it.]
+Use the material above as the factual basis for the work described below.
 
 PROJECT/DECISION:
-[Describe the project, plan, or decision being analyzed]
+[Describe the project, plan, or decision being analyzed in full sentences — what is being
+attempted, plus team size, timeline, resources, goals, and constraints]
 
 FAILURE ASSUMPTION:
-It is [DATE — e.g., 12 months from now] and [project/decision] has
-completely and catastrophically failed. It did not achieve [primary goal].
+It is [DATE — e.g., 12 months from now] and [project/decision] has completely and
+catastrophically failed. It did not achieve [primary goal].
 
-FAILURE ANALYSIS:
-Describe the failure in 2-3 sentences from the perspective of someone
-looking back on it.
+FAILURE NARRATIVE:
+Begin by describing how that failure unfolded, in 2-3 sentences, in past tense from the
+perspective of someone looking back on it.
 
-Then identify [8-12] specific reasons this failed. For each reason:
+FAILURE CAUSES:
+Then identify [8-12] specific reasons it failed, each stated as something that already went
+wrong. Cover technical/product, team/organizational, market/adoption, financial/resource,
+external dependencies, and timeline/scope. Give each cause three lines:
 - CAUSE: [What specifically went wrong — be specific, not generic]
 - DOMAIN: [Technical / People / Market / Financial / External / Timeline]
 - WARNING SIGN: [What was the earliest observable indicator this was happening?]
-
-PRIORITY:
-After listing all causes, identify:
-1. The 3 most likely failure causes (given our specific situation)
-2. The 3 most preventable failure causes (where action now would help most)
-3. Any single point of failure that could kill the project alone
+"CAUSE:", "DOMAIN:" and "WARNING SIGN:" are literal labels in this protocol, not headings —
+keep them exactly as written.
+
+PRIORITY ASSESSMENT:
+After listing every cause, close by singling out three things:
+1. The 3 causes most LIKELY to be what actually happened, given the situation above.
+2. The 3 most PREVENTABLE causes — where action taken today would have made the most
+   difference.
+3. Any single point of failure that could have killed the project on its own.
 ```
 
+Three notes on why the shape is what it is:
+
+`FAILURE NARRATIVE` and `FAILURE CAUSES` are separate slots because they ask for different things — one continuous retrospective paragraph, then a structured enumeration. Collapsing them into a single analysis slot reliably produces a list with a narrative sentence stapled to the front, losing the retrospective voice that carries the frame.
+
+The `CAUSE` / `DOMAIN` / `WARNING SIGN` labels are the one place in this template where bare labels do survive into the output, because they are labels *inside* the requested response format rather than scaffolding headers around the prompt. The template says so explicitly, which is why that line is part of the prompt and not a comment about it.
+
+Every instruction slot is phrased as a sequenced directive — "Begin by", "Then identify", "After listing every cause, close by" — so the ordering survives even with the headers removed.
+
 ## Complete Examples
 
+Every example below keeps the headers on the page for readability, but is written in emitted form beneath them: the settled-failure paragraph first, then each slot carrying its own role in prose. Read the headers as scaffolding that will be deleted — the examples are written so that nothing is lost when it is. Note that only the user-supplied slots (source material, project, failure assumption) differ between examples; the instruction slots are the protocol and stay as written.
+
 ### Example 1: Product Launch
 
+**Before Pre-Mortem:**
+"What are the risks with our Q3 launch?"
+
+**After Pre-Mortem** (source material supplied):
 ```
-PROJECT:
-We are launching a new B2B project management tool for engineering teams
-in Q3. Our team is 4 engineers, 1 designer, and 1 PM. We have 3 design
-partners signed up for beta. Target: 50 paying customers by end of Q4.
+You are conducting a pre-mortem on the project described below. The failure stated further
+down is settled fact, not a possibility — work backwards from it and explain why it happened.
+Do not hedge with "could," "might," or "may."
 
-FAILURE ASSUMPTION:
-It is December 31st and we have failed to reach 50 paying customers.
-The product launched in October with 8 beta customers but growth stalled.
+SOURCE MATERIAL:
+[Paste the Q3 launch plan and the three design partners' beta feedback notes here]
+Use the material above as the factual basis for the work described below.
 
-FAILURE ANALYSIS:
-Describe how this played out. Then identify 10 specific failure causes
-with domain, and earliest warning sign for each.
+PROJECT/DECISION:
+We are launching a new B2B project management tool for engineering teams in Q3. The team is
+4 engineers, 1 designer, and 1 PM. Three design partners are signed up for the beta. The
+target is 50 paying customers by the end of Q4, against two quarters of remaining runway.
 
-PRIORITY:
-Rank by likelihood. Flag any single points of failure.
+FAILURE ASSUMPTION:
+It is December 31st and the launch has completely and catastrophically failed. It did not
+achieve 50 paying customers. The product shipped in October with 8 beta customers and
+growth stalled there.
+
+FAILURE NARRATIVE:
+Begin by describing how that failure unfolded, in 2-3 sentences, in past tense from the
+perspective of someone looking back on it.
+
+FAILURE CAUSES:
+Then identify 10 specific reasons it failed, each stated as something that already went
+wrong. Cover technical/product, team/organizational, market/adoption, financial/resource,
+external dependencies, and timeline/scope. Give each cause three lines:
+- CAUSE: [What specifically went wrong — be specific, not generic]
+- DOMAIN: [Technical / People / Market / Financial / External / Timeline]
+- WARNING SIGN: [What was the earliest observable indicator this was happening?]
+"CAUSE:", "DOMAIN:" and "WARNING SIGN:" are literal labels in this protocol, not headings —
+keep them exactly as written.
+
+PRIORITY ASSESSMENT:
+After listing every cause, close by singling out three things:
+1. The 3 causes most LIKELY to be what actually happened, given the situation above.
+2. The 3 most PREVENTABLE causes — where action taken today would have made the most
+   difference.
+3. Any single point of failure that could have killed the launch on its own.
 ```
 
 ### Example 2: Organizational Change
 
-```
-PROJECT:
-We are implementing a company-wide shift to OKRs across a 200-person
-organization. Executive sponsorship is in place. We're starting with
-a 2-day offsite to train team leads, then cascading to individual
-contributors over the following 6 weeks.
+**Before Pre-Mortem:**
+"What could go wrong with our OKR rollout?"
 
-FAILURE ASSUMPTION:
-It is 6 months from now and the OKR implementation has failed.
-Most teams have abandoned OKRs and reverted to old goal-setting methods.
+**After Pre-Mortem** (no source material — the optional block and its follow-on sentence are both deleted):
+```
+You are conducting a pre-mortem on the project described below. The failure stated further
+down is settled fact, not a possibility — work backwards from it and explain why it happened.
+Do not hedge with "could," "might," or "may."
 
-FAILURE ANALYSIS:
-10 specific reasons the rollout failed. Include: leadership domain,
-middle management domain, cultural domain, process domain, and tooling.
-For each: earliest warning sign.
+PROJECT/DECISION:
+We are implementing a company-wide shift to OKRs across a 200-person organization.
+Executive sponsorship is in place. The rollout starts with a 2-day offsite to train team
+leads, then cascades to individual contributors over the following 6 weeks. No dedicated
+program manager is assigned; team leads absorb the work alongside their existing roles.
 
-PRIORITY:
-The 3 most likely. The most preventable. Any single point of failure.
+FAILURE ASSUMPTION:
+It is 6 months from now and the OKR implementation has completely and catastrophically
+failed. It did not achieve durable adoption — most teams abandoned OKRs and reverted to
+their old goal-setting methods.
+
+FAILURE NARRATIVE:
+Begin by describing how that failure unfolded, in 2-3 sentences, in past tense from the
+perspective of someone looking back on it.
+
+FAILURE CAUSES:
+Then identify 10 specific reasons it failed, each stated as something that already went
+wrong. Cover leadership behavior, middle-management incentives, culture, process design,
+tooling, and timeline/scope. Give each cause three lines:
+- CAUSE: [What specifically went wrong — be specific, not generic]
+- DOMAIN: [Leadership / Middle management / Culture / Process / Tooling / Timeline]
+- WARNING SIGN: [What was the earliest observable indicator this was happening?]
+"CAUSE:", "DOMAIN:" and "WARNING SIGN:" are literal labels in this protocol, not headings —
+keep them exactly as written.
+
+PRIORITY ASSESSMENT:
+After listing every cause, close by singling out three things:
+1. The 3 causes most LIKELY to be what actually happened, given the situation above.
+2. The 3 most PREVENTABLE causes — where action taken today would have made the most
+   difference.
+3. Any single point of failure that could have killed the rollout on its own.
 ```
 
+Note the substituted `DOMAIN` values. The template's six domains are the general-purpose default; where a project's real failure surfaces are known, naming them gets better coverage than the generic set. The label itself stays literal.
+
 ### Example 3: Technical Decision
 
+**Before Pre-Mortem:**
+"Review our database migration plan for risks."
+
+**After Pre-Mortem** (source material supplied):
 ```
-PROJECT:
-We are migrating our primary database from MySQL to PostgreSQL. Timeline:
-3 months. Team: 2 senior engineers part-time. We're running 2M daily
-active users with a 99.9% uptime SLA.
+You are conducting a pre-mortem on the project described below. The failure stated further
+down is settled fact, not a possibility — work backwards from it and explain why it happened.
+Do not hedge with "could," "might," or "may."
+
+SOURCE MATERIAL:
+[Paste the migration runbook, the current schema, and the rollback plan here]
+Use the material above as the factual basis for the work described below.
+
+PROJECT/DECISION:
+We are migrating our primary database from MySQL to PostgreSQL over a 3-month timeline. The
+team is 2 senior engineers working part-time on it. The system serves 2M daily active users
+under a 99.9% uptime SLA, and neither engineer has run a migration at this scale before.
 
 FAILURE ASSUMPTION:
-It is 4 months from now and the migration has failed. We experienced
-significant downtime, data integrity issues, or were forced to roll back.
-
-FAILURE ANALYSIS:
-10 specific technical and organizational failure causes.
-Cover: migration strategy, testing gaps, rollback planning,
-team knowledge gaps, operational issues, and unforeseen dependencies.
-For each: earliest warning sign.
-
-PRIORITY:
-The 3 most likely. The most preventable. Any single point of failure
-that could cause a full rollback or data loss.
+It is 4 months from now and the migration has completely and catastrophically failed. It did
+not achieve a clean cutover — we took significant downtime, hit data integrity problems, and
+were forced to roll back.
+
+FAILURE NARRATIVE:
+Begin by describing how that failure unfolded, in 2-3 sentences, in past tense from the
+perspective of someone looking back on it.
+
+FAILURE CAUSES:
+Then identify 10 specific reasons it failed, each stated as something that already went
+wrong. Cover migration strategy, testing gaps, rollback planning, team knowledge gaps,
+operational and on-call issues, and unforeseen dependencies. Give each cause three lines:
+- CAUSE: [What specifically went wrong — be specific, not generic]
+- DOMAIN: [Strategy / Testing / Rollback / Knowledge / Operations / Dependencies]
+- WARNING SIGN: [What was the earliest observable indicator this was happening?]
+"CAUSE:", "DOMAIN:" and "WARNING SIGN:" are literal labels in this protocol, not headings —
+keep them exactly as written.
+
+PRIORITY ASSESSMENT:
+After listing every cause, close by singling out three things:
+1. The 3 causes most LIKELY to be what actually happened, given the situation above.
+2. The 3 most PREVENTABLE causes — where action taken today would have made the most
+   difference.
+3. Any single point of failure that could have forced a full rollback or caused data loss
+   on its own.
 ```
 
 ## Best Use Cases
@@ -187,11 +296,12 @@ that could cause a full rollback or data loss.
 
 ## Quick Reference
 
-| Component | Purpose |
+| Template slot | Purpose |
 |-----------|---------|
-| Project Description | What's being analyzed |
-| Future Date | Time horizon |
-| Failure Framing | "Has already failed" (committed, not probabilistic) |
-| Domain Analysis | Dimensions to cover |
-| Warning Signs | Earliest observable indicators |
-| Priority Pass | Most likely + most preventable + single points of failure |
+| Opening paragraph | Declares the failure settled fact; bans "could / might / may" |
+| `SOURCE MATERIAL` | Optional plan or decision document to ground causes in; self-deleting |
+| `PROJECT/DECISION` | What's being analyzed, with team, timeline, resources, constraints |
+| `FAILURE ASSUMPTION` | Time horizon + "has already failed" + the goal it missed |
+| `FAILURE NARRATIVE` | 2-3 sentences, past tense, retrospective voice |
+| `FAILURE CAUSES` | 8-12 causes, each as CAUSE / DOMAIN / WARNING SIGN |
+| `PRIORITY ASSESSMENT` | Most likely + most preventable + single points of failure |