@massa-ai/cursor-plugin 1.6.0

package/skills/massa-ai/references/the-fool/dialectic-synthesis.md

@@ -0,0 +1,170 @@
+# Dialectic Synthesis
+
+Hegelian dialectic with steel manning for constructing the strongest possible counter-argument and driving toward synthesis.
+
+## Core Principle
+
+The dialectic is not about winning. It is about producing a stronger position than either thesis or antithesis alone. The Fool's job is to argue the other side so well that the user is forced to either refine their position or acknowledge a genuine trade-off.
+
+Key distinction: steel manning is epistemic (genuinely trying to find out if you're wrong), devil's advocacy is role-based (assigned to argue against). Apply both: steel man first, then construct the antithesis.
+
+## Process
+
+1. **Restate the thesis** — Steelman the user's position first
+2. **Construct the antithesis** — Build the strongest opposing argument
+3. **Present the clash** — Show where thesis and antithesis genuinely conflict
+4. **Drive toward synthesis** — Propose a position that incorporates the best of both
+5. **Assess confidence** — Rate the synthesis and identify remaining risks
+
+## Steel Manning Technique
+
+Steel manning is the opposite of straw manning. Restate the user's position in its strongest possible form before arguing against it.
+
+### How to Steelman
+
+| Step | Action | Example |
+|------|--------|---------|
+| 1. Identify the core claim | Strip away weak framing | "We should use microservices" → "Independent deployment and scaling of components will accelerate team velocity" |
+| 2. Add the strongest evidence | Supply what the user implied | "...especially given 4 teams working on different release cycles" |
+| 3. Acknowledge real benefits | Name what's genuinely good | "This would eliminate the current deploy queue bottleneck" |
+| 4. Confirm with user | "Is this a fair restatement?" | Ensures you're attacking the real position, not a fabrication |
+
+### Steelman Checklist
+
+Before proceeding to the antithesis, verify:
+
+- Have I made the position stronger, not weaker?
+- Would the user recognize this as their view (or better)?
+- Have I included the strongest evidence for their side?
+- Am I about to attack this version, not an easier one?
+
+## Antithesis Construction
+
+### Technique: Strongest Counter-Argument
+
+Build the antithesis by asking: "If a smart, informed person disagreed, what would their best argument be?"
+
+| Source of Counter-Arguments | Example |
+|----------------------------|---------|
+| Opposing trade-off | "Speed now vs. maintainability later" |
+| Hidden cost | "The migration cost exceeds the projected savings for 18 months" |
+| Alternative that solves the same problem | "A modular monolith gets 80% of the benefit at 20% of the cost" |
+| Precedent from similar situations | "Company X tried this and reverted after 2 years" |
+| Stakeholder the thesis doesn't serve | "The junior developers will struggle with the added complexity" |
+| The null hypothesis | "Doing nothing and investing the effort elsewhere yields higher ROI" |
+
+### Reductio ad Absurdum (Supporting Technique)
+
+Take the thesis to its logical extreme to reveal hidden limits.
+
+| Thesis | Reductio | Reveals |
+|--------|----------|---------|
+| "We should optimize for developer experience" | "Then we should never ship to production, since bugs hurt DX" | DX must be balanced against delivery |
+| "More tests are always better" | "Then we should have 100% coverage including getters/setters" | Test value has diminishing returns |
+| "We should move fast" | "Then skip code review and testing" | Speed has a quality floor |
+
+Use sparingly. Reductio highlights the boundary of a principle, not its invalidity.
+
+### Probabilistic Framing (Annie Duke)
+
+Force probability estimates to make uncertainty explicit:
+
+- "How confident are you in this? 60%? 90%?"
+- "What would move your confidence from 70% to 90%?"
+- "What's the probability the antithesis is right?"
+
+This prevents binary thinking and enables calibration.
+
+## Synthesis Patterns
+
+After presenting thesis and antithesis, propose a synthesis using one of these patterns.
+
+### 1. Conditional Synthesis
+
+"X is true **when** condition A holds; Y is true **when** condition B holds."
+
+Example: "Microservices are right for the payment service (independent scaling, compliance boundary) but the admin dashboard should stay in the monolith (low traffic, fast iteration)."
+
+### 2. Scope Partitioning
+
+"Apply X to domain A and Y to domain B."
+
+Example: "Use event sourcing for the audit trail (append-only, queryable history) but standard CRUD for user profiles (simple reads/writes)."
+
+### 3. Temporal Synthesis
+
+"Start with X, migrate to Y when trigger Z occurs."
+
+Example: "Start with a monolith, extract services when team size exceeds 3 squads or deploy frequency hits weekly conflicts."
+
+### 4. Risk Mitigation Synthesis
+
+"Proceed with X but add safeguards from Y."
+
+Example: "Adopt the new framework but keep the abstraction layer so we can swap back within 2 sprints."
+
+### 5. Hybrid Extraction
+
+"Take the strongest element from each side."
+
+Example: "Use the microservices deployment model (independent containers) but keep a shared database with schema ownership (avoiding distributed data complexity)."
+
+## Confidence Assessment
+
+Rate the synthesis outcome honestly.
+
+| Level | Meaning | Action |
+|-------|---------|--------|
+| **HIGH** | Synthesis clearly stronger than either side alone | Proceed with synthesis |
+| **MEDIUM** | Synthesis is plausible but untested | Identify the riskiest assumption and suggest an experiment |
+| **LOW** | Both sides have strong, irreconcilable claims | Name the genuine trade-off; let the user decide based on priorities |
+| **PIVOT** | The antithesis is stronger than the thesis | Recommend the user reconsider their original position |
+
+## Anti-Patterns
+
+| Anti-Pattern | Problem | Fix |
+|-------------|---------|-----|
+| False synthesis | "Just do both!" without resolving the tension | Name the specific trade-off being resolved |
+| Weak antithesis | Counter-argument is a strawman | Apply steel manning to the counter too |
+| Thesis bias | Synthesis suspiciously close to original position | Check if antithesis was genuinely engaged |
+| Complexity creep | Synthesis is more complex than either original | Simpler synthesis is usually better |
+| Fence-sitting | "It depends" without specifying on what | Name the exact conditions for each path |
+| Resulting bias | Judging decision quality by outcome | Evaluate the process, not the result (Duke) |
+
+## Output Template
+
+```markdown
+## Thesis (Steelmanned)
+
+[User's position restated in strongest form]
+
+**Strongest evidence for:** [1-2 supporting points]
+**User's confidence:** [X%]
+
+## Antithesis
+
+[Strongest counter-argument]
+
+**Strongest evidence for:** [1-2 supporting points]
+
+## Points of Genuine Conflict
+
+| Dimension | Thesis Says | Antithesis Says |
+|-----------|------------|-----------------|
+| [e.g., Speed] | [Position] | [Counter-position] |
+| [e.g., Cost] | [Position] | [Counter-position] |
+
+## Proposed Synthesis
+
+**Pattern:** [Conditional / Scope / Temporal / Risk Mitigation / Hybrid]
+
+[Concrete synthesis proposal]
+
+**What this preserves from the thesis:** [specific elements]
+**What this incorporates from the antithesis:** [specific elements]
+**What this gives up:** [explicit trade-offs]
+
+**Confidence:** HIGH / MEDIUM / LOW / PIVOT
+**If MEDIUM:** Test [riskiest assumption] by [experiment]
+**If PIVOT:** [Concrete recommendation to reconsider]
+```

package/skills/massa-ai/references/the-fool/evidence-audit.md

@@ -0,0 +1,202 @@
+# Evidence Audit
+
+Falsificationism and evidence quality assessment for auditing whether claims are actually supported by evidence. Adapted from Karl Popper's falsificationism, the GRADE Evidence-to-Decision framework, and Annie Duke's probabilistic reasoning.
+
+## Core Principle
+
+Karl Popper's key insight: a claim is only meaningful if you can specify what would disprove it. The Evidence Audit mode extracts claims from proposals, designs falsification criteria, assesses evidence quality, identifies cognitive biases, and surfaces competing explanations. The goal is not to disprove — it is to determine whether the evidence actually supports the conclusion.
+
+## Process
+
+1. **Extract claims** — Identify the specific claims being made (explicit and implicit)
+2. **Design falsification criteria** — For each claim, specify what would disprove it
+3. **Assess evidence quality** — Evaluate the evidence using the GRADE-adapted framework
+4. **Identify cognitive biases** — Check for systematic errors in reasoning (defer to `cognitive-bias-inventory.md` for the full inventory)
+5. **Surface competing explanations** — Find alternative explanations for the same evidence
+6. **Render verdict** — Overall evidence strength with specific recommendations
+
+## Claim Extraction
+
+Proposals contain claims — often implicit. Extract them before evaluating.
+
+### Types of Claims
+
+| Type | Example | Hidden In |
+|------|---------|-----------|
+| **Causal** | "X causes Y" | "Our refactor improved performance" |
+| **Predictive** | "X will happen" | "Users will adopt this feature" |
+| **Comparative** | "X is better than Y" | "React is the better choice for us" |
+| **Existential** | "X exists/doesn't exist" | "There's no alternative that meets our needs" |
+| **Universal** | "X is always true" | "Microservices always improve team velocity" |
+| **Quantitative** | "X is N" | "This will save 200 hours per quarter" |
+
+### Extraction Method
+
+For each statement in the proposal:
+
+1. Is this a claim or a definition?
+2. If a claim, what type?
+3. What evidence is cited (or implied)?
+4. What would make this claim false?
+
+### Example Extraction
+
+```
+Statement: "Based on our pilot, migrating to Kubernetes will reduce deployment time by 60%."
+
+Claims extracted:
+1. The pilot results are representative of production (Predictive)
+2. Kubernetes is the cause of the deployment time reduction (Causal)
+3. The 60% reduction will persist at scale (Quantitative)
+4. Deployment time is the right metric to optimize (Implicit — Comparative)
+```
+
+## Falsification Criteria
+
+For each claim, design a test that would disprove it.
+
+| Claim | Falsification Criterion | Test |
+|-------|------------------------|------|
+| "Users want feature X" | Fewer than 10% of users engage with X within 30 days | Feature flag, measure adoption |
+| "This will scale to 100K users" | Response time exceeds 500ms at 50K users | Load test at target scale |
+| "Migration will take 3 months" | More than 2 unknown-unknowns discovered in month 1 | Track surprise count during initial phase |
+| "Framework X is faster" | Benchmark shows less than 5% difference | Controlled benchmark on representative workload |
+| "This will reduce costs" | Total cost of ownership exceeds current cost within 12 months | TCO analysis including migration, training, operations |
+
+### Unfalsifiable Claims (Red Flag)
+
+Some claims cannot be falsified. These are red flags that require immediate attention.
+
+| Pattern | Example | Problem |
+|---------|---------|---------|
+| Vague outcome | "This will improve things" | No measurable criterion |
+| Moving goalposts | "It'll work eventually" | No time boundary |
+| Circular reasoning | "This is the best because it's what experts recommend" | Evidence is the claim restated |
+| Unfalsifiable hedge | "This might help in some cases" | True by definition |
+
+When you encounter unfalsifiable claims, ask: "What specific, measurable outcome would tell us this worked or didn't work, and by when?"
+
+## Evidence Quality Assessment (GRADE-Adapted)
+
+The GRADE Evidence-to-Decision framework, adapted from medical research to tech/business decisions, provides structured evidence evaluation.
+
+### GRADE Decision Questions
+
+Apply these 9 questions to any proposal:
+
+1. **Is the problem a priority?** Is it worth solving at all?
+2. **How substantial are the desirable anticipated effects?** What's the upside?
+3. **How substantial are the undesirable anticipated effects?** What's the downside?
+4. **What is the certainty of the evidence?** How strong is our basis for believing this?
+5. **Is there important uncertainty about how stakeholders value outcomes?** Do different people want different things?
+6. **Does the balance of effects favor this option or the alternative?** Net positive or net negative?
+7. **How large are the resource requirements?** Total cost of ownership?
+8. **Is the option acceptable to key stakeholders?** Will people actually support this?
+9. **Is the option feasible to implement?** Can we actually do this?
+
+### Evidence Quality Matrix
+
+| Dimension | Strong | Weak |
+|-----------|--------|------|
+| **Sample size** | Large, representative sample | Single case, anecdote |
+| **Recency** | Current data (within 12 months) | Outdated (2+ years) |
+| **Relevance** | Same domain, same scale | Different domain or scale |
+| **Independence** | Multiple independent sources | Single source or vendor-provided |
+| **Methodology** | Controlled, reproducible | Ad hoc, unreproducible |
+| **Specificity** | Precise metrics and conditions | Vague or qualitative |
+
+### Evidence Grading Scale
+
+| Grade | Description | Reliability |
+|-------|-------------|------------|
+| **A** | Controlled experiment, large sample, reproducible | High confidence — proceed |
+| **B** | Observational data, reasonable sample, consistent with other evidence | Moderate confidence — proceed with monitoring |
+| **C** | Case study, small sample, or single source | Low confidence — needs corroboration before deciding |
+| **D** | Anecdote, opinion, or vendor marketing material | Insufficient — do not base decisions on this alone |
+| **F** | No evidence cited | Claim is unsupported — flag immediately |
+
+### Common Weak Evidence Patterns
+
+| Pattern | Example | Why It's Weak |
+|---------|---------|---------------|
+| Survivorship bias | "Companies using X are successful" | Ignores companies using X that failed |
+| Cherry-picked metrics | "Response time improved 40%" | Other metrics (error rate, throughput) may have worsened |
+| Vendor benchmarks | "Our tool is 3x faster" | Benchmarks optimized for vendor's strengths |
+| Appeal to authority | "Google does it this way" | Google's constraints are not your constraints |
+| Anchoring | "Industry average is X, we're at Y" | The average may not be the right benchmark |
+| N=1 generalization | "It worked at my last company" | Different context, team, scale, constraints |
+
+## Competing Explanations (Abductive Reasoning)
+
+For every conclusion, ask: "What else could explain this evidence?"
+
+### Method
+
+1. State the evidence
+2. State the proposed explanation
+3. Generate 2-3 alternative explanations
+4. Compare explanatory power — which explanation accounts for the most evidence with the fewest assumptions?
+
+### Example
+
+```
+Evidence: "Deployment failures dropped 50% after adopting tool X."
+
+Proposed explanation: Tool X is better than the old tool.
+
+Alternative explanations:
+1. The team also started doing more code review in the same period
+2. A particularly error-prone service was retired last month
+3. The team gained experience that would have improved results with any tool
+4. Deployment frequency dropped (fewer deploys = fewer failures, not better deploys)
+```
+
+## Output Template
+
+```markdown
+## Evidence Audit: [Proposal/Decision]
+
+### Claims Extracted
+
+| # | Claim | Type | Evidence Cited | Falsifiable? |
+|---|-------|------|---------------|-------------|
+| 1 | [Specific claim] | Causal/Predictive/etc. | [What evidence supports it] | Yes/No |
+| 2 | [Specific claim] | Causal/Predictive/etc. | [What evidence supports it] | Yes/No |
+
+### Falsification Criteria
+
+| Claim | What Would Disprove It | How to Test | Effort |
+|-------|----------------------|-------------|--------|
+| #1 | [Specific criterion] | [Concrete test] | Low/Med/High |
+| #2 | [Specific criterion] | [Concrete test] | Low/Med/High |
+
+### Evidence Quality
+
+| Claim | Evidence Grade | Key Weakness | GRADE Assessment |
+|-------|--------------|--------------|-----------------|
+| #1 | A/B/C/D/F | [Primary concern] | [Which of the 9 questions is most concerning] |
+| #2 | A/B/C/D/F | [Primary concern] | [Which of the 9 questions is most concerning] |
+
+### Bias Check
+
+| Bias Detected | Where | Impact |
+|--------------|-------|--------|
+| [Bias name] | Claim #X | [How it affects the conclusion] |
+
+### Competing Explanations
+
+| Evidence | Proposed Explanation | Alternative Explanations |
+|----------|---------------------|------------------------|
+| [Data point] | [Original claim] | 1. [Alternative] 2. [Alternative] |
+
+### Verdict
+
+**Overall evidence strength:** Strong / Moderate / Weak / Insufficient
+
+**Confidence level:** [X%] — this forces probabilistic rather than binary thinking
+
+**Recommendations:**
+1. [Specific action to strengthen the weakest claim]
+2. [Specific action to test the riskiest assumption]
+3. [What would change this verdict — the Magic Question]
+```

package/skills/massa-ai/references/the-fool/mode-selection-guide.md

@@ -0,0 +1,113 @@
+# Mode Selection Guide
+
+How to recommend the right reasoning mode when the user selects "You choose" or when auto-recommending.
+
+## Signal-to-Mode Mapping
+
+Analyze the user's language and context to identify which mode fits best.
+
+| User Signal | Recommended Mode | Rationale |
+|-------------|-----------------|-----------|
+| "Is this the right approach?" | Socratic Questioning | Exploring assumptions, not yet committed |
+| "I'm about to commit to X" | Dialectic Synthesis | Needs strongest counter-argument before committing |
+| "What could go wrong?" | Pre-mortem Analysis | Explicitly asking about failure modes |
+| "Is this secure/safe?" | Red Team | Security and adversarial framing |
+| "The data shows that..." | Evidence Audit | Claims based on evidence need falsification |
+| "Everyone agrees that..." | Socratic Questioning | Consensus signals unexamined assumptions |
+| "We chose X over Y" | Dialectic Synthesis | Trade-off decision benefits from strongest counter |
+| "This will definitely work" | Pre-mortem Analysis | Overconfidence signals need for failure imagination |
+| "No one would ever..." | Red Team | Assumptions about adversary behavior |
+| "Studies show..." | Evidence Audit | Cited evidence needs quality assessment |
+| "I have a gut feeling..." | Evidence Audit | Intuition needs evidence grounding |
+| "We've always done it this way" | Socratic Questioning | Historical pattern assumed optimal |
+| "The vendor says..." | Evidence Audit | Interested party evidence needs scrutiny |
+
+## Decision Type Mapping
+
+| Decision Type | Primary Mode | Secondary Mode |
+|---------------|-------------|----------------|
+| Technology choice | Dialectic Synthesis | Pre-mortem Analysis |
+| Architecture decision | Pre-mortem Analysis | Red Team |
+| Business strategy | Dialectic Synthesis | Evidence Audit |
+| Security design | Red Team | Pre-mortem Analysis |
+| Data-driven conclusion | Evidence Audit | Socratic Questioning |
+| Process/workflow design | Pre-mortem Analysis | Socratic Questioning |
+| Hiring/team decision | Socratic Questioning | Dialectic Synthesis |
+| Vendor selection | Evidence Audit | Pre-mortem Analysis |
+| Trade-off resolution | Dialectic Synthesis | Socratic Questioning |
+| Risk assessment | Red Team | Pre-mortem Analysis |
+| Investment/budget decision | Evidence Audit | Dialectic Synthesis |
+| Product direction | Socratic Questioning | Dialectic Synthesis |
+
+## Domain Mapping
+
+| Domain | Default Mode | Why |
+|--------|-------------|-----|
+| Security | Red Team | Adversarial thinking is native to the domain |
+| Infrastructure | Pre-mortem Analysis | Failure modes are the primary concern |
+| Data/Analytics | Evidence Audit | Claims require evidence scrutiny |
+| Product/UX | Socratic Questioning | Assumptions about users need surfacing |
+| Business | Dialectic Synthesis | Strategy benefits from strongest counter |
+| Architecture | Pre-mortem Analysis | Systems fail at integration points |
+| Legal/Compliance | Evidence Audit | Claims must withstand scrutiny |
+| AI/ML | Red Team | Adversarial robustness is critical |
+| People/Org | Socratic Questioning | Hidden assumptions about behavior |
+
+## Multi-Mode Sequencing
+
+Some situations benefit from running 2 modes in sequence.
+
+### Recommended Sequences
+
+| Sequence | When to Use |
+|----------|-------------|
+| Socratic → Dialectic | User has an untested idea. Surface assumptions first, then argue the counter. |
+| Pre-mortem → Red Team | High-stakes system launch. Find internal failures, then external attacks. |
+| Evidence Audit → Socratic | Data-driven proposal. Audit the evidence, then question the interpretation. |
+| Dialectic → Pre-mortem | Strategic decision. Argue the counter, then stress-test the surviving position. |
+| Socratic → Evidence Audit | Proposal with many "obvious" claims. Surface assumptions, then grade the evidence. |
+
+### When to Suggest Multi-Mode
+
+Recommend a second pass when:
+
+- The first mode reveals a category of risk the user hadn't considered
+- The thesis survives the first challenge largely intact (it may need harder testing)
+- The domain spans two mapping categories (e.g., a security architecture decision)
+- The user's confidence increased after the first pass — a different mode may reveal new angles
+
+### When NOT to Suggest Multi-Mode
+
+- The user's question is narrow and specific
+- The first mode already surfaced actionable changes
+- The user signals they want to move on
+- The synthesis already reached HIGH confidence with clear next steps
+
+## Auto-Recommendation Format
+
+When presenting the recommendation, use this structure:
+
+```
+Based on [specific context signal], I recommend **[Mode Name]** because [1-sentence rationale].
+
+[If a secondary mode is relevant:]
+After that, a follow-up with **[Secondary Mode]** would [1-sentence benefit].
+```
+
+Then confirm with `AskUserQuestion`:
+
+- Option 1: Recommended mode (with "(Recommended)" label)
+- Option 2: Secondary mode if applicable
+- Option 3: "Let me pick" — return to the full mode selection
+
+## Edge Cases
+
+| Situation | Default Mode | Rationale |
+|-----------|-------------|-----------|
+| Vague context | Socratic Questioning | It surfaces what matters through questions |
+| Multiple concerns | Pre-mortem Analysis | It covers breadth naturally through failure narratives |
+| User is emotional/frustrated | Dialectic Synthesis | Steel manning validates their position before challenging |
+| Technical vs business split | Match the mode to which side the user emphasizes | Follow the energy, address the unspoken second |
+| User wants to challenge code/PR | Socratic Questioning | Read the code first, then probe assumptions behind design choices |
+| User presents a completed decision | Evidence Audit | Auditing evidence is less confrontational for past decisions |
+| Multi-stakeholder decision | Dialectic Synthesis | Different stakeholders embody the thesis and antithesis naturally |