@fredcallagan/arn-spark 5.1.0

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

@@ -0,0 +1,112 @@
+# Pre-Mortem Protocol
+
+Adapted from Gary Klein's pre-mortem methodology for product concept stress testing. This document is consumed by the `arn-spark-stress-premortem` skill to frame the forensic investigator's investigation.
+
+## Overview
+
+The pre-mortem technique inverts the typical risk assessment. Instead of asking "what could go wrong?" (which invites optimism bias and superficial answers), the pre-mortem declares that the product has already failed and asks "why did it fail?" This psychological reframing unlocks deeper, more specific failure analysis because it removes the social pressure to be optimistic and replaces it with the intellectual challenge of explaining a known outcome.
+
+**The premise:** It is 12 months after launch. The product was shut down today. You are not predicting failure -- you are investigating a failure that has already happened.
+
+---
+
+## Methodology
+
+### Step 1: Establish the Failure Premise
+
+Set the temporal frame:
+- The product launched 12 months ago with the features and scope described in the product concept
+- Initial reception was [variable -- the investigator determines this based on the concept's strengths and weaknesses]
+- Despite the team's best efforts, the product was shut down today
+- Your job is to explain why
+
+The failure premise must be stated explicitly at the beginning of the investigation. This is not a hypothetical -- it is a forensic reconstruction.
+
+### Step 2: Work Backward from Failure
+
+The investigator works backward from the shutdown to identify root causes. Each root cause follows a causal chain:
+
+```
+Shutdown decision
+  <- Trigger event (the specific metric or incident that forced the decision)
+    <- Compounding effect (what made recovery impossible)
+      <- Execution failure (how the design decision played out in practice)
+        <- Design assumption (the original decision or assumption in the product concept)
+```
+
+### Step 3: Identify Root Causes Across Failure Dimensions
+
+The standard investigation produces 3 root causes, each targeting a distinct failure dimension:
+
+#### Dimension A: User Adoption Failure / Core Experience Flaw
+The product's central interaction model had a fundamental flaw. Users tried it and left. This is not about missing features -- it is about the core experience itself being wrong, insufficient, or misaligned with actual user needs.
+
+Investigation angles:
+- Gap between promised experience and actual experience
+- Onboarding friction that prevented users from reaching the value
+- Core interaction that was interesting in demos but tedious in daily use
+- Product pillars that conflicted with each other in practice
+
+#### Dimension B: Trust / Security / Compliance Failure
+The product had a trust assumption that proved catastrophically wrong. A data breach, a privacy scandal, a compliance failure, or a trust violation that destroyed user confidence overnight.
+
+Investigation angles:
+- Data handling assumptions that were tested by a real incident
+- Security architecture decisions that seemed reasonable but failed under load or adversarial conditions
+- Compliance requirements that emerged post-launch and could not be met
+- Trust signals that were sufficient for early adopters but not for mainstream users
+
+#### Dimension C: Market / Audience Misread
+The product was built for the wrong people, or the right people in the wrong context. The personas were plausible but did not match reality. The market existed but the product's entry point was misaligned.
+
+Investigation angles:
+- Which persona assumption was most wrong, and how the actual early adopters differed
+- Market timing: too early, too late, or right time but wrong entry point
+- Competitive response that the product concept underestimated
+- Adjacent market or use case that users actually wanted but the product did not pivot toward
+
+### Step 4: Evaluate Each Root Cause
+
+For each root cause, assess:
+
+**Likelihood:** How probable is this failure chain given the product concept's current design?
+- **High:** The product concept contains specific elements that directly increase this risk
+- **Medium:** The product concept does not directly address this risk but is not uniquely vulnerable
+- **Low:** The product concept has elements that mitigate this risk, but it cannot be eliminated
+
+**Severity:** If this failure chain occurs, how bad is the outcome?
+- **Critical:** Product shutdown -- unrecoverable
+- **High:** Significant user loss or trust damage -- recoverable but costly
+- **Medium:** Growth stalled or market position weakened -- manageable with pivots
+
+### Step 5: Construct Risk Priority Matrix
+
+Map root causes on a 3x3 matrix:
+
+|  | Low Likelihood | Medium Likelihood | High Likelihood |
+|--|---------------|-------------------|-----------------|
+| **Critical Severity** | Monitor | Mitigate | Address immediately |
+| **High Severity** | Monitor | Mitigate | Address immediately |
+| **Medium Severity** | Accept | Monitor | Mitigate |
+
+Root causes in "Address immediately" cells must appear in the Recommended Concept Updates table.
+
+---
+
+## Psychological Framing Instructions for the Forensic Investigator
+
+These instructions are passed to the `arn-spark-forensic-investigator` agent to establish the correct mindset:
+
+1. **You are not defending this product.** You are not an advocate, a coach, or a well-wisher. You are a forensic investigator called in after the shutdown, piecing together what went wrong and why nobody saw it coming.
+
+2. **The failure has already happened.** Do not hedge with "might" or "could." The product failed. Your job is to explain why, not to predict whether it will.
+
+3. **Be specific, not generic.** "Users did not find it useful" is not a root cause. "Users expected [specific claim from concept] but experienced [specific reality], leading to [specific metric decline] by month [N]" is a root cause.
+
+4. **Use the product concept against itself.** Quote specific claims, features, and design decisions. A pre-mortem that could apply to any product is a failed pre-mortem.
+
+5. **Product pillars are forensic evidence.** Pillars often become failure vectors. A "zero-configuration" pillar might mean the product could not accommodate enterprise deployment requirements. A "privacy-first" pillar might mean the product could not implement the analytics needed to detect churn early enough.
+
+6. **Early warning signals must be observable.** Not "user satisfaction declining" but "NPS scores for the [specific feature] flow dropping below 30 within 60 days" or "support ticket volume for [specific issue] exceeding [threshold] by month 2."
+
+7. **Mitigation strategies must change the product concept.** Not "improve onboarding" but "add a guided first-run experience that demonstrates [specific value] within 90 seconds by [specific mechanism]."

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

@@ -0,0 +1,158 @@
+# Pre-Mortem Report Template
+
+Template for the pre-mortem risk mitigation stress test report. This document is consumed by the `arn-spark-stress-premortem` skill when assembling the final report from the forensic investigator's output.
+
+## Instructions for arn-spark-stress-premortem
+
+When populating this template:
+
+- Every section below MUST appear in the output
+- Replace all bracketed placeholders with concrete content from the forensic investigator's output
+- Each Root Cause must have ALL 6 subsections: Failure Narrative, Causal Chain, Early Warning Signals, Mitigation Strategies, Likelihood, Severity
+- The Risk Priority Matrix must accurately reflect the Likelihood/Severity assessments from the root causes
+- The Recommended Concept Updates table MUST use the standardized schema exactly as shown
+- Unresolved Questions should capture questions that the pre-mortem raised but could not answer
+- If the forensic investigator produced fewer than 3 root causes or overlapping root causes, note this in the report and explain what happened
+
+---
+
+## Template
+
+```markdown
+# Pre-Mortem Investigation Report
+
+**Product:** [product name]
+**Date:** [ISO 8601 date]
+**Failure premise:** It is [date + 12 months]. [Product name] launched 12 months ago and was shut down today.
+
+---
+
+## Executive Summary
+
+[3-5 sentences summarizing the investigation findings. What was the most likely failure mode? What was the most severe? What was the most surprising finding? Overall risk posture of the product concept.]
+
+---
+
+## Failure Premise
+
+[2-3 sentences establishing the temporal frame and initial conditions. How did the launch go? What was the initial reception? What happened in the months that followed?]
+
+---
+
+## Root Cause A: Core Experience Flaw -- [Specific Flaw Title]
+
+**Failure Narrative:**
+[3-5 sentences describing what happened from the user's perspective. Specific, vivid, grounded in the product concept's own claims. Reference specific features, interactions, and personas.]
+
+**Causal Chain:**
+1. [Design assumption in the product concept]
+2. [How that assumption played out in practice]
+3. [The compounding effect that made recovery impossible]
+4. [The specific trigger event that forced shutdown]
+
+**Early Warning Signals:**
+- [Signal 1 -- observable in month 1-2, with specific metric or behavior]
+- [Signal 2 -- a metric or user behavior pattern]
+- [Signal 3 -- a qualitative signal from feedback or support]
+
+**Mitigation Strategies:**
+1. [Specific change to the product concept that addresses the root cause]
+2. [Monitoring or validation approach to catch early warning signals]
+3. [Design alternative that avoids the failure chain entirely]
+
+**Likelihood:** [High / Medium / Low] -- [1-sentence justification referencing specific product concept elements]
+**Severity:** [Critical / High / Medium] -- [1-sentence justification]
+
+---
+
+## Root Cause B: Trust & Security Blind Spot -- [Specific Blind Spot Title]
+
+**Failure Narrative:**
+[Same structure as Root Cause A]
+
+**Causal Chain:**
+1. [Trust/security assumption in the product concept]
+2. [How that assumption was tested by real-world conditions]
+3. [The compounding effect -- loss of user confidence, regulatory response, competitive messaging]
+4. [The trigger event -- specific incident or revelation]
+
+**Early Warning Signals:**
+- [Signal 1]
+- [Signal 2]
+- [Signal 3]
+
+**Mitigation Strategies:**
+1. [Strategy 1]
+2. [Strategy 2]
+3. [Strategy 3]
+
+**Likelihood:** [High / Medium / Low] -- [justification]
+**Severity:** [Critical / High / Medium] -- [justification]
+
+---
+
+## Root Cause C: Target Audience Assumption -- [Specific Assumption Title]
+
+**Failure Narrative:**
+[Same structure as Root Cause A]
+
+**Causal Chain:**
+1. [Audience assumption in the product concept]
+2. [How the actual market differed from the assumed market]
+3. [The compounding effect -- wrong users, wrong positioning, wrong growth strategy]
+4. [The trigger event -- specific metric or market shift]
+
+**Early Warning Signals:**
+- [Signal 1]
+- [Signal 2]
+- [Signal 3]
+
+**Mitigation Strategies:**
+1. [Strategy 1]
+2. [Strategy 2]
+3. [Strategy 3]
+
+**Likelihood:** [High / Medium / Low] -- [justification]
+**Severity:** [Critical / High / Medium] -- [justification]
+
+---
+
+## Risk Priority Matrix
+
+|  | Low Likelihood | Medium Likelihood | High Likelihood |
+|--|---------------|-------------------|-----------------|
+| **Critical Severity** | [Root Cause letter if applicable] | [Root Cause letter if applicable] | [Root Cause letter if applicable] |
+| **High Severity** | [Root Cause letter if applicable] | [Root Cause letter if applicable] | [Root Cause letter if applicable] |
+| **Medium Severity** | [Root Cause letter if applicable] | [Root Cause letter if applicable] | [Root Cause letter if applicable] |
+
+---
+
+## 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 root cause this addresses -- reference Root Cause letter and mitigation strategy number] |
+| 2 | ... | ... | ... | ... | ... |
+
+---
+
+## Unresolved Questions
+
+| # | Section | Question | Options | Assessment |
+|---|---------|----------|---------|------------|
+| 1 | [product concept section] | [question that the pre-mortem raised but could not answer] | [possible approaches to answering this] | [preliminary assessment based on investigation findings] |
+| 2 | ... | ... | ... | ... |
+```
+
+---
+
+## Section Guidance
+
+| Section | Source | Depth |
+|---------|--------|-------|
+| Executive Summary | Synthesized by skill from forensic investigator output | 3-5 sentences, overall risk posture |
+| Failure Premise | Set by skill based on product concept | 2-3 sentences establishing temporal frame |
+| Root Cause A/B/C | Forensic investigator output, one per failure dimension | Each root cause: narrative (3-5 sentences), causal chain (4 links), early warning signals (3), mitigation strategies (3), likelihood and severity with justification |
+| Risk Priority Matrix | Derived from root cause likelihood/severity assessments | 3x3 matrix with root cause letters placed in cells |
+| Recommended Concept Updates | Derived from root causes in "Address immediately" or "Mitigate" cells | One row per recommendation, Type must be Add/Modify/Remove, rationale must reference specific root cause and mitigation strategy |
+| Unresolved Questions | Identified during investigation as questions requiring real data | One row per question, must specify which product concept section is affected |

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

@@ -0,0 +1,206 @@
+---
+name: arn-spark-stress-prfaq
+description: >-
+  This skill should be used when the user says "prfaq", "pr faq", "pr/faq",
+  "press release stress test", "stress prfaq", "amazon pr faq method",
+  "test the pitch with a pr/faq", "validate concept through pr/faq",
+  "critique press release", "pr faq stress test",
+  "will this marketing story hold up", or wants to stress-test a product concept by drafting a
+  compelling press release and FAQ, then adversarially critiquing it to find
+  where the concept cracks under scrutiny. Produces a PR/FAQ report with the
+  full draft, adversarial questions, crack point analysis, and recommended
+  concept updates.
+version: 1.0.0
+---
+
+# Arness Spark Stress PR/FAQ
+
+Stress-test a product concept using Amazon's PR/FAQ method. This technique forces the product concept through two filters:
+
+1. **Draft phase:** A marketing PM agent writes the best possible public story -- a compelling press release, customer FAQ, and internal FAQ. If the press release is unconvincing, the product concept likely has clarity problems.
+2. **Critique phase:** The same marketing PM agent (in a separate invocation, with no memory of drafting) adversarially attacks the draft -- finding questions the PR dodges, identifying crack points where claims exceed substance, and recommending concept changes.
+
+The two phases use **separate agent invocations** to prevent rubber-stamping. A critic who remembers being the drafter unconsciously defends what it wrote. Separate invocations force genuine adversarial evaluation.
+
+The product concept is read but never modified -- all recommendations are captured in the PR/FAQ 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 | Draft messaging is less focused; critique has fewer anchors |
+| Competitive landscape | ENRICHES | Competitive Landscape section of product concept | Draft positioning is less grounded in market context |
+| Target personas | ENRICHES | Target Personas section of product concept | Customer quote in press release is less persona-specific |
+
+**Standard fallback cascade:**
+
+If no product concept exists:
+
+Ask the user: **"No product concept found. The PR/FAQ stress test needs a product concept to draft and critique messaging for. 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 PR/FAQ from your description)
+3. Skip the PR/FAQ stress test
+
+If the user chooses option 2, collect a product description and proceed with a reduced-fidelity test (note in the report that the test was based on a verbal description rather than a full product concept).
+
+## Workflow
+
+### Step 1: Load References
+
+Load the PR/FAQ workflow and report template:
+> Read `${CLAUDE_PLUGIN_ROOT}/skills/arn-spark-stress-prfaq/references/prfaq-workflow.md`
+> Read `${CLAUDE_PLUGIN_ROOT}/skills/arn-spark-stress-prfaq/references/prfaq-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 (both draft and critique need the complete document)
+- Product pillars (anchors messaging in draft, tested for sincerity in critique)
+- Competitive landscape (grounds positioning in real market context)
+- Target personas (for realistic customer quote in press release)
+- Core experience (primary material for the solution paragraph)
+
+### Step 3: Phase 1 -- Draft
+
+Invoke the `arn-spark-marketing-pm` agent in **draft 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:
+
+--- PRODUCT CONCEPT ---
+[full product concept document]
+--- END PRODUCT CONCEPT ---
+
+--- PRODUCT PILLARS ---
+[product pillars section]
+--- END PRODUCT PILLARS ---
+
+--- OPERATING MODE ---
+draft
+--- END OPERATING MODE ---
+
+Receive back the complete draft: press release (400-600 words), customer FAQ (5-8 entries), internal FAQ (3-5 entries).
+
+**Quality check before proceeding:**
+- Press release must be 400-600 words and compelling (would a reporter find this newsworthy? Does it lead with customer value, not features?)
+- Customer FAQ answers must be concrete with specific examples, not evasive hedging
+- Internal FAQ questions must address genuine tensions or risky claims in the press release
+- Customer quote must use colloquial language and personal emotion, not corporate phrasing
+
+If the draft is too thin or generic, retry with more specific context:
+
+"The draft needs to be more specific. Ground it in these details:
+- Target persona for the customer quote: [specific persona from product concept]
+- Key competitive differentiator: [from competitive landscape]
+- Core interaction to highlight: [from core experience]
+- Most important pillar to anchor messaging: [from product pillars]"
+
+### Step 4: Phase 2 -- Critique
+
+Invoke the `arn-spark-marketing-pm` agent in **critique 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:
+
+--- PRODUCT CONCEPT ---
+[full product concept document -- same as Phase 1]
+--- END PRODUCT CONCEPT ---
+
+--- PRODUCT PILLARS ---
+[product pillars section -- same as Phase 1]
+--- END PRODUCT PILLARS ---
+
+--- OPERATING MODE ---
+critique
+--- END OPERATING MODE ---
+
+--- DRAFT OUTPUT ---
+[complete draft from Phase 1 -- press release + customer FAQ + internal FAQ]
+--- END DRAFT OUTPUT ---
+
+**Critical:** This MUST be a separate agent invocation from Phase 1. Include ONLY: the full product concept, the product pillars, the complete draft output (press release + FAQs), and the critique task instructions. Do NOT include any conversation context from the draft phase or any conversational recap.
+
+Receive back: adversarial questions (5-8), crack points (3-5), recommended concept updates table, unresolved questions.
+
+**Quality check:**
+- Adversarial questions must target concept substance, not word choice
+- Crack points must identify real gaps between claims and substance
+- At least one crack point should reference a product pillar
+- Recommendations must change the product concept, not the press release
+
+If the critique is too soft, retry with explicit adversarial instruction:
+
+"The critique needs to be sharper. Requirements:
+- At least 2 adversarial questions rated High damage potential
+- Crack points must reference specific claims from the press release and specific gaps in the product concept
+- If no crack point makes someone say 'we need to address that before building this,' the critique is too gentle
+- Do not find ways the messaging could be improved -- find ways the underlying concept fails"
+
+### Step 5: Draft Recommended Concept Updates
+
+Review the critique's Recommended Concept Updates table. Ensure:
+- Each recommendation uses the standardized schema
+- Each recommendation traces to a specific crack point
+- Type column uses Add/Modify/Remove
+- All crack points with High damage potential adversarial questions have corresponding recommendations
+
+If the critique's recommendations are incomplete, supplement from the crack point "What needs strengthening" fields.
+
+### Step 6: Assemble and Write Report
+
+Using the PR/FAQ report template:
+1. Populate all sections with draft output and critique output
+2. Include the full press release text, all FAQ entries, all adversarial questions, and all crack points
+3. Write the report to `<reports-dir>/stress-tests/prfaq-report.md`
+
+Present a summary to the user:
+
+"PR/FAQ stress test complete. Report saved to `[path]`.
+
+**Draft assessment:** [1 sentence on whether the product story was compelling]
+
+**Key critique findings:**
+- **Adversarial questions:** [N] questions the PR dodges ([X] High damage, [Y] Medium, [Z] Low)
+- **Crack points:** [N] places where the concept cracks under scrutiny
+
+**Top crack point:** [The highest-impact crack point in 1 sentence]
+
+**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 |
+|-----------|-------|--------------|
+| Write press release and FAQ | `arn-spark-marketing-pm` | Draft mode with product concept and pillars |
+| Adversarially critique the draft | `arn-spark-marketing-pm` | Critique mode with product concept, pillars, and draft output (separate invocation) |
+
+## Error Handling
+
+- **Marketing PM produces generic/thin draft:** Retry with more specific context from the product concept -- highlight specific features, personas, and competitive positioning. If retry still produces thin output:
+  Ask the user: **"The PR/FAQ draft is too generic to produce a useful critique. How would you like to proceed?"**
+  1. Retry with additional context
+  2. Proceed with the current draft (critique may be less effective)
+  3. Abort the PR/FAQ stress test
+
+- **Marketing PM produces soft critique:** Retry with explicit adversarial instruction emphasizing that the critique must target concept substance, not copywriting quality. Include: "If no crack point makes someone uncomfortable, the critique has failed."
+
+- **Critique mode receives draft context (accidental context leak):** This should not happen if invocations are properly separated. If detected (the critique references drafting decisions or uses phrases like "when I wrote..."), discard the critique and re-invoke in critique mode with only the draft output and product concept -- no conversational context.
+
+- **Any 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 PR/FAQ skill reads the product concept but NEVER modifies it. All recommendations are captured in the PR/FAQ report.
+- **Separate invocations for draft and critique.** This is a hard requirement, not a preference. Same-context self-critique produces rubber-stamp results. The draft and critique MUST be separate agent invocations with no shared conversational context.
+- **Report overwrites on re-run.** If `prfaq-report.md` already exists, it is overwritten. Git provides history.

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

@@ -0,0 +1,139 @@
+# PR/FAQ Report Template
+
+Template for the PR/FAQ stress test report. This document is consumed by the `arn-spark-stress-prfaq` skill when assembling the final report from the marketing PM's draft and critique outputs.
+
+## Instructions for arn-spark-stress-prfaq
+
+When populating this template:
+
+- Every section below MUST appear in the output
+- Replace all bracketed placeholders with concrete content from the marketing PM's draft and critique outputs
+- The Press Release should be the FULL text from draft mode, not a summary
+- Customer FAQ and Internal FAQ should include ALL entries from draft mode
+- Adversarial Questions and Crack Points should include ALL entries from critique mode
+- The Recommended Concept Updates table MUST use the standardized schema exactly as shown
+- Unresolved Questions should capture questions that emerged from the critique but cannot be answered without real user data or market research
+- If either draft or critique mode failed, note what was captured and explain the gap
+
+---
+
+## Template
+
+```markdown
+# PR/FAQ Stress Test Report
+
+**Product:** [product name]
+**Date:** [ISO 8601 date]
+
+---
+
+## Executive Summary
+
+[3-5 sentences summarizing the PR/FAQ stress test findings. Was the product story compelling? Where did it crack? What was the most significant finding from the critique?]
+
+---
+
+## Press Release
+
+### [Headline]
+
+**[Subheading]**
+
+[Problem paragraph]
+
+[Solution paragraph]
+
+> "[Customer quote]"
+> -- [Persona name], [role/context]
+
+[Product details paragraph]
+
+**[Call to action]**
+
+---
+
+## Customer FAQ
+
+### Q: [Question 1]
+[Answer]
+
+### Q: [Question 2]
+[Answer]
+
+[... 5-8 entries total]
+
+---
+
+## Internal FAQ
+
+### Q: [Question 1]
+[Answer]
+
+### Q: [Question 2]
+[Answer]
+
+[... 3-5 entries total]
+
+---
+
+## Adversarial Questions
+
+### 1. [Question]
+**Why the PR dodges this:** [explanation of what claim is made and what evidence is missing]
+**Damage potential:** [High/Medium/Low] -- [brief justification]
+
+### 2. [Question]
+**Why the PR dodges this:** [explanation]
+**Damage potential:** [High/Medium/Low] -- [justification]
+
+[... 5-8 entries total]
+
+---
+
+## Crack Point Analysis
+
+### 1. [Crack Point Title]
+- **What the concept claims:** [specific claim from the PR/FAQ]
+- **What the question reveals:** [the gap, assumption, or contradiction exposed]
+- **What needs strengthening:** [actionable recommendation for the product concept]
+
+### 2. [Crack Point Title]
+- **What the concept claims:** [specific claim]
+- **What the question reveals:** [gap exposed]
+- **What needs strengthening:** [recommendation]
+
+[... 3-5 entries 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 crack point this addresses -- reference crack point number] |
+| 2 | ... | ... | ... | ... | ... |
+
+---
+
+## Unresolved Questions
+
+| # | Section | Question | Options | Assessment |
+|---|---------|----------|---------|------------|
+| 1 | [product concept section] | [question that the PR/FAQ critique raised but cannot be answered without real data] | [possible approaches to answering this] | [preliminary assessment based on critique findings] |
+| 2 | ... | ... | ... | ... |
+```
+
+---
+
+## Section Guidance
+
+| Section | Source | Depth |
+|---------|--------|-------|
+| Executive Summary | Synthesized by skill from draft quality assessment and critique findings | 3-5 sentences, overall messaging integrity assessment |
+| Press Release | Marketing PM draft mode output | Full text, 400-600 words, Amazon PR/FAQ format |
+| Customer FAQ | Marketing PM draft mode output | 5-8 entries with concrete, specific answers |
+| Internal FAQ | Marketing PM draft mode output | 3-5 entries with honest, hard-question answers |
+| Adversarial Questions | Marketing PM critique mode output | 5-8 questions with dodge explanations and damage potential ratings |
+| Crack Point Analysis | Marketing PM critique mode output | 3-5 crack points with: claim, revelation, and strengthening recommendation |
+| Recommended Concept Updates | Marketing PM critique mode output, reviewed by skill | One row per recommendation, Type must be Add/Modify/Remove, rationale must reference specific crack point |
+| Unresolved Questions | Identified during critique as questions requiring real data | One row per question, must specify which product concept section is affected |