@human-avatar/skills-for-humanity 1.0.0

package/skills/logic-argument-validation/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: logic-argument-validation
+description: "Check whether an argument's premises actually support its conclusion, and identify logical fallacies. Use when reviewing a design decision, technical proposal, product argument, or any reasoning where the conclusion needs to hold up under scrutiny. TRIGGERS: 'validate this argument', 'does this logic hold', 'check my reasoning', 'is this a fallacy', 'find the flaw in this', any proposal or decision where the reasoning chain matters. Pairs well with logic-consistency-check when a full document needs scrutiny."
+---
+
+# Logic Argument Validation
+
+An argument can *sound* compelling while the reasoning is broken. Confident language, plausible premises, a conclusion that feels right — none of these guarantee the argument actually holds. This skill validates the structure: do the premises support the conclusion, and is the reasoning free of fallacies?
+
+---
+
+## Your Process
+
+**Step 1: Extract the argument structure**
+Before evaluating, make the argument explicit:
+- **Premises**: what claims is the argument built on?
+- **Conclusion**: what is it trying to prove?
+- **Reasoning**: what's the logical path from premises to conclusion?
+
+Restate this clearly before proceeding. Often the weakest point becomes obvious once the structure is explicit.
+
+**Step 2: Test premise soundness**
+For each premise:
+- Is it stated as fact? Is it actually established, assumed, or contested?
+- Is it relevant to the conclusion, or is it doing rhetorical work without logical work?
+- Are there hidden premises — unstated assumptions the argument silently depends on?
+
+**Step 3: Test the inference**
+Does the conclusion actually follow from the premises, *even if* the premises are true? Common inference failures:
+- The premises support a weaker version of the conclusion than the one being claimed
+- The reasoning jumps over a step that would need its own justification
+- The conclusion is true but for reasons the premises don't establish
+
+**Step 4: Check for fallacies**
+Scan for common fallacies. Name them specifically if found:
+
+| Fallacy | What it looks like |
+|---|---|
+| **Ad hominem** | Attacking the source rather than the argument |
+| **Straw man** | Misrepresenting a position to make it easier to refute |
+| **False dichotomy** | Presenting two options when more exist |
+| **Circular reasoning** | The conclusion is smuggled into the premises |
+| **Slippery slope** | Assuming a chain of consequences without justifying each step |
+| **Appeal to authority** | Citing authority as a substitute for evidence |
+| **Hasty generalisation** | Drawing broad conclusions from insufficient cases |
+| **Post hoc** | Assuming causation from correlation or sequence |
+| **Equivocation** | Using the same word in two different senses |
+
+**Step 5: Verdict**
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Validity test only** — skip premise truth assessment, test whether the conclusion follows from what's given
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Argument:**
+[Premises / Conclusion restated explicitly]
+
+**Premise Assessment**
+| Premise | Status | Issue |
+|---|---|---|
+| [premise] | ✅ Established / ⚠️ Assumed / ❌ Contested | [note] |
+
+**Inference Assessment**
+[Does the conclusion follow? Where does the chain hold or break?]
+
+**Fallacies Detected**
+- [Fallacy name]: [specific example from the argument] — or "None detected"
+
+**Verdict**
+[Does the argument hold? What is the specific weakest point?]
+
+**What would strengthen it**
+- [Specific fix — evidence needed, premise to qualify, step to make explicit]
+
+---
+
+## Notes
+
+A broken argument isn't necessarily a wrong conclusion. The conclusion might be correct while the reasoning that supports it is flawed. Flag both: the structural problem *and* whether the conclusion still seems defensible by other means.

package/skills/logic-causality-mapping/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: logic-causality-mapping
+description: "Map causal relationships, trace dependencies, and reason about consequences before acting. Use when you need to understand what causes what, what breaks if something changes, or what must be true for a plan to work. TRIGGERS: 'map the dependencies', 'what causes this', 'what breaks if I change X', 'trace the root cause', 'if X then what', 'what has to be true for this to work', any situation involving root cause analysis, impact assessment, dependency tracing, or reasoning about chains of effect."
+---
+
+# Logic Causal Reasoning
+
+Correlation isn't causation. Neither is sequence. "This happened, then that happened" is not the same as "this caused that" — but it's treated as equivalent constantly, and it produces wrong diagnoses, failed fixes, and surprised engineers.
+
+This skill makes causal structure explicit: what actually depends on what, what change produces what effect, and what must be true for a plan to hold.
+
+---
+
+## Four Modes
+
+Use the mode that matches the question.
+
+### Mode 1: Root Cause Tracing
+*"Why did this happen?"*
+
+Work backwards from an observed effect to its cause — and to the cause of that cause.
+
+**Process:**
+1. State the observed effect precisely. Not "the system is slow" — "p95 latency increased from 120ms to 840ms after the Tuesday deploy."
+2. Ask: what are the immediate causes that could produce this effect? List all plausible candidates.
+3. For each candidate: what evidence would confirm or rule it out?
+4. Eliminate candidates. For the survivors: what caused them?
+5. Continue until you reach a cause that has no upstream cause within scope — or a point where further tracing requires different expertise or data.
+6. Distinguish: **root cause** (the origin), **proximate cause** (the immediate trigger), **contributing factors** (conditions that allowed it).
+
+### Mode 2: Impact Mapping
+*"What breaks if I change X?"*
+
+Work forwards from a proposed change through its downstream effects.
+
+**Process:**
+1. State the change precisely.
+2. Identify direct dependents: what immediately relies on the thing being changed?
+3. For each dependent: what behaviour changes, and what downstream systems rely on that behaviour?
+4. Continue for two to three levels of dependency.
+5. Mark irreversible effects — changes that, once made, cannot be cleanly undone.
+6. Mark cascade risks — places where a small effect triggers a large one.
+
+### Mode 3: Dependency Mapping
+*"What must be true for this to work?"*
+
+Identify the full set of conditions a plan depends on.
+
+**Process:**
+1. State the plan or goal.
+2. Ask: what must be true in the environment for this to succeed? List all dependencies.
+3. For each dependency: is it guaranteed, assumed, or unknown?
+4. For each assumed dependency: what is the cost if the assumption is wrong?
+5. Surface single points of failure — dependencies that, if they break, cause total plan failure with no fallback.
+
+### Mode 4: Counterfactual Testing
+*"Would Y still have happened without X?"*
+
+Test a causal claim by reasoning about the counterfactual world.
+
+**Process:**
+1. State the causal claim: "X caused Y."
+2. Imagine removing X. Would Y still happen via another path?
+3. If yes: X is a contributing factor, not the root cause.
+4. If no: X is necessary for Y — strong causal evidence.
+5. Consider: was X sufficient alone, or did it require other conditions?
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Direct causes only** — map first-order causal links, skip downstream consequences
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Mode:** [Root Cause / Impact Mapping / Dependency Mapping / Counterfactual]
+
+**Question:** [the specific causal question being answered]
+
+**[Mode-appropriate structure]**
+
+For Root Cause:
+- Proximate cause: [immediate trigger]
+- Root cause: [origin]
+- Contributing factors: [conditions that enabled it]
+- Evidence: [what confirms this vs what was ruled out]
+
+For Impact Mapping:
+- Direct effects: [level 1 dependencies affected]
+- Downstream effects: [level 2-3]
+- Irreversible effects: [flagged]
+- Cascade risks: [flagged]
+
+For Dependency Mapping:
+- Dependencies: [each, with status: guaranteed / assumed / unknown]
+- Single points of failure: [flagged]
+- Highest-risk assumptions: [ranked]
+
+For Counterfactual:
+- Causal claim tested: [X caused Y]
+- Counterfactual: [would Y happen without X?]
+- Verdict: [necessary / contributing / coincidental]
+- Conditions required alongside X: [if X alone wasn't sufficient]
+
+**Summary**
+[2-3 sentences on what the causal analysis reveals and what action it implies]
+
+---
+
+## Notes
+
+Causal reasoning is always provisional — it produces the best available model given current evidence, not a proof. State explicitly what evidence would change the analysis. In complex systems, multiple causal chains often contribute to a single effect; resist the urge to stop at the first plausible explanation.

package/skills/logic-check/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: logic-check
+description: "A fast, comprehensive logic report on any argument, plan, or reasoning — validates premises, tests inference, detects fallacies, surfaces hidden assumptions, and produces a verdict. Lighter than logic-council (no peer review), heavier than logic-argument-validation (covers the whole reasoning, not just one argument). Triggers: 'logic check', 'quick logic review', 'check my reasoning', 'is this sound', 'full logic check', any request for a complete logical assessment."
+---
+
+# Logic Check
+
+An argument can fail in three distinct places: a premise can be false, the inference can be invalid (the conclusion doesn't follow even if premises are true), or a hidden assumption can be doing load-bearing work without being examined. Most reasoning errors are invisible because they happen in exactly these places. A complete logic check must test all three.
+
+---
+
+## Your Process
+
+**Step 1: Extract the Argument Structure**
+Identify the premises (claims taken as given), the inference (how they connect), and the conclusion (what is claimed to follow). Write them out explicitly. Complex reasoning often has multiple linked arguments — map the chain.
+
+**Step 2: Test Each Premise**
+Classify each premise:
+- **Established fact** — supported by reliable evidence
+- **Reasonable assumption** — plausible but not established; stakes determine whether it needs verification
+- **Contested claim** — disputed or uncertain; the argument depends on this being true
+- **Unsupported assertion** — no evidence offered
+
+The argument is only as strong as its weakest load-bearing premise.
+
+**Step 3: Test the Inference**
+Even if all premises are true: does the conclusion follow? Test with a steelman of the denial — can the premises all be true and the conclusion still be false? If yes, the inference is invalid. Common inference failures: missing variables, scope shifts (all → some), correlation treated as causation.
+
+**Step 4: Scan for Fallacies**
+Name any fallacies present specifically — do not give a generic list. Common ones in strategic and analytical reasoning: hasty generalisation, false dilemma, straw man, appeal to authority, ad hominem, sunk cost, post hoc ergo propter hoc, false analogy, slippery slope.
+
+**Step 5: Surface Hidden Assumptions**
+What must be true for the argument to work — but is never stated? These are the most dangerous load-bearers because they are not examined. Ask: "What would have to be true for this to hold? Is it?"
+
+**Step 6: Assess Overall**
+Does the reasoning hold? Give a verdict and name the specific weaknesses if it doesn't.
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Premises only** — surface what's being taken as given and classify each, skip inference and fallacy sections
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+### Argument Structure
+**Premises:**
+1. [P1]
+2. [P2]
+3. [P3]
+
+**Inference:** [How the premises are claimed to connect to the conclusion]
+
+**Conclusion:** [What is claimed to follow]
+
+### Premise Assessment
+| Premise | Classification | Notes |
+|---------|---------------|-------|
+| P1 | Established / Assumption / Contested / Unsupported | ... |
+| P2 | ... | ... |
+
+### Inference Validity
+**Valid:** Yes / No / Partially
+**Analysis:** [Does the conclusion follow from the premises? Where does the inference fail if it does?]
+
+### Fallacies Found
+- [Name of fallacy] — [Where it appears in the argument, specifically]
+- (None found — if absent)
+
+### Hidden Assumptions
+- [Assumption doing load-bearing work] — [Whether it holds]
+
+### Verdict
+**The reasoning:** Holds / Has specific problems / Does not hold
+
+**Specific problems (if any):**
+1. [Problem] — [Why it matters to the conclusion]
+
+---
+
+## Notes
+
+Use logic-council when the situation requires adversarial peer challenge between logical positions. Use logic-argument-validation for a single, focused argument. This skill covers complete reasoning chains — plans, proposals, analyses — in a single pass.

package/skills/logic-consistency-check/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: logic-consistency-check
+description: "Surface internal contradictions, conflicting requirements, and edge cases that expose hidden conflicts in a document, spec, plan, design, or set of requirements. Use when something feels off but you can't pinpoint why, before committing to a design, or when requirements have grown incrementally and may have drifted out of sync. TRIGGERS: 'consistency check', 'find contradictions', 'does this spec make sense', 'check for conflicts', 'something feels wrong here', reviewing requirements docs, technical specs, architecture plans, product briefs, or any document where internal coherence matters."
+---
+
+# Logic Consistency Check
+
+Requirements drift. Specs accumulate. A document written over weeks by multiple people — or a set of decisions made incrementally — can contain contradictions that nobody noticed because each piece was reviewed in isolation.
+
+This skill reads the whole and finds where the parts disagree.
+
+---
+
+## Your Process
+
+**Step 1: Map the claims**
+Before checking for consistency, inventory what the document asserts:
+- Goals and objectives stated
+- Constraints and non-negotiables stated
+- Assumptions stated or implied
+- Decisions and their stated rationale
+- Any numbered requirements or acceptance criteria
+
+This map is what gets checked for internal coherence — not whether any claim is *true*, but whether the claims are consistent with each other.
+
+**Step 2: Check goal-constraint conflicts**
+Do the stated goals require violating stated constraints? Common patterns:
+- A performance goal that requires more resources than the budget allows
+- A simplicity goal combined with a feature list that requires complexity
+- A timeline that requires skipping steps the quality requirements depend on
+
+**Step 3: Check requirement-requirement conflicts**
+Do individual requirements contradict each other?
+- Two requirements that can't both be satisfied simultaneously
+- A requirement that is a special case of another requirement but handled differently
+- Requirements that use the same term with different implicit meanings (equivocation across requirements)
+
+**Step 4: Find edge cases that expose conflicts**
+Some contradictions only appear at the boundary. Ask: what happens when...
+- Input is at its minimum and maximum values simultaneously required
+- Two features interact that were designed independently
+- The happy path assumption fails
+- A stated exception meets a stated rule
+
+**Step 5: Check assumption coherence**
+Implicit assumptions are the most dangerous source of inconsistency — stated nowhere, but load-bearing everywhere. Surface them:
+- What must be true for each requirement to be satisfiable?
+- Do any of those assumptions contradict each other?
+- Do any assumptions contradict stated facts?
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Contradictions list only** — flag the specific inconsistencies without full analysis
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Subject:** [what was checked]
+
+**Contradictions Found**
+
+| Type | Item A | Item B | Conflict |
+|---|---|---|---|
+| Goal vs constraint | [goal] | [constraint] | [why they conflict] |
+| Requirement vs requirement | [req] | [req] | [why they conflict] |
+| Assumption vs fact | [assumption] | [fact] | [why they conflict] |
+
+*"None found" if clean.*
+
+**Edge Cases That Expose Conflicts**
+- [scenario]: [which requirements or goals it breaks]
+
+**Hidden Assumptions**
+- [assumption]: [which requirements depend on it; whether it's safe]
+
+**Verdict**
+[Overall consistency assessment — clean, minor issues, or significant conflicts that need resolution before proceeding]
+
+**Recommended Resolutions**
+- [Specific change per conflict — which item to amend and how]
+
+---
+
+## Notes
+
+Not every inconsistency is equally urgent. Flag severity: a contradiction in core requirements is a blocker; an ambiguity in an edge case may just need a decision logged. The goal is to make implicit conflicts explicit so they can be resolved consciously rather than discovered in production.

package/skills/logic-constraint-mapping/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: logic-constraint-mapping
+description: "Map the full constraint landscape for a decision, design, or plan — distinguishing hard limits from soft preferences, surfacing hidden constraints, and finding conflicts between them. Use before committing to an approach, when a plan keeps hitting unexpected walls, or when it's unclear what's actually negotiable. TRIGGERS: 'map the constraints', 'what are we actually working with', 'what's blocking this', 'what can we change', 'constraint analysis', any situation where the boundaries of what's possible need to be understood before proceeding."
+---
+
+# Logic Constraint Mapping
+
+Every decision happens inside a constraint space. Some limits are real and fixed. Others feel fixed but aren't. And some constraints conflict with each other in ways nobody has named yet.
+
+The map makes that space visible — so you're solving the actual problem, not a version of it you've accidentally invented by treating assumptions as facts.
+
+---
+
+## Types of Constraints
+
+**Hard constraints** — cannot be violated without abandoning the goal entirely. Physical laws, legal requirements, contractual obligations, irreversible dependencies.
+
+**Soft constraints** — strong preferences or defaults that can be negotiated under sufficient pressure. Budget, timeline, team size, technology choices, organisational preferences.
+
+**Hidden constraints** — not explicitly stated, but load-bearing. Discovered when violated. Often cultural, political, or architectural. The most dangerous kind.
+
+**Conflicting constraints** — two constraints that cannot both be fully satisfied. Require a conscious trade-off decision rather than a solution.
+
+---
+
+## Your Process
+
+**Step 1: Extract stated constraints**
+What limits have been explicitly named? Separate:
+- Stated as hard: "must", "cannot", "required", "non-negotiable"
+- Stated as soft: "should", "prefer", "ideally", "target"
+- Implied but unstated: present in the problem framing without being declared
+
+**Step 2: Test each constraint's hardness**
+For every constraint labelled hard, ask: *what would actually happen if we violated it?*
+- Legal/regulatory: real hard — violation has defined consequences
+- Budget/timeline: often softer than declared — the consequence is negotiation, not failure
+- Technical: depends on reversibility — changing a database schema is hard; changing a variable name is not
+- Organisational: often the softest of all, disguised as the hardest
+
+Reclassify where the test shows the constraint is softer than claimed.
+
+**Step 3: Surface hidden constraints**
+Ask:
+- What would break if we changed X? (reveals architectural constraints)
+- Who has to approve this? (reveals political constraints)
+- What can't we undo once we start? (reveals irreversibility constraints)
+- What are we assuming about the environment that isn't guaranteed? (reveals dependency constraints)
+
+**Step 4: Find constraint conflicts**
+With the full map laid out, which constraints cannot all be satisfied simultaneously?
+- Time vs quality vs scope (the classic three)
+- Flexibility vs stability (don't break the API vs let it evolve)
+- Performance vs cost
+- Security vs usability
+
+For each conflict: name what's being traded off and who decides.
+
+**Step 5: Identify the degrees of freedom**
+What's genuinely open? After removing hard and near-hard constraints, what remains movable? This is where the actual solution space lives.
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Hard constraints only** — identify which limits are truly non-negotiable, skip soft and assumed
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Context:** [what decision or plan this constraint map is for]
+
+**Constraint Inventory**
+
+| Constraint | Type | Hardness | Source |
+|---|---|---|---|
+| [constraint] | Limit / Preference / Hidden | Hard / Soft / Unknown | [who imposed it, why] |
+
+**Hardness Reassessments**
+- [constraint stated as hard] → actually [softer] because [reason]
+
+**Hidden Constraints Found**
+- [constraint]: [what revealed it; what it blocks]
+
+**Conflicts**
+| Constraint A | Constraint B | Trade-off | Owner |
+|---|---|---|---|
+| [A] | [B] | [what gives if you prioritise A; what gives if you prioritise B] | [who decides] |
+
+**Degrees of Freedom**
+[What is genuinely negotiable; where the real solution space is]
+
+---
+
+## Notes
+
+The value of this map is not finding solutions — it's establishing ground truth about what's actually fixed before committing to an approach. A constraint map produced before design prevents the common failure mode: a clever solution that satisfies stated requirements while violating an unstated one that everyone assumed was obvious.

package/skills/logic-council/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: logic-council
+description: "Run a reasoning problem, argument, plan, or decision through a council of 5 logical reasoning advisors who analyze it from distinct reasoning frameworks, peer-review each other, and synthesize a verdict on whether the reasoning holds. MANDATORY TRIGGERS: 'logic council this', 'run the logic council', 'pressure-test this reasoning', 'is my thinking sound'. STRONG TRIGGERS: any complex argument where the conclusion matters, a plan with non-obvious dependencies, reasoning you've invested in and want stress-tested. Use ethics-council for moral questions, llm-council for general decisions — this council is specifically for testing the soundness of reasoning itself."
+---
+
+# Logic Council
+
+A single reviewer catches some flaws in reasoning. A council catches more — because different reasoning frameworks find different failure modes. Formal logic catches invalid inferences. Systems thinking catches missing feedback loops. Bayesian reasoning catches base-rate neglect. First principles reasoning catches assumptions dressed as facts. Adversarial logic catches the strongest counter-argument you haven't faced yet.
+
+Run all five. Let them disagree. The synthesis tells you where your reasoning is load-bearing and where it's hollow.
+
+---
+
+## The Five Reasoning Frameworks
+
+### 1. Formal Logic
+Tests deductive structure. Are premises stated? Do they support the conclusion? Are necessary and sufficient conditions correctly identified? Finds: invalid inferences, unstated assumptions doing hidden work, conclusions that overreach their premises, equivocation across terms.
+
+### 2. Systems Thinking
+Treats the problem as a system with feedback loops, delays, and emergent properties. Asks: what happens over time? What non-linear effects appear at scale? What second and third-order consequences has the reasoning ignored? Finds: linear thinking applied to non-linear systems, missing feedback loops, unintended consequences, solutions that fix the proximate cause while worsening the root cause.
+
+### 3. Bayesian Reasoning
+Evaluates probabilistic claims and evidence. Asks: what are the base rates? How much should this evidence actually update our beliefs? Is confidence calibrated to evidence? Finds: base-rate neglect, overconfidence from anecdote, underweighted prior probability, failure to consider how likely the evidence would be under alternative hypotheses.
+
+### 4. First Principles
+Strips away assumptions and rebuilds from fundamentals. Asks: what do we actually know is true, vs what are we taking for granted? Is the problem framed correctly, or has the framing inherited constraints that don't belong? Finds: assumptions treated as facts, inherited framings that foreclose better solutions, analogies stretched past their breaking point.
+
+### 5. Adversarial Logic
+Steelmans the strongest counter-argument. Asks: what is the best version of the opposing case? If this reasoning is wrong, what's the most compelling reason it's wrong? Finds: the objections the reasoning hasn't faced, the cases where the conclusion fails, the evidence that would most efficiently falsify it.
+
+**Why these five:** They create genuine tension. Formal logic and Adversarial logic both find flaws, but via different mechanisms. Systems thinking and Bayesian reasoning both deal with uncertainty, but differently. First Principles stands apart from all four — it questions whether the problem is being solved at all.
+
+---
+
+## How a Council Session Works
+
+### Step 1: Frame the Reasoning
+
+State what is being evaluated — an argument, a plan's logic, a reasoning chain, a stated conclusion and its support. Include:
+1. The claim or conclusion being made
+2. The premises or evidence supporting it
+3. Any context needed to evaluate the reasoning
+
+If the subject is vague, ask one clarifying question before proceeding.
+
+---
+
+### Human Check-in
+
+After framing the question, ask the user:
+
+**How do you want to run the council?**
+
+- **A) Full council** — all 5 advisors + peer review + chair synthesis + saved transcript
+- **B) Chair synthesis only** — skip advisor outputs, deliver the verdict directly
+- **C) Strongest objection only** — skip all advisors and peer review, identify the single most devastating challenge to this reasoning
+- **D) Adjust the framing** — revisit the question before convening
+
+Proceed based on their choice.
+
+---
+
+### Step 2: Convene the Council (5 subagents in parallel)
+
+Spawn all 5 framework advisors simultaneously.
+
+**Subagent prompt template:**
+```
+You are reasoning from the [Framework Name] perspective in a Logic Council.
+
+Your framework: [framework description — core logic, what it finds, what it prioritises]
+
+A Logic Council has been convened on this reasoning:
+---
+[framed reasoning]
+---
+
+Analyze this reasoning from your framework. Where does it hold? Where does it fail? What does your framework specifically find that other approaches might miss?
+
+Be direct and specific. Don't hedge. Lean fully into your framework — the synthesis comes later.
+
+150–300 words. No preamble.
+```
+
+---
+
+### Step 3: Peer Review (5 subagents in parallel)
+
+Anonymize responses as A through E. Spawn 5 reviewers, each seeing all five.
+
+Each reviewer answers:
+1. Which response identified the most significant flaw in the reasoning? Why?
+2. Which response has the biggest blind spot — what is it missing?
+3. What do *all* the responses agree on? (High-confidence signal — if five different frameworks find the same problem, it's real.)
+
+---
+
+### Step 4: Chair Synthesis
+
+One agent synthesizes everything into a verdict:
+
+**LOGIC COUNCIL VERDICT**
+
+1. **Where the frameworks agree** — reasoning failures flagged by multiple frameworks independently. These are the most reliable findings.
+2. **Where the frameworks diverge** — disagreements about whether or how the reasoning fails, and why.
+3. **The strongest single objection** — the most damaging finding across all five frameworks.
+4. **Verdict** — does the reasoning hold? If not, where exactly does it break?
+5. **What would make it sound** — the specific changes that would address the council's findings.
+
+**Chair prompt template:**
+```
+You are the Chair of a Logic Council. Synthesize the work of 5 reasoning-framework advisors and their peer reviews.
+
+The reasoning under examination:
+---
+[framed reasoning]
+---
+
+FRAMEWORK RESPONSES:
+[de-anonymized advisor responses]
+
+PEER REVIEWS:
+[all 5 peer reviews]
+
+Produce the verdict:
+
+## Where the Frameworks Agree
+[Findings multiple frameworks reached independently — high-confidence signals]
+
+## Where the Frameworks Diverge
+[Genuine disagreements about the reasoning's validity]
+
+## The Strongest Single Objection
+[The most damaging finding; the one that most undermines the reasoning]
+
+## Verdict
+[Does this reasoning hold? Where exactly does it break, if so?]
+
+## What Would Make It Sound
+[Specific repairs — premises to add, claims to qualify, steps to make explicit]
+
+Be direct. The council's value is telling the person where their reasoning breaks, not reassuring them it's fine.
+```
+
+---
+
+### Step 5: Save the Output
+
+Save the full transcript as `logic-council-transcript-[timestamp].md`. Optionally generate an HTML report with the verdict prominent and advisor responses collapsible.
+
+---
+
+## Notes
+
+- **Spawn all five in parallel.** Sequential spawning lets earlier frameworks contaminate later ones.
+- **The chair can dissent.** If four frameworks find no flaw but the fifth's objection is devastating, the chair should say so.
+- **Agreement across frameworks is the strongest signal.** When five different reasoning approaches all flag the same problem, that problem is real.
+- For reasoning that fails the council, consider using `logic-fixer` to produce a corrected version.