@funnycode/myclaude 0.1.76 → 0.1.78

package/seed/marketplaces/ecc/skills/council/SKILL.md

@@ -1,203 +1,203 @@
----
-name: council
-description: Convene a four-voice council for ambiguous decisions, tradeoffs, and go/no-go calls. Use when multiple valid paths exist and you need structured disagreement before choosing.
-origin: ECC
----
-
-# Council
-
-Convene four advisors for ambiguous decisions:
-- the in-context Claude voice
-- a Skeptic subagent
-- a Pragmatist subagent
-- a Critic subagent
-
-This is for **decision-making under ambiguity**, not code review, implementation planning, or architecture design.
-
-## When to Use
-
-Use council when:
-- a decision has multiple credible paths and no obvious winner
-- you need explicit tradeoff surfacing
-- the user asks for second opinions, dissent, or multiple perspectives
-- conversational anchoring is a real risk
-- a go / no-go call would benefit from adversarial challenge
-
-Examples:
-- monorepo vs polyrepo
-- ship now vs hold for polish
-- feature flag vs full rollout
-- simplify scope vs keep strategic breadth
-
-## When NOT to Use
-
-| Instead of council | Use |
-| --- | --- |
-| Verifying whether output is correct | `santa-method` |
-| Breaking a feature into implementation steps | `planner` |
-| Designing system architecture | `architect` |
-| Reviewing code for bugs or security | `code-reviewer` or `santa-method` |
-| Straight factual questions | just answer directly |
-| Obvious execution tasks | just do the task |
-
-## Roles
-
-| Voice | Lens |
-| --- | --- |
-| Architect | correctness, maintainability, long-term implications |
-| Skeptic | premise challenge, simplification, assumption breaking |
-| Pragmatist | shipping speed, user impact, operational reality |
-| Critic | edge cases, downside risk, failure modes |
-
-The three external voices should be launched as fresh subagents with **only the question and relevant context**, not the full ongoing conversation. That is the anti-anchoring mechanism.
-
-## Workflow
-
-### 1. Extract the real question
-
-Reduce the decision to one explicit prompt:
-- what are we deciding?
-- what constraints matter?
-- what counts as success?
-
-If the question is vague, ask one clarifying question before convening the council.
-
-### 2. Gather only the necessary context
-
-If the decision is codebase-specific:
-- collect the relevant files, snippets, issue text, or metrics
-- keep it compact
-- include only the context needed to make the decision
-
-If the decision is strategic/general:
-- skip repo snippets unless they materially change the answer
-
-### 3. Form the Architect position first
-
-Before reading other voices, write down:
-- your initial position
-- the three strongest reasons for it
-- the main risk in your preferred path
-
-Do this first so the synthesis does not simply mirror the external voices.
-
-### 4. Launch three independent voices in parallel
-
-Each subagent gets:
-- the decision question
-- compact context if needed
-- a strict role
-- no unnecessary conversation history
-
-Prompt shape:
-
-```text
-You are the [ROLE] on a four-voice decision council.
-
-Question:
-[decision question]
-
-Context:
-[only the relevant snippets or constraints]
-
-Respond with:
-1. Position — 1-2 sentences
-2. Reasoning — 3 concise bullets
-3. Risk — biggest risk in your recommendation
-4. Surprise — one thing the other voices may miss
-
-Be direct. No hedging. Keep it under 300 words.
-```
-
-Role emphasis:
-- Skeptic: challenge framing, question assumptions, propose the simplest credible alternative
-- Pragmatist: optimize for speed, simplicity, and real-world execution
-- Critic: surface downside risk, edge cases, and reasons the plan could fail
-
-### 5. Synthesize with bias guardrails
-
-You are both a participant and the synthesizer, so use these rules:
-- do not dismiss an external view without explaining why
-- if an external voice changed your recommendation, say so explicitly
-- always include the strongest dissent, even if you reject it
-- if two voices align against your initial position, treat that as a real signal
-- keep the raw positions visible before the verdict
-
-### 6. Present a compact verdict
-
-Use this output shape:
-
-```markdown
-## Council: [short decision title]
-
-**Architect:** [1-2 sentence position]
-[1 line on why]
-
-**Skeptic:** [1-2 sentence position]
-[1 line on why]
-
-**Pragmatist:** [1-2 sentence position]
-[1 line on why]
-
-**Critic:** [1-2 sentence position]
-[1 line on why]
-
-### Verdict
-- **Consensus:** [where they align]
-- **Strongest dissent:** [most important disagreement]
-- **Premise check:** [did the Skeptic challenge the question itself?]
-- **Recommendation:** [the synthesized path]
-```
-
-Keep it scannable on a phone screen.
-
-## Persistence Rule
-
-Do **not** write ad-hoc notes to `~/.claude/notes` or other shadow paths from this skill.
-
-If the council materially changes the recommendation:
-- use `knowledge-ops` to store the lesson in the right durable location
-- or use `/save-session` if the outcome belongs in session memory
-- or update the relevant GitHub / Linear issue directly if the decision changes active execution truth
-
-Only persist a decision when it changes something real.
-
-## Multi-Round Follow-up
-
-Default is one round.
-
-If the user wants another round:
-- keep the new question focused
-- include the previous verdict only if it is necessary
-- keep the Skeptic as clean as possible to preserve anti-anchoring value
-
-## Anti-Patterns
-
-- using council for code review
-- using council when the task is just implementation work
-- feeding the subagents the entire conversation transcript
-- hiding disagreement in the final verdict
-- persisting every decision as a note regardless of importance
-
-## Related Skills
-
-- `santa-method` — adversarial verification
-- `knowledge-ops` — persist durable decision deltas correctly
-- `search-first` — gather external reference material before the council if needed
-- `architecture-decision-records` — formalize the outcome when the decision becomes long-lived system policy
-
-## Example
-
-Question:
-
-```text
-Should we ship ECC 2.0 as alpha now, or hold until the control-plane UI is more complete?
-```
-
-Likely council shape:
-- Architect pushes for structural integrity and avoiding a confused surface
-- Skeptic questions whether the UI is actually the gating factor
-- Pragmatist asks what can be shipped now without harming trust
-- Critic focuses on support burden, expectation debt, and rollout confusion
-
-The value is not unanimity. The value is making the disagreement legible before choosing.
+---
+name: council
+description: Convene a four-voice council for ambiguous decisions, tradeoffs, and go/no-go calls. Use when multiple valid paths exist and you need structured disagreement before choosing.
+origin: ECC
+---
+
+# Council
+
+Convene four advisors for ambiguous decisions:
+- the in-context Claude voice
+- a Skeptic subagent
+- a Pragmatist subagent
+- a Critic subagent
+
+This is for **decision-making under ambiguity**, not code review, implementation planning, or architecture design.
+
+## When to Use
+
+Use council when:
+- a decision has multiple credible paths and no obvious winner
+- you need explicit tradeoff surfacing
+- the user asks for second opinions, dissent, or multiple perspectives
+- conversational anchoring is a real risk
+- a go / no-go call would benefit from adversarial challenge
+
+Examples:
+- monorepo vs polyrepo
+- ship now vs hold for polish
+- feature flag vs full rollout
+- simplify scope vs keep strategic breadth
+
+## When NOT to Use
+
+| Instead of council | Use |
+| --- | --- |
+| Verifying whether output is correct | `santa-method` |
+| Breaking a feature into implementation steps | `planner` |
+| Designing system architecture | `architect` |
+| Reviewing code for bugs or security | `code-reviewer` or `santa-method` |
+| Straight factual questions | just answer directly |
+| Obvious execution tasks | just do the task |
+
+## Roles
+
+| Voice | Lens |
+| --- | --- |
+| Architect | correctness, maintainability, long-term implications |
+| Skeptic | premise challenge, simplification, assumption breaking |
+| Pragmatist | shipping speed, user impact, operational reality |
+| Critic | edge cases, downside risk, failure modes |
+
+The three external voices should be launched as fresh subagents with **only the question and relevant context**, not the full ongoing conversation. That is the anti-anchoring mechanism.
+
+## Workflow
+
+### 1. Extract the real question
+
+Reduce the decision to one explicit prompt:
+- what are we deciding?
+- what constraints matter?
+- what counts as success?
+
+If the question is vague, ask one clarifying question before convening the council.
+
+### 2. Gather only the necessary context
+
+If the decision is codebase-specific:
+- collect the relevant files, snippets, issue text, or metrics
+- keep it compact
+- include only the context needed to make the decision
+
+If the decision is strategic/general:
+- skip repo snippets unless they materially change the answer
+
+### 3. Form the Architect position first
+
+Before reading other voices, write down:
+- your initial position
+- the three strongest reasons for it
+- the main risk in your preferred path
+
+Do this first so the synthesis does not simply mirror the external voices.
+
+### 4. Launch three independent voices in parallel
+
+Each subagent gets:
+- the decision question
+- compact context if needed
+- a strict role
+- no unnecessary conversation history
+
+Prompt shape:
+
+```text
+You are the [ROLE] on a four-voice decision council.
+
+Question:
+[decision question]
+
+Context:
+[only the relevant snippets or constraints]
+
+Respond with:
+1. Position — 1-2 sentences
+2. Reasoning — 3 concise bullets
+3. Risk — biggest risk in your recommendation
+4. Surprise — one thing the other voices may miss
+
+Be direct. No hedging. Keep it under 300 words.
+```
+
+Role emphasis:
+- Skeptic: challenge framing, question assumptions, propose the simplest credible alternative
+- Pragmatist: optimize for speed, simplicity, and real-world execution
+- Critic: surface downside risk, edge cases, and reasons the plan could fail
+
+### 5. Synthesize with bias guardrails
+
+You are both a participant and the synthesizer, so use these rules:
+- do not dismiss an external view without explaining why
+- if an external voice changed your recommendation, say so explicitly
+- always include the strongest dissent, even if you reject it
+- if two voices align against your initial position, treat that as a real signal
+- keep the raw positions visible before the verdict
+
+### 6. Present a compact verdict
+
+Use this output shape:
+
+```markdown
+## Council: [short decision title]
+
+**Architect:** [1-2 sentence position]
+[1 line on why]
+
+**Skeptic:** [1-2 sentence position]
+[1 line on why]
+
+**Pragmatist:** [1-2 sentence position]
+[1 line on why]
+
+**Critic:** [1-2 sentence position]
+[1 line on why]
+
+### Verdict
+- **Consensus:** [where they align]
+- **Strongest dissent:** [most important disagreement]
+- **Premise check:** [did the Skeptic challenge the question itself?]
+- **Recommendation:** [the synthesized path]
+```
+
+Keep it scannable on a phone screen.
+
+## Persistence Rule
+
+Do **not** write ad-hoc notes to `~/.claude/notes` or other shadow paths from this skill.
+
+If the council materially changes the recommendation:
+- use `knowledge-ops` to store the lesson in the right durable location
+- or use `/save-session` if the outcome belongs in session memory
+- or update the relevant GitHub / Linear issue directly if the decision changes active execution truth
+
+Only persist a decision when it changes something real.
+
+## Multi-Round Follow-up
+
+Default is one round.
+
+If the user wants another round:
+- keep the new question focused
+- include the previous verdict only if it is necessary
+- keep the Skeptic as clean as possible to preserve anti-anchoring value
+
+## Anti-Patterns
+
+- using council for code review
+- using council when the task is just implementation work
+- feeding the subagents the entire conversation transcript
+- hiding disagreement in the final verdict
+- persisting every decision as a note regardless of importance
+
+## Related Skills
+
+- `santa-method` — adversarial verification
+- `knowledge-ops` — persist durable decision deltas correctly
+- `search-first` — gather external reference material before the council if needed
+- `architecture-decision-records` — formalize the outcome when the decision becomes long-lived system policy
+
+## Example
+
+Question:
+
+```text
+Should we ship ECC 2.0 as alpha now, or hold until the control-plane UI is more complete?
+```
+
+Likely council shape:
+- Architect pushes for structural integrity and avoiding a confused surface
+- Skeptic questions whether the UI is actually the gating factor
+- Pragmatist asks what can be shipped now without harming trust
+- Critic focuses on support burden, expectation debt, and rollout confusion
+
+The value is not unanimity. The value is making the disagreement legible before choosing.