@massa-ai/cursor-plugin 1.6.0

package/skills/massa-ai/references/the-fool/pre-mortem-analysis.md

@@ -0,0 +1,200 @@
+# Pre-Mortem Analysis
+
+Pre-mortem methodology (Gary Klein) with second-order thinking for identifying how plans fail before they fail.
+
+## Core Principle
+
+A pre-mortem inverts the question. Instead of "Will this work?" ask: **"It's 6 months from now and this has failed. Why?"** This psychological shift bypasses optimism bias by making failure the starting point, not the thing to be argued against.
+
+Research shows prospective hindsight increases correct failure identification by 30% compared to asking "what could go wrong?" directly.
+
+## Process
+
+1. **Set the scene** — "Imagine it's [timeframe] from now. This plan has failed. Not a small setback — a clear failure."
+2. **Generate failure narratives** — Write specific stories about how it failed (silent individual generation first, then present)
+3. **Rank by likelihood and impact** — Not all failures are equal
+4. **Trace consequence chains** — First → second → third order effects
+5. **Identify early warning signs** — What would you see before the failure materializes?
+6. **Apply the inversion technique** — "What would guarantee this fails?" Then check if any conditions exist
+7. **Design mitigations** — Concrete actions, not vague "be careful"
+
+## Failure Narrative Construction
+
+Failure narratives must be specific. "It didn't scale" is not a narrative. "At 50K concurrent users, the database connection pool exhausted, causing cascading timeouts across all services, which triggered the circuit breaker to reject all requests for 4 minutes during peak hours" is a narrative.
+
+### Specificity Checklist
+
+Every narrative must pass all 5 checks:
+
+- [ ] Names a specific trigger (not "something goes wrong")
+- [ ] Includes a number or threshold
+- [ ] Describes the chain of events, not just the end state
+- [ ] Identifies who or what is affected
+- [ ] Could actually happen (not a fantasy scenario)
+
+### Failure Narrative Template
+
+```markdown
+**Failure: [Title]**
+
+It's [timeframe] from now. [Specific trigger event]. This caused [first-order effect],
+which led to [second-order effect]. The team discovered the problem when [detection point],
+but by then [consequence]. The root cause was [underlying assumption that proved wrong].
+```
+
+### Example
+
+```markdown
+**Failure: Migration Data Loss**
+
+It's 3 months from now. During the database migration from PostgreSQL to the new schema,
+a batch job silently drops records where the `legacy_id` field contains special characters
+(~2% of records). The team discovers the problem 2 weeks post-migration when a customer
+reports missing order history. By then, the legacy database has been decommissioned and
+backups have rotated past the migration date. The root cause was that the migration script
+was tested against a sanitized staging dataset that didn't include special characters.
+```
+
+## Second-Order Consequence Chains
+
+Every failure has consequences beyond the immediate impact. Trace at least two orders deep.
+
+### Chain Template
+
+```
+Trigger: [event]
+  → 1st order: [immediate effect]
+    → 2nd order: [consequence of the 1st order effect]
+      → 3rd order: [consequence of the 2nd order effect]
+```
+
+### Example Chain
+
+```
+Trigger: Key engineer leaves during migration
+  → 1st order: Migration timeline slips 4 weeks
+    → 2nd order: Overlap period with legacy system extends, doubling operational cost
+      → 3rd order: Budget overrun triggers executive review, project gets descoped
+```
+
+### Common Second-Order Patterns
+
+| First Order | Second Order | Third Order |
+|------------|-------------|-------------|
+| Feature ships late | Sales misses quarter target | Engineering loses trust, gets more oversight |
+| Performance degrades | Users adopt workarounds | Workarounds become "requirements" that constrain future design |
+| Team member burns out | Knowledge concentrated in fewer people | Bus factor drops, risk increases |
+| Dependency breaks | Hotfix bypasses testing | New bugs introduced, confidence in releases drops |
+| Data quality issue | Downstream reports are wrong | Business decisions made on bad data |
+| Cost overrun | Budget pulled from other initiatives | Team morale drops, talent leaves |
+
+## Inversion Technique
+
+Ask: **"What would guarantee this fails?"** Then check if any of those conditions exist today.
+
+### Guaranteed Failure Conditions
+
+| Category | What Guarantees Failure |
+|----------|----------------------|
+| **People** | Single point of knowledge, no stakeholder buy-in, team doesn't believe in approach |
+| **Process** | No rollback plan, no incremental validation, all-or-nothing deployment |
+| **Technology** | Untested at target scale, undocumented dependencies, version lock-in |
+| **Timeline** | No buffer for unknowns, dependencies on external teams with no SLA, parallel critical paths |
+| **Data** | Migration without validation, no data quality checks, schema changes without backward compatibility |
+| **Incentives** | Success metrics misaligned with actual goals, team rewarded for speed not quality |
+
+## Domain-Specific Failure Patterns
+
+### Technical Failures
+
+| Pattern | Trigger | Typical Consequence |
+|---------|---------|-------------------|
+| Integration cliff | New service connects to 3+ existing systems | One integration blocks all others |
+| Scale surprise | Load 10x beyond testing | Cascading failures across dependent services |
+| Migration trap | "Just move the data" | Data loss, extended downtime, rollback impossible |
+| Dependency rot | Pinned to abandoned library | Security vulnerability with no upgrade path |
+| Config drift | Manual environment setup | "Works on my machine" becomes "works in no environment" |
+| Halfway house | Partial migration, two systems running | Worst of both worlds — double maintenance, inconsistent state |
+
+### Business Failures
+
+| Pattern | Trigger | Typical Consequence |
+|---------|---------|-------------------|
+| Adoption cliff | Build it and they don't come | Sunk cost with no revenue impact |
+| Competitor preempt | Competitor ships similar feature first | Market positioning lost, differentiation eroded |
+| Timing mismatch | Market shifts during development | Product solves yesterday's problem |
+| Stakeholder reversal | Executive sponsor changes | Project loses priority, resources reallocated |
+| Hidden cost | Operational burden underestimated | Feature costs more to run than it generates |
+
+### Process Failures
+
+| Pattern | Trigger | Typical Consequence |
+|---------|---------|-------------------|
+| Timeline fantasy | Estimates based on best case | Crunch, quality cuts, or scope cuts at the worst time |
+| Dependency chain | Team A waits on Team B waits on Team C | Any slip cascades through all teams |
+| Knowledge silo | Expert leaves or is unavailable | Progress stops; replacement ramps up for weeks |
+| Scope creep | "While we're at it..." | Original goal buried under additions |
+| Feedback void | No user testing until launch | Wrong product built correctly |
+
+## Early Warning Signs
+
+| Warning Sign | What It Indicates | Check Frequency |
+|-------------|-------------------|-----------------|
+| "We'll figure that out later" repeated 3+ times | Critical decisions being deferred, not resolved | Every planning session |
+| No one can explain the rollback plan | Rollback hasn't been designed | Before launch |
+| Estimates keep growing | Hidden complexity being discovered incrementally | Weekly |
+| Key meetings keep getting rescheduled | Stakeholder alignment is weaker than assumed | Weekly |
+| "It works locally" | Environment parity is worse than assumed | Every sprint |
+| Testing phase compressed | Quality will be sacrificed | Mid-project checkpoint |
+| No metrics defined for success | No one will know if this worked | Before kickoff |
+| Team uses hedging language | Confidence is lower than stated | Ongoing |
+
+## Output Template
+
+```markdown
+## Pre-Mortem: [Plan/Decision Name]
+
+**Timeframe:** [When would failure be evident]
+
+### Failure Narratives
+
+#### 1. [Failure Title] — Likelihood: High/Medium/Low | Impact: High/Medium/Low
+
+[Specific failure narrative using the template above]
+
+**Consequence chain:**
+- 1st order: [immediate]
+- 2nd order: [downstream]
+- 3rd order: [systemic]
+
+#### 2. [Failure Title] — Likelihood: High/Medium/Low | Impact: High/Medium/Low
+
+[Narrative]
+
+#### 3. [Failure Title] — Likelihood: High/Medium/Low | Impact: High/Medium/Low
+
+[Narrative]
+
+### Early Warning Signs
+
+| Signal | Failure It Predicts | Check Frequency |
+|--------|-------------------|-----------------|
+| [Observable signal] | Failure #X | Weekly / Sprint / Monthly |
+
+### Mitigations
+
+| Failure | Mitigation | Effort | Reduces Risk By |
+|---------|-----------|--------|-----------------|
+| #1 | [Specific action] | Low/Med/High | [How much] |
+| #2 | [Specific action] | Low/Med/High | [How much] |
+| #3 | [Specific action] | Low/Med/High | [How much] |
+
+### Inversion Check
+
+**What would guarantee failure:**
+1. [Condition]
+2. [Condition]
+3. [Condition]
+
+**Do any exist now?** [Yes/No with specifics for each]
+```

package/skills/massa-ai/references/the-fool/red-team-adversarial.md

@@ -0,0 +1,206 @@
+# Red Team Adversarial
+
+Adversarial thinking and red teaming for finding weaknesses before adversaries do. Incorporates the military RED model (Recognize assumptions, Evaluate arguments, Draw conclusions) and modern red teaming methodologies.
+
+## Core Principle
+
+Red teaming asks: **"If someone wanted to break, exploit, or game this, how would they do it?"** The Fool adopts the mindset of an adversary — not to cause harm, but to find vulnerabilities before real adversaries do. This applies beyond security: competitors, disgruntled users, perverse incentives, and regulatory challenges are all adversarial forces.
+
+## The RED Model
+
+The U.S. Army Applied Critical Thinking Handbook's RED model provides a generalizable three-step checklist applicable to any adversarial analysis:
+
+| Step | Action | Key Questions |
+|------|--------|---------------|
+| **R — Recognize Assumptions** | What are we taking for granted? | What would have to be true for this to be secure? What are we assuming about the adversary? |
+| **E — Evaluate Arguments** | What is the evidence quality? | Are there logical fallacies? What alternative attack paths exist? |
+| **D — Draw Conclusions** | What do the data actually support? | What conclusions are we NOT entitled to draw about our security posture? |
+
+Apply RED before constructing adversary personas to ensure the analysis is grounded.
+
+## Process
+
+1. **Apply RED model** — Recognize assumptions about security/resilience, evaluate existing defenses, draw honest conclusions
+2. **Identify the asset** — What are you protecting? (system, decision, strategy, product)
+3. **Construct adversary personas** — Who would attack this and why?
+4. **Map attack vectors** — How would each persona exploit weaknesses?
+5. **Detect perverse incentives** — How does the system reward wrong behavior?
+6. **Assess impact** — Rank by likelihood x impact
+7. **Design defenses** — Specific countermeasures for the highest-ranked vectors
+
+## Adversary Persona Construction
+
+Generic "attackers" produce generic findings. Specific personas produce actionable insights.
+
+### Persona Template
+
+| Field | Description |
+|-------|-------------|
+| **Role** | Who is this adversary? |
+| **Motivation** | Why would they attack? |
+| **Capability** | What resources and skills do they have? |
+| **Access** | What do they already have access to? |
+| **Constraints** | What limits them? |
+
+### Common Adversary Personas
+
+| Persona | Motivation | Typical Vectors |
+|---------|-----------|----------------|
+| **External Attacker** | Financial gain, data theft | API exploitation, credential stuffing, injection attacks |
+| **Competitor** | Market advantage | Feature copying, talent poaching, FUD campaigns |
+| **Disgruntled Insider** | Revenge, financial gain | Privilege escalation, data exfiltration, sabotage |
+| **Careless User** | None (accidental) | Misconfiguration, weak passwords, sharing credentials |
+| **Regulator** | Compliance enforcement | Audit findings, data handling violations, accessibility gaps |
+| **Opportunistic Gamer** | Personal benefit | Exploiting loopholes in business logic, referral fraud |
+| **Activist** | Ideological goals | Public embarrassment, data leaks, service disruption |
+| **AI Agent** | Automated exploitation | Prompt injection, API abuse at scale, automated vulnerability scanning |
+
+### Domain-Specific Personas
+
+| Domain | Key Adversary | Focus |
+|--------|--------------|-------|
+| E-commerce | Fraudster | Payment bypass, coupon abuse, fake returns |
+| SaaS | Free-tier abuser | Rate limit evasion, multi-accounting, resource hoarding |
+| Marketplace | Bad-faith seller | Fake listings, review manipulation, escrow games |
+| API Platform | Scraper | Rate limit bypass, data harvesting, reverse engineering |
+| Social Platform | Troll/bot farm | Spam, manipulation, fake engagement |
+| AI/ML System | Adversarial attacker | Data poisoning, model extraction, prompt injection |
+
+## Attack Vector Identification
+
+### By Category
+
+| Category | Vectors | Example |
+|----------|---------|---------|
+| **Technical** | Injection, auth bypass, race conditions, SSRF | SQL injection in search parameter |
+| **Business Logic** | Workflow bypass, state manipulation, price tampering | Applying expired coupon via API replay |
+| **Social** | Phishing, pretexting, authority exploitation | "I'm the CEO, I need access now" |
+| **Operational** | Supply chain, dependency poisoning, insider threat | Compromised npm package in build pipeline |
+| **Information** | Data leakage, metadata exposure, timing attacks | User enumeration via login error messages |
+| **Economic** | Resource exhaustion, denial of wallet, asymmetric cost | Lambda invocation flood causing $50K bill |
+| **AI-Specific** | Prompt injection, training data extraction, model manipulation | Injecting instructions via user-controlled content |
+
+### Attack Tree Construction
+
+For complex systems, build attack trees to map paths to a goal.
+
+```
+Goal: Steal user payment data
+├── Path 1: Compromise the database
+│   ├── SQL injection in search endpoint
+│   ├── Credential theft from env variables in logs
+│   └── Exploit unpatched database CVE
+├── Path 2: Intercept in transit
+│   ├── Downgrade TLS via misconfigured CDN
+│   └── Man-in-the-middle on internal service mesh
+└── Path 3: Abuse application logic
+    ├── Export feature with insufficient access control
+    └── Admin panel with default credentials
+```
+
+### The 12 Rules of the Red Team Mindset
+
+Adapted from ITS Tactical for decision analysis:
+
+1. Assume the obvious answer is wrong
+2. Seek disconfirming evidence actively
+3. Never accept the first answer
+4. Treat consensus as a warning sign, not a conclusion
+5. Distinguish between what is known vs. what is assumed
+6. Identify what the defender is NOT protecting
+7. Find the single point of failure
+8. Exploit the gap between policy and practice
+9. Think in time — what's the window of opportunity?
+10. Consider the second and third order effects of your attack
+11. Map the incentives — follow the money, the ego, the convenience
+12. Test the assumption that "no one would ever do that"
+
+## Perverse Incentive Detection
+
+Systems create incentives. Sometimes those incentives reward the wrong behavior.
+
+### Questions to Surface Perverse Incentives
+
+| Question | What It Reveals |
+|----------|----------------|
+| "How will people game this?" | Loopholes in business logic |
+| "What behavior does this reward that we don't want?" | Misaligned incentives |
+| "What's the cheapest way to get the reward without the effort?" | Shortcut exploitation |
+| "If we measure X, what Y gets sacrificed?" | Goodhart's Law in action |
+| "Who benefits from this failing?" | Adversaries with motive |
+| "What would a lazy but clever person do?" | Path of least resistance exploits |
+
+### Common Perverse Incentive Patterns
+
+| Pattern | Example | Consequence |
+|---------|---------|-------------|
+| Metric gaming | "Lines of code" as productivity metric | Verbose, unmaintainable code |
+| Reward hacking | Referral bonus with no verification | Fake accounts for self-referral |
+| Race to the bottom | "Fastest response time" as SLA | Teams avoid taking complex tickets |
+| Cobra effect | Bounty for reporting bugs | Team introduces bugs to claim bounties |
+| Information asymmetry | Users know more than the system | Adverse selection in marketplace pricing |
+| Goodhart's Law | Any target metric becomes the optimization goal | Metric improves, actual outcome deteriorates |
+
+## Competitive Response Analysis
+
+When the "adversary" is a competitor.
+
+| Scenario | Analysis Framework |
+|----------|-------------------|
+| Feature parity | What can they copy? How fast? What's our defensible moat? |
+| Price war | Can they sustain lower prices? What's their cost structure? |
+| Talent poaching | Which roles are critical? How replaceable? What's our retention advantage? |
+| Platform risk | Are we dependent on their platform? What's the switch cost? |
+| FUD campaign | What claims could they make? Which are hardest to refute? |
+
+## Output Template
+
+```markdown
+## Red Team Analysis: [Target]
+
+### RED Model Assessment
+
+| Step | Finding |
+|------|---------|
+| **Recognize Assumptions** | [Key assumptions about security/resilience] |
+| **Evaluate Arguments** | [Quality of evidence for current defenses] |
+| **Draw Conclusions** | [Honest assessment of actual posture] |
+
+### Asset Under Assessment
+
+[What we're protecting and why it matters]
+
+### Adversary Profiles
+
+#### Adversary 1: [Name/Role]
+- **Motivation:** [Why they attack]
+- **Capability:** [What they can do]
+- **Access:** [What they start with]
+
+#### Adversary 2: [Name/Role]
+- **Motivation:** [Why they attack]
+- **Capability:** [What they can do]
+- **Access:** [What they start with]
+
+### Attack Vectors (Ranked)
+
+| # | Vector | Adversary | Likelihood | Impact | Risk Score |
+|---|--------|-----------|-----------|--------|------------|
+| 1 | [Specific attack] | [Who] | High/Med/Low | High/Med/Low | [L x I] |
+| 2 | [Specific attack] | [Who] | High/Med/Low | High/Med/Low | [L x I] |
+| 3 | [Specific attack] | [Who] | High/Med/Low | High/Med/Low | [L x I] |
+
+### Perverse Incentives
+
+| Incentive Created | Unintended Behavior | Severity |
+|-------------------|-------------------|----------|
+| [What the system rewards] | [How it gets gamed] | High/Med/Low |
+
+### Recommended Defenses
+
+| Attack Vector | Defense | Effort | Priority |
+|--------------|---------|--------|----------|
+| #1 | [Specific countermeasure] | Low/Med/High | Immediate/Next sprint/Backlog |
+| #2 | [Specific countermeasure] | Low/Med/High | Immediate/Next sprint/Backlog |
+| #3 | [Specific countermeasure] | Low/Med/High | Immediate/Next sprint/Backlog |
+```

package/skills/massa-ai/references/the-fool/socratic-questioning.md

@@ -0,0 +1,153 @@
+# Socratic Questioning
+
+Structured question frameworks for exposing assumptions and deepening understanding.
+
+## Core Principle
+
+Socratic questioning does not argue. It asks. The goal is to help the user discover gaps in their own reasoning by surfacing what they have not examined. Every question should create a moment of "I hadn't thought about that."
+
+The agent must never answer the questions itself. Present them, let the user sit with them.
+
+## The 6 Question Types
+
+Research (NAACL 2024, ChemRxiv 2025) confirms these 6 types as the most effective for critical analysis in AI-assisted workflows.
+
+### 1. Clarifying Questions
+
+Force precision on vague or overloaded terms.
+
+| Pattern | Example |
+|---------|---------|
+| "When you say X, what specifically do you mean?" | "When you say 'scalable,' do you mean 10x users or 1000x?" |
+| "How would you define X to someone unfamiliar?" | "How would you explain 'real-time' to a non-engineer?" |
+| "Are there cases where X means something different?" | "Does 'fast' mean the same thing for API response and batch job?" |
+
+### 2. Assumption-Probing Questions
+
+Surface hidden premises that the reasoning depends on.
+
+| Pattern | Example |
+|---------|---------|
+| "What are you assuming here?" | "What has to be true for microservices to improve velocity?" |
+| "Is this based on data or intuition?" | "Is the 'users hate the current flow' claim from research or assumption?" |
+| "What would change your mind?" | "What metric would convince you this approach is wrong?" |
+| "What are you treating as fixed that might be flexible?" | "Does the deadline have to be Q2, or is that an assumption?" |
+
+### 3. Evidence-Probing Questions
+
+Test the evidential basis for beliefs.
+
+| Pattern | Example |
+|---------|---------|
+| "What evidence supports this?" | "What data shows users actually want this feature?" |
+| "How do you know X is true?" | "How do you know the current system can't handle the load?" |
+| "How large and representative is the sample?" | "Was the pilot tested on production-like data or sanitized staging data?" |
+| "Is the source independent or interested?" | "Is that benchmark from a vendor or an independent test?" |
+
+### 4. Implication Questions
+
+Follow the logical consequences of the position.
+
+| Pattern | Example |
+|---------|---------|
+| "If that's true, what follows?" | "If we accept this latency budget, what does that force on the database layer?" |
+| "Does X necessarily lead to Y?" | "Does adding caching necessarily improve user experience?" |
+| "What's the second-order effect?" | "If we hire contractors to speed up, what happens to team knowledge?" |
+| "What becomes harder later?" | "What future feature becomes harder if we choose this schema?" |
+
+### 5. Perspective-Shifting Questions
+
+Force consideration of other viewpoints.
+
+| Pattern | Example |
+|---------|---------|
+| "How would [stakeholder] see this?" | "How would the on-call engineer feel about this architecture?" |
+| "What would a skeptic say?" | "What would a senior engineer who prefers simplicity say?" |
+| "What does this look like in 2 years?" | "Will this abstraction still make sense when the team doubles?" |
+| "Who loses if this succeeds?" | "If we adopt this vendor, what capability do we give up?" |
+
+### 6. Meta-Questions
+
+Examine the reasoning process itself.
+
+| Pattern | Example |
+|---------|---------|
+| "Why are we framing it this way?" | "Why are we treating this as a technology decision instead of an organizational one?" |
+| "What question are we NOT asking?" | "We've discussed performance — what about operability?" |
+| "Are we solving the right problem?" | "Is the real problem the deploy pipeline or the coupling?" |
+| "What would it take to change your mind?" (Kozyrkov's Magic Question) | "If I could prove X, would you reconsider?" |
+
+## Assumption Detection Signals
+
+Watch for language that hides assumptions. When you hear these, probe immediately.
+
+| Signal Phrase | Hidden Assumption | Probe With |
+|---------------|-------------------|------------|
+| "Obviously..." | The speaker hasn't questioned this | "What makes this obvious? Has it been tested?" |
+| "Everyone knows..." | Consensus hasn't been verified | "Who specifically? Has anyone disagreed?" |
+| "It just makes sense..." | The reasoning chain hasn't been articulated | "Walk me through the logic step by step." |
+| "We always..." | Historical pattern assumed to be optimal | "Why? What would happen if you didn't?" |
+| "There's no other way..." | Alternatives haven't been explored | "What if there were? What would it look like?" |
+| "It's simple..." | Complexity has been underestimated | "What's the simplest thing that could go wrong?" |
+| "Users want..." | User research may be absent or stale | "How do you know? When was this last validated?" |
+| "The standard approach is..." | Convention hasn't been validated for context | "Standard for whom? Does their context match yours?" |
+| "We need to be careful..." | Risk aversion without quantified risk | "What specifically is the risk? How likely?" |
+
+## Domain-Adapted Question Banks
+
+### Technical Decisions
+
+- What are you optimizing for? Are you sure that's the right dimension?
+- What's the simplest version that tests the core assumption?
+- What constraint are you treating as fixed that might actually be flexible?
+- How would you build this if you had to ship in one week?
+- What's the most expensive thing to change later?
+- If you had to explain the failure mode to a non-technical executive, what would you say?
+
+### Business Decisions
+
+- Who is the customer for this decision? Are you sure?
+- What would make this a bad investment in hindsight?
+- How does this compare to doing nothing?
+- What's the opportunity cost of this choice?
+- If a competitor made the opposite choice, would you be worried?
+- What's the maximum you'd pay a clairvoyant for perfect information on this? (Kozyrkov's Value of Clairvoyance test — if low, the decision doesn't need more analysis)
+
+### Strategic Decisions
+
+- What has to be true for this strategy to work?
+- Which of those assumptions are you least confident about?
+- What's the fastest way to test the riskiest assumption?
+- How will you know if this is failing before it's too late?
+- What's the exit strategy if this doesn't work?
+- Frame this as a bet: what are you staking, at what odds, for what payoff?
+
+## Output Template
+
+```markdown
+## Assumption Inventory
+
+| # | Assumption | Type | Confidence | Source |
+|---|-----------|------|------------|--------|
+| 1 | [Stated or hidden assumption] | Stated / Unstated | High / Medium / Low | [Where it appears in the reasoning] |
+
+## Probing Questions
+
+### [Theme 1: e.g., "User Behavior"]
+1. [Question targeting assumption #X] _(Type: Assumption-probing)_
+2. [Follow-up question deepening the probe] _(Type: Implication)_
+
+### [Theme 2: e.g., "Technical Feasibility"]
+1. [Question targeting assumption #Y] _(Type: Evidence-probing)_
+2. [Follow-up question] _(Type: Perspective-shifting)_
+
+### [Theme 3: e.g., "Business Viability"]
+1. [Question targeting assumption #Z] _(Type: Meta-question)_
+2. [Follow-up question] _(Type: Clarifying)_
+
+## Suggested Experiments
+
+| Assumption | Experiment | Effort | Signal |
+|-----------|-----------|--------|--------|
+| [Riskiest assumption] | [How to test it] | Low/Med/High | [What result means] |
+```