/arn-spark-stress-premortem

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 `CLAUDE.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 (using `AskUserQuestion`): **"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 under