Install
$ agentstack add skill-affaan-m-ecc-council ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
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:
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:
## 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-opsto store the lesson in the right durable location - or use
/save-sessionif 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 verificationknowledge-ops— persist durable decision deltas correctlysearch-first— gather external reference material before the council if neededarchitecture-decision-records— formalize the outcome when the decision becomes long-lived system policy
Example
Question:
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.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: affaan-m
- Source: affaan-m/ECC
- License: MIT
- Homepage: https://ecc.tools
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.