@fredcallagan/arn-spark 5.1.0

package/plugins/arn-spark/skills/arn-spark-stress-interview/references/interview-protocol.md

@@ -0,0 +1,140 @@
+# Interview Protocol
+
+Structured protocol for the "Two-Part Reveal" synthetic user interview process. This document is consumed by the `arn-spark-stress-interview` skill to orchestrate persona impersonator invocations across three interview phases.
+
+## Overview
+
+The Two-Part Reveal is designed to surface genuine reactions by controlling information disclosure. The interview starts blind (the persona does not know what the product is), reveals the full concept in the second phase, and pressure-tests in the third. This mirrors how real users encounter products: first impressions are formed before marketing messaging has time to shape expectations.
+
+The full interview cycle runs 3 personas x 3 phases = 9 persona-impersonator invocations organized as 3 phase-parallel waves, with product-strategist invocations at the start of each wave for question formulation. All personas run the same phase in parallel before the wave advances to the next phase.
+
+---
+
+## Phase 1: Initial Reaction (Blind Problem Check)
+
+**Goal:** Determine whether the persona recognizes and cares about the problem the product solves -- before knowing the product exists.
+
+**Information disclosed to persona:**
+- The problem space description (extracted from the product concept's Problem Statement section)
+- The persona's own profile and casting overlay
+- NO product name, NO solution description, NO features
+
+**Question types:**
+- Problem recognition: "Do you experience [problem]? How often? How severely?"
+- Current coping: "What do you currently do about this? What tools or workarounds?"
+- Pain severity: "On a scale of 'mild annoyance' to 'blocking my work,' where does this fall?"
+- Willingness to solve: "If a solution existed, what would you pay / what effort would you invest?"
+
+**What to listen for:**
+- Whether the persona even recognizes the problem (if not, the product concept may have a target audience assumption error)
+- The language the persona uses to describe the problem (may differ from the product concept's framing)
+- How severe the problem is from the persona's perspective versus the product concept's claim
+- What the persona's switching threshold looks like (how much pain before they seek a solution)
+
+**Expected duration:** 3-5 sentences from the persona per prompt. 1-2 prompts per phase.
+
+**Product strategist role:** Before Phase 1, the product strategist formulates 2-3 questions that probe problem recognition without revealing the solution. The strategist extracts the problem framing from the product concept and strips solution-specific language.
+
+---
+
+## Phase 2: Deep Probing (Elevator Pitch Reveal)
+
+**Goal:** Reveal the full product concept and probe adoption barriers, feature gaps, and misalignment with the persona's needs.
+
+**Information disclosed to persona:**
+- Everything from Phase 1 PLUS the full product concept summary (vision, core experience, product pillars, key features)
+- The product's claimed value proposition and differentiation
+
+**Question types:**
+- First reaction to solution: "Now that you see the product, what is your gut reaction?"
+- Fit assessment: "Does this solve the problem you described in Phase 1? Where does it fall short?"
+- Adoption barriers: "What would stop you from trying this? What would you need to see first?"
+- Feature evaluation: "Which features matter most to you? Which seem unnecessary?"
+- Pillar alignment: "The product commits to [pillar]. Does that match what you need?"
+
+**What to listen for:**
+- Whether the persona's Phase 1 problem description matches what the product actually solves
+- Specific adoption barriers that the product concept does not address
+- Features the persona expected that are missing
+- Features the persona considers unnecessary or harmful
+- Whether the product pillars resonate or feel irrelevant to the persona's needs
+
+**Expected duration:** 1-3 paragraphs from the persona per prompt. 2-3 prompts per phase.
+
+**Product strategist role:** Between Phase 1 and Phase 2, the product strategist reviews Phase 1 responses and formulates questions that target gaps between the persona's described problem and the product's proposed solution. The strategist identifies which product pillars to probe based on the persona's stated priorities.
+
+---
+
+## Phase 3: Stress Test (Dealbreaker Probe)
+
+**Goal:** Present the weakest aspects of the product concept and pressure-test the persona's willingness to adopt despite known limitations.
+
+**Information disclosed to persona:**
+- Everything from Phase 2 PLUS explicitly identified weaknesses, scope boundaries, and deferred features
+- Known competitive alternatives and their advantages over this product
+
+**Question types:**
+- Dealbreaker identification: "What is the single biggest reason you would NOT use this product?"
+- Competitive comparison: "Given that [competitor] already does [feature], why would you switch to this?"
+- Scope boundary reaction: "[Feature] is explicitly not in v1. Does that change your assessment?"
+- Worst case: "If [known weakness] turns out to be worse than expected, would you still use this?"
+- Verdict: "Honest assessment -- would you use this, pay for this, recommend this to a colleague?"
+
+**What to listen for:**
+- Dealbreakers that the product concept does not acknowledge or mitigate
+- Competitive advantages that the product concept underestimates
+- Scope boundary decisions that the persona views as fatal omissions
+- The persona's honest adoption verdict and the reasoning behind it
+- Whether the casting overlay's specific concerns (pragmatist/skeptic/power user) surface unique failure modes
+
+**Expected duration:** 2-4 paragraphs from the persona per prompt, ending with a clear verdict. 2-3 prompts per phase.
+
+**Product strategist role:** Between Phase 2 and Phase 3, the product strategist reviews Phase 2 responses and identifies the weakest points to probe. The strategist formulates questions that force the persona to confront known limitations rather than politely sidestep them.
+
+---
+
+## Orchestration Guide
+
+### Invocation Sequence (Phase-Parallel Waves)
+
+```
+Wave 1 -- Phase 1 (all 3 personas in parallel):
+  Persona 1: Product strategist → Persona impersonator (Phase 1)
+  Persona 2: Product strategist → Persona impersonator (Phase 1)
+  Persona 3: Product strategist → Persona impersonator (Phase 1)
+  [Wait for all 3 to complete]
+
+Wave 2 -- Phase 2 (all 3 personas in parallel):
+  Persona 1: Product strategist → Persona impersonator (Phase 2)
+  Persona 2: Product strategist → Persona impersonator (Phase 2)
+  Persona 3: Product strategist → Persona impersonator (Phase 2)
+  [Wait for all 3 to complete]
+
+Wave 3 -- Phase 3 (all 3 personas in parallel):
+  Persona 1: Product strategist → Persona impersonator (Phase 3)
+  Persona 2: Product strategist → Persona impersonator (Phase 3)
+  Persona 3: Product strategist → Persona impersonator (Phase 3)
+  [Wait for all 3 to complete]
+```
+
+Total: 3 waves x 3 personas x 2 agents = 18 invocations (9 impersonator + 9 strategist)
+Per wave: 3 parallel persona-pairs, each with a strategist then impersonator (sequential within the pair, parallel across pairs)
+
+### Context Passing Between Waves
+
+Each persona-impersonator invocation receives:
+- The persona profile (constant across all 3 phases)
+- The casting overlay (constant across all 3 phases)
+- The interview phase identifier (reaction/probing/stress)
+- The specific questions for this phase (from product strategist)
+- Previous phase responses for **this persona only** (accumulated -- Phase 2 receives this persona's Phase 1 responses, Phase 3 receives this persona's Phase 1+2 responses)
+
+Each product-strategist invocation receives:
+- The full product concept
+- The persona profile and casting overlay
+- All previous phase responses **for this persona only**
+- The current phase's goal and question types (from this protocol)
+
+### Phase-Parallel Execution
+
+All 3 personas run the same phase in parallel before the wave advances to the next phase. Each persona's interview context is independent -- no cross-persona information is shared between parallel invocations within a wave. Cross-persona comparison happens at the synthesis stage (Step 5 of the SKILL), not during interviews.

package/plugins/arn-spark/skills/arn-spark-stress-interview/references/interview-report-template.md

@@ -0,0 +1,165 @@
+# Interview Report Template
+
+Template for the synthetic user interview stress test report. This document is consumed by the `arn-spark-stress-interview` skill when assembling the final report from interview transcripts and strategist synthesis.
+
+## Instructions for arn-spark-stress-interview
+
+When populating this template:
+
+- Every section below MUST appear in the output, even if an interview was skipped due to agent failure
+- Replace all bracketed placeholders with concrete content from interview transcripts and strategist synthesis
+- Per-Persona Findings should quote or closely paraphrase the persona's actual responses -- do not summarize away the specificity
+- Synthesized Themes should identify cross-persona patterns, not repeat individual findings
+- The Recommended Concept Updates table MUST use the standardized schema exactly as shown
+- Unresolved Questions should capture questions that emerged from interviews but cannot be answered without real user data or domain expertise
+- Full Transcript includes all 9 persona-impersonator responses organized by persona and phase
+- If a persona interview was partially completed (e.g., agent failure after Phase 2), include what was captured and note the gap
+
+---
+
+## Template
+
+```markdown
+# Synthetic User Interview Report
+
+**Product:** [product name]
+**Date:** [ISO 8601 date]
+**Personas interviewed:** [Persona 1 name] (Mould: [archetype], Overlay: [casting]), [Persona 2 name] (Mould: [archetype], Overlay: [casting]), [Persona 3 name] (Mould: [archetype], Overlay: [casting])
+
+---
+
+## Executive Summary
+
+[3-5 sentences summarizing the overall interview findings. What was the dominant sentiment? Where did the product concept hold up? Where did it crack? What was the most surprising finding?]
+
+---
+
+## Per-Persona Findings
+
+### [Persona 1 Name] -- [Archetype Label] / [Casting Overlay]
+
+**Key Reactions:**
+- Phase 1 (Blind): [1-2 sentences on whether they recognized and cared about the problem]
+- Phase 2 (Reveal): [1-2 sentences on their reaction to the full product concept]
+- Phase 3 (Stress): [1-2 sentences on their dealbreaker assessment]
+
+**Adoption Barriers:**
+- [Barrier 1 -- specific to this persona's context and casting overlay]
+- [Barrier 2]
+- [Barrier 3 if applicable]
+
+**Strongest Objections:**
+- [Objection 1 -- quoted or closely paraphrased from transcript]
+- [Objection 2]
+
+**What Resonated:**
+- [Element 1 -- what the persona responded positively to, if anything]
+- [Element 2 if applicable]
+
+**Verdict:** [The persona's honest adoption verdict from Phase 3 -- would they use it, pay for it, recommend it? 1-2 sentences.]
+
+---
+
+### [Persona 2 Name] -- [Archetype Label] / [Casting Overlay]
+
+[Same structure as Persona 1]
+
+---
+
+### [Persona 3 Name] -- [Archetype Label] / [Casting Overlay]
+
+[Same structure as Persona 1]
+
+---
+
+## Synthesized Themes
+
+Cross-persona patterns identified by the product strategist from all 9 interview responses.
+
+### Theme 1: [Theme Title]
+
+[Description of the pattern observed across multiple personas. Which personas exhibited this? How does it manifest differently through different casting overlays? What does this mean for the product concept?]
+
+### Theme 2: [Theme Title]
+
+[Same structure]
+
+### Theme 3: [Theme Title]
+
+[Same structure]
+
+[3-5 themes total]
+
+---
+
+## Recommended Concept Updates
+
+| # | Section | Current State | Recommended Change | Type | Rationale |
+|---|---------|---------------|--------------------|------|-----------|
+| 1 | [product concept section] | [what the concept currently says or assumes] | [specific change recommended] | [Add/Modify/Remove] | [which interview findings support this -- reference persona names and phases] |
+| 2 | ... | ... | ... | ... | ... |
+
+---
+
+## Unresolved Questions
+
+| # | Section | Question | Options | Assessment |
+|---|---------|----------|---------|------------|
+| 1 | [product concept section] | [question that emerged from interviews but cannot be answered without real user data] | [possible approaches to answering this] | [preliminary assessment based on interview data] |
+| 2 | ... | ... | ... | ... |
+
+---
+
+## Full Transcript
+
+### [Persona 1 Name] -- [Archetype Label] / [Casting Overlay]
+
+#### Phase 1: Initial Reaction
+
+**Questions asked:**
+[questions from product strategist]
+
+**Response:**
+[full persona-impersonator response]
+
+#### Phase 2: Deep Probing
+
+**Questions asked:**
+[questions from product strategist]
+
+**Response:**
+[full persona-impersonator response]
+
+#### Phase 3: Stress Test
+
+**Questions asked:**
+[questions from product strategist]
+
+**Response:**
+[full persona-impersonator response]
+
+---
+
+### [Persona 2 Name] -- [Archetype Label] / [Casting Overlay]
+
+[Same structure as Persona 1 transcript]
+
+---
+
+### [Persona 3 Name] -- [Archetype Label] / [Casting Overlay]
+
+[Same structure as Persona 1 transcript]
+```
+
+---
+
+## Section Guidance
+
+| Section | Source | Depth |
+|---------|--------|-------|
+| Executive Summary | Synthesized by skill from strategist output and interview transcripts | 3-5 sentences, high-level patterns and surprises |
+| Per-Persona Findings | Extracted from persona-impersonator responses across 3 phases | Per persona: key reactions (3 phases), adoption barriers (2-3), strongest objections (1-2), what resonated (1-2), verdict (1-2 sentences) |
+| Synthesized Themes | Product strategist synthesis of all 9 interview responses | 3-5 themes, each with cross-persona pattern analysis |
+| Recommended Concept Updates | Product strategist output using standardized table schema | One row per recommendation, Type must be Add/Modify/Remove, rationale must reference specific interview findings |
+| Unresolved Questions | Identified during strategist synthesis as questions requiring real data | One row per question, must specify which product concept section is affected and possible resolution approaches |
+| Full Transcript | Raw persona-impersonator responses, organized by persona and phase | Complete responses -- no summarization or editing |

package/plugins/arn-spark/skills/arn-spark-stress-interview/references/persona-casting-spec.md

@@ -0,0 +1,138 @@
+# Persona Casting Spec
+
+Defines the 3 casting overlays used by the `arn-spark-stress-interview` skill to create adversarial interview perspectives. Each overlay is applied on top of a base persona profile to focus the interview through a specific critical lens.
+
+## Overview
+
+Casting overlays do not replace the persona's identity -- they focus the persona's natural concerns toward specific categories of product weakness. A Pragmatist version of "Sarah, the senior product manager" evaluates differently from a Skeptic version of the same person, even though both share the same background, goals, and pain points.
+
+The 3 overlays are designed to cover complementary failure surfaces:
+- **Pragmatist:** Practical adoption and workflow integration failures
+- **Skeptic:** Trust, privacy, and systemic risk failures
+- **Power User:** Depth, scalability, and customization failures
+
+Together, they approximate the range of real user reactions that a product concept would face in the market.
+
+---
+
+## Overlay 1: Pragmatist
+
+### Adversarial Lens
+
+The Pragmatist evaluates everything through the lens of practical adoption. Their time is valuable, their current workflow is functional (if imperfect), and they need concrete evidence that switching is worth the disruption. They are not hostile to new tools -- they are hostile to wasted time.
+
+### How It Modifies Base Persona Responses
+
+- Amplifies the persona's existing concerns about workflow disruption and migration cost
+- Foregrounds time-to-value calculations: "How long until this actually helps me?"
+- Emphasizes comparison with current workarounds: "My spreadsheet is ugly but it works"
+- Reduces patience for abstract benefits: "Show me the before/after for my specific Tuesday morning"
+- Increases sensitivity to onboarding friction and learning curves
+
+### Weakness Categories Surfaced
+
+- Migration and onboarding friction that the product concept underestimates
+- Workflow integration gaps (the product works in isolation but not in the user's existing toolchain)
+- Time-to-value disconnect (the product requires significant setup before delivering value)
+- Reliability concerns (the product needs to work consistently, not just in demos)
+- Hidden costs of switching (not just price -- cognitive load, team retraining, data migration)
+
+### Casting Instructions for Persona Architect
+
+When generating a persona with the Pragmatist overlay for instantiation mode:
+1. Take the base persona mould and generate a concrete instance
+2. Emphasize the persona's current tool stack and daily workflow in the profile
+3. Include specific details about how the persona currently solves the problem (even poorly)
+4. Note the persona's switching history: what tools they have adopted and abandoned, and why
+5. Set the frustration threshold around workflow disruption rather than abstract concerns
+
+---
+
+## Overlay 2: Skeptic
+
+### Adversarial Lens
+
+The Skeptic evaluates everything through the lens of trust, privacy, and systemic risk. They have been burned before by products that over-promised and under-delivered, or that handled their data carelessly. They are not paranoid -- they are experienced. Marketing language makes them more suspicious, not less.
+
+### How It Modifies Base Persona Responses
+
+- Amplifies the persona's existing concerns about data handling, privacy, and security
+- Foregrounds trust establishment: "Who built this? What is their track record?"
+- Emphasizes vendor lock-in and exit strategies: "What happens if this company shuts down?"
+- Reduces trust in marketing claims: "Show me the architecture, not the landing page"
+- Increases sensitivity to vague privacy policies and unclear data ownership
+
+### Weakness Categories Surfaced
+
+- Trust and credibility gaps in the product concept's positioning
+- Privacy and data handling assumptions that are stated but not substantiated
+- Vendor lock-in risks that the product concept minimizes or ignores
+- Failure precedents: "Why would this succeed where [competitor] failed?"
+- Security architecture decisions that are deferred or hand-waved
+
+### Casting Instructions for Persona Architect
+
+When generating a persona with the Skeptic overlay for instantiation mode:
+1. Take the base persona mould and generate a concrete instance
+2. Emphasize the persona's past experiences with tool adoption failures
+3. Include specific details about data sensitivity in the persona's domain
+4. Note the persona's trust signals: what makes them trust a new tool, what triggers distrust
+5. Set the frustration threshold around trust violations rather than usability issues
+
+---
+
+## Overlay 3: Power User
+
+### Adversarial Lens
+
+The Power User evaluates everything through the lens of depth, customization, and scalability. They push every tool to its limits and need to know what happens at the edges. They are not looking for the simplest tool -- they are looking for the most capable one that respects their expertise.
+
+### How It Modifies Base Persona Responses
+
+- Amplifies the persona's existing need for control, customization, and advanced features
+- Foregrounds API access, automation, and integration capabilities
+- Emphasizes performance ceilings and scalability limits: "What happens at 10x?"
+- Reduces tolerance for opinionated defaults without escape hatches
+- Increases sensitivity to edge cases, error handling, and recovery mechanisms
+
+### Weakness Categories Surfaced
+
+- Customization and configuration limitations that constrain advanced workflows
+- API and integration gaps that prevent embedding the product in existing pipelines
+- Performance ceilings and scalability limits that the product concept does not address
+- Edge case handling: what happens when the happy path breaks?
+- Advanced workflow support: can the product grow with the user or does it plateau?
+
+### Casting Instructions for Persona Architect
+
+When generating a persona with the Power User overlay for instantiation mode:
+1. Take the base persona mould and generate a concrete instance
+2. Emphasize the persona's technical depth and existing integrations
+3. Include specific details about the persona's advanced use cases and automation needs
+4. Note the persona's history with outgrowing tools: what tools they have abandoned because of limits
+5. Set the frustration threshold around capability ceilings rather than initial usability
+
+---
+
+## Instantiation Workflow
+
+The interview skill uses the following process to generate cast personas:
+
+1. **Read persona moulds** from the product concept's Target Personas section
+2. **Select 3 moulds** (or use all if 3 or fewer exist). If more than 3 moulds exist, select the 3 that are most diverse in their adoption posture and technical sophistication.
+3. **For each mould, invoke the `arn-spark-persona-architect` agent in instantiation mode** via the Task tool, passing the model from `.arness/agent-models/spark.md` as the `model` parameter (see `plugins/arn-spark/skills/arn-spark-ensure-config/references/ensure-config.md` "Dispatch convention" for fallback). Context:
+   - The mould definition (abstracted profile)
+   - The casting overlay specification (from this document)
+   - The product concept summary (for domain grounding)
+4. **Receive back** a fully detailed concrete persona with the casting overlay baked into the profile
+5. **Pass the cast persona** to `arn-spark-persona-impersonator` for interview phases
+
+### Mould-to-Overlay Assignment
+
+Each mould gets exactly one overlay. Assignment follows this priority:
+
+1. If the mould's boundary conditions or variation axes suggest a natural fit (e.g., a mould with "risk-averse" in its personality spectrum maps well to Skeptic), use that alignment.
+2. If no natural fit exists, assign overlays to maximize coverage: the mould whose persona is most likely to challenge practical adoption gets Pragmatist, the mould most sensitive to trust gets Skeptic, and the mould with the deepest technical range gets Power User.
+3. If all moulds are similar, assign overlays round-robin to ensure all 3 lenses are represented.
+
+The goal is not to assign the "matching" overlay but to ensure all 3 adversarial perspectives are represented across the interview set.

package/plugins/arn-spark/skills/arn-spark-stress-premortem/SKILL.md

@@ -0,0 +1,181 @@
+---
+name: arn-spark-stress-premortem
+description: >-
+  This skill should be used when the user says "pre-mortem", "premortem",
+  "risk analysis", "stress premortem", "failure analysis", "what could go wrong",
+  "pre mortem", "investigate failure", "failure modes", or wants to stress-test a
+  product concept by applying Gary Klein's pre-mortem methodology to identify
+  hypothetical failure root causes, early warning signals, and mitigation
+  strategies. Produces a pre-mortem report with 3 root causes across distinct
+  failure dimensions and recommended concept updates.
+version: 1.0.0
+---
+
+# Arness Spark Stress Pre-Mortem
+
+Stress-test a product concept using Gary Klein's pre-mortem methodology. Instead of asking "what could go wrong?" (which invites optimism bias), the pre-mortem declares that the product has already launched and failed, then investigates why.
+
+The process works like this:
+1. **Accept the premise:** It is 12 months after launch. The product was shut down today.
+2. **Investigate:** A forensic investigator agent works backward from the failure to identify 3 distinct root causes -- a core experience flaw (A), a trust/security blind spot (B), and a target audience assumption error (C).
+3. **Assess:** Each root cause gets a causal chain, early warning signals, mitigation strategies, and a likelihood/severity rating.
+4. **Prioritize:** Root causes are mapped on a risk priority matrix to identify what needs immediate attention.
+
+This technique surfaces failure modes that optimism obscures. The product concept is read but never modified -- all recommendations are captured in the pre-mortem report for later review.
+
+## Prerequisites
+
+### Configuration Check
+
+1. Read the project's `arness.md` and check for a `## Arness` section
+2. If found, extract the configured **Vision directory** and **Reports directory** paths
+3. If no `## Arness` section exists or Arness Spark fields are missing, inform the user: "Arness Spark is not configured for this project yet. Run `/arn-brainstorming` to get started — it will set everything up automatically." Do not proceed without it.
+4. If the Reports directory does not exist, create it with `mkdir -p <reports-dir>/stress-tests/`
+
+### Data Availability
+
+| Artifact | Status | Location | Fallback |
+|----------|--------|----------|----------|
+| Product concept | REQUIRED | `<vision-dir>/product-concept.md` | Cannot proceed without it -- suggest running `/arn-spark-discover` |
+| Product pillars | ENRICHES | Product Pillars section of product concept | Investigation proceeds but pillar-as-evidence analysis is less targeted |
+| Competitive landscape | ENRICHES | Competitive Landscape section of product concept | Root Cause C (market misread) is less grounded in competitive dynamics |
+| Target personas | ENRICHES | Target Personas section of product concept | Root Cause A and C are less grounded in persona-specific failure scenarios |
+
+**Product concept fallback:**
+
+If no product concept exists:
+
+Ask the user: **"No product concept found. The pre-mortem needs a product concept to investigate. How would you like to proceed?"**
+1. Run `/arn-spark-discover` to create a product concept first
+2. Describe the product now (I will conduct the pre-mortem from your description)
+3. Skip the pre-mortem stress test
+
+If the user chooses option 2, collect a product description and proceed with a reduced-fidelity investigation (note in the report that the investigation was based on a verbal description rather than a full product concept).
+
+## Workflow
+
+### Step 1: Load References
+
+Load the pre-mortem protocol and report template:
+> Read `${CLAUDE_PLUGIN_ROOT}/skills/arn-spark-stress-premortem/references/premortem-protocol.md`
+> Read `${CLAUDE_PLUGIN_ROOT}/skills/arn-spark-stress-premortem/references/premortem-report-template.md`
+
+### Step 2: Read Product Concept and Extract Context
+
+Read the product concept from `<vision-dir>/product-concept.md`. Extract:
+- Full product concept (the investigator needs the complete document)
+- Product pillars (used as forensic evidence -- pillars often become failure vectors)
+- Competitive landscape (grounds Root Cause C in real competitive dynamics)
+- Target personas (grounds Root Causes A and C in specific user scenarios)
+- Core experience (primary investigation target for Root Cause A)
+- Trust & security model (primary investigation target for Root Cause B)
+
+### Step 3: Invoke Forensic Investigator
+
+Invoke the `arn-spark-forensic-investigator` agent via the Task tool, passing the model from `.arness/agent-models/spark.md` as the `model` parameter (see `plugins/arn-spark/skills/arn-spark-ensure-config/references/ensure-config.md` "Dispatch convention" for fallback). Context:
+
+--- PRODUCT CONCEPT ---
+[full product concept document]
+--- END PRODUCT CONCEPT ---
+
+--- PRODUCT PILLARS ---
+[product pillars section -- these are forensic evidence, not goals to protect]
+--- END PRODUCT PILLARS ---
+
+--- COMPETITIVE LANDSCAPE ---
+[competitive landscape section, or "Not available" if absent]
+--- END COMPETITIVE LANDSCAPE ---
+
+--- TARGET PERSONAS ---
+[target personas section from the product concept, or "Not available" if absent]
+--- END TARGET PERSONAS ---
+
+--- INVESTIGATION TASK ---
+Standard investigation: Generate 3 root causes across distinct failure dimensions:
+- Root Cause A: Core Experience Flaw leading to user churn
+- Root Cause B: Trust & Security Blind Spot leading to breach or exodus
+- Root Cause C: Target Audience Assumption that was wrong
+
+For each root cause: failure narrative, causal chain (4 links), early warning signals (3), mitigation strategies (3), likelihood assessment, severity assessment.
+
+Include a Recommended Concept Updates table and Unresolved Questions section.
+--- END INVESTIGATION TASK ---
+
+### Step 4: Validate Investigation Quality
+
+Review the forensic investigator's output for quality:
+
+1. **3 distinct root causes:** Each root cause must have a distinct causal chain. If two root causes share the same underlying mechanism, they are one root cause, not two.
+2. **Specificity:** Root causes must reference specific elements of the product concept (features, claims, personas, pillars). Generic failures that could apply to any product are rejected.
+3. **Adversarial depth:** Root causes must be genuinely adversarial -- not soft, hedged, or diplomatic. Each should make someone wince and say "that could actually happen."
+
+**If quality is insufficient:** Retry with an explicit adversarial instruction:
+
+"The investigation was too soft. Requirements:
+- Each root cause must quote or reference a specific claim from the product concept
+- Each causal chain must have 4 distinct links, not 2 restated
+- Each early warning signal must include a specific metric threshold or observable behavior
+- Failure narratives must describe what users actually experienced, not abstract disappointment"
+
+If the retry also fails quality checks, proceed with the best available output and note the quality gap in the report.
+
+### Step 5: Draft Recommended Concept Updates
+
+Review the investigator's Recommended Concept Updates table. Ensure:
+- Each recommendation uses the 6-column schema: `# | Section | Current State | Recommended Change | Type | Rationale`
+- Each recommendation traces to a specific root cause
+- Type column uses Add/Modify/Remove
+- Recommendations from "Address immediately" and "Mitigate" cells in the risk priority matrix are all represented
+
+If the investigator's recommendations are incomplete, supplement from the mitigation strategies.
+
+### Step 6: Assemble and Write Report
+
+Using the pre-mortem report template:
+1. Populate all sections with investigator output
+2. Construct the Risk Priority Matrix from likelihood/severity assessments
+3. Write the report to `<reports-dir>/stress-tests/premortem-report.md`
+
+Present a summary to the user:
+
+"Pre-mortem investigation complete. Report saved to `[path]`.
+
+**Failure premise:** [Product name] launched and was shut down 12 months later.
+
+**Root causes identified:**
+- **A -- [Title]:** [1-sentence summary] (Likelihood: [L], Severity: [S])
+- **B -- [Title]:** [1-sentence summary] (Likelihood: [L], Severity: [S])
+- **C -- [Title]:** [1-sentence summary] (Likelihood: [L], Severity: [S])
+
+**Risk priority:** [N] root causes require immediate attention, [N] require mitigation
+**Recommended concept updates:** [N] recommendations ([X] Add, [Y] Modify, [Z] Remove)
+**Unresolved questions:** [N]
+
+This report will be used by `/arn-spark-concept-review` to propose changes to the product concept."
+
+## Agent Invocation Guide
+
+| Situation | Agent | Mode/Context |
+|-----------|-------|--------------|
+| Standard pre-mortem investigation | `arn-spark-forensic-investigator` | Full product concept with pillars and competitive landscape |
+| Targeted deep-dive (future) | `arn-spark-forensic-investigator` | Specific failure scenario for extended analysis |
+
+## Error Handling
+
+- **Forensic investigator produces soft/hedged failures:** Retry with explicit adversarial instruction emphasizing that failures must be specific, vivid, and grounded in product concept details. Include: "Generic failures like 'users did not find it useful' are worthless -- explain exactly why and how."
+
+- **Forensic investigator produces fewer than 3 root causes:** Retry specifying which failure dimension is missing and providing additional context for that dimension. If retry still produces fewer than 3, proceed with available output and note the gap.
+
+- **Forensic investigator produces overlapping root causes:** Retry specifying that each root cause must have a distinct causal mechanism. If two root causes share the same first link in the causal chain, they are one root cause.
+
+- **Agent invocation fails entirely:** Retry once with a simplified prompt. If retry fails:
+  Ask the user: **"Agent invocation failed. How would you like to proceed?"**
+  1. Retry
+  2. Skip this step
+  3. Abort
+
+## Constraints
+
+- **Read-only with respect to product-concept.md.** The pre-mortem skill reads the product concept but NEVER modifies it. All recommendations are captured in the pre-mortem report.
+- **3 root causes across distinct dimensions.** The standard investigation always targets 3 failure dimensions (core experience, trust/security, audience). This ensures coverage across the most common failure modes.
+- **Report overwrites on re-run.** If `premortem-report.md` already exists, it is overwritten. Git provides history.