[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7EWMQ3NS7W4MPVR4RBCX5GA":3,"skill-same:01M7EWMQ3NS7W4MPVR4RBCX5GA":48},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":26,"commitSha":27,"skillDirectory":28,"forksCount":29,"repositoryHtmlUrl":30,"repositoryHomepageUrl":6,"ownerHtmlUrl":31,"ownerBlogUrl":32,"ownerDescription":6,"updatedAt":33,"install":34,"resources":47},"01M7EWMQ3NS7W4MPVR4RBCX5GA","council",null,"Convene a four-voice council for ambiguous decisions, tradeoffs, and go\u002Fno-go calls. Use when multiple valid paths exist and you need structured disagreement before choosing.","TanNhatCMS\u002Fjarvis","TanNhatCMS","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F113796420?v=4","01M753MV17KG5CD3152G3WQEQY","KietNT","01M7EKEDYVYQ6PWVJJMZ911VMX",0,"MIT","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fecc-council\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: council\ndescription: Convene a four-voice council for ambiguous decisions, tradeoffs, and go\u002Fno-go calls. Use when multiple valid paths exist and you need structured disagreement before choosing.\nmetadata:\n  origin: ECC\n---\n\n# Council\n\nConvene four advisors for ambiguous decisions:\n- the in-context Claude voice\n- a Skeptic subagent\n- a Pragmatist subagent\n- a Critic subagent\n\nThis is for **decision-making under ambiguity**, not code review, implementation planning, or architecture design.\n\n## When to Use\n\nUse council when:\n- a decision has multiple credible paths and no obvious winner\n- you need explicit tradeoff surfacing\n- the user asks for second opinions, dissent, or multiple perspectives\n- conversational anchoring is a real risk\n- a go \u002F no-go call would benefit from adversarial challenge\n\nExamples:\n- monorepo vs polyrepo\n- ship now vs hold for polish\n- feature flag vs full rollout\n- simplify scope vs keep strategic breadth\n\n## When NOT to Use\n\n| Instead of council | Use |\n| --- | --- |\n| Verifying whether output is correct | `santa-method` |\n| Breaking a feature into implementation steps | `planner` |\n| Designing system architecture | `architect` |\n| Reviewing code for bugs or security | `code-reviewer` or `santa-method` |\n| Straight factual questions | just answer directly |\n| Obvious execution tasks | just do the task |\n\n## Roles\n\n| Voice | Lens |\n| --- | --- |\n| Architect | correctness, maintainability, long-term implications |\n| Skeptic | premise challenge, simplification, assumption breaking |\n| Pragmatist | shipping speed, user impact, operational reality |\n| Critic | edge cases, downside risk, failure modes |\n\nThe 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.\n\n## Workflow\n\n### 1. Extract the real question\n\nReduce the decision to one explicit prompt:\n- what are we deciding?\n- what constraints matter?\n- what counts as success?\n\nIf the question is vague, ask one clarifying question before convening the council.\n\n### 2. Gather only the necessary context\n\nIf the decision is codebase-specific:\n- collect the relevant files, snippets, issue text, or metrics\n- keep it compact\n- include only the context needed to make the decision\n\nIf the decision is strategic\u002Fgeneral:\n- skip repo snippets unless they materially change the answer\n\n### 3. Form the Architect position first\n\nBefore reading other voices, write down:\n- your initial position\n- the three strongest reasons for it\n- the main risk in your preferred path\n\nDo this first so the synthesis does not simply mirror the external voices.\n\n### 4. Launch three independent voices in parallel\n\nEach subagent gets:\n- the decision question\n- compact context if needed\n- a strict role\n- no unnecessary conversation history\n\nPrompt shape:\n\n```text\nYou are the [ROLE] on a four-voice decision council.\n\nQuestion:\n[decision question]\n\nContext:\n[only the relevant snippets or constraints]\n\nRespond with:\n1. Position — 1-2 sentences\n2. Reasoning — 3 concise bullets\n3. Risk — biggest risk in your recommendation\n4. Surprise — one thing the other voices may miss\n\nBe direct. No hedging. Keep it under 300 words.\n```\n\nRole emphasis:\n- Skeptic: challenge framing, question assumptions, propose the simplest credible alternative\n- Pragmatist: optimize for speed, simplicity, and real-world execution\n- Critic: surface downside risk, edge cases, and reasons the plan could fail\n\n### 5. Synthesize with bias guardrails\n\nYou are both a participant and the synthesizer, so use these rules:\n- do not dismiss an external view without explaining why\n- if an external voice changed your recommendation, say so explicitly\n- always include the strongest dissent, even if you reject it\n- if two voices align against your initial position, treat that as a real signal\n- keep the raw positions visible before the verdict\n\n### 6. Present a compact verdict\n\nUse this output shape:\n\n```markdown\n## Council: [short decision title]\n\n**Architect:** [1-2 sentence position]\n[1 line on why]\n\n**Skeptic:** [1-2 sentence position]\n[1 line on why]\n\n**Pragmatist:** [1-2 sentence position]\n[1 line on why]\n\n**Critic:** [1-2 sentence position]\n[1 line on why]\n\n### Verdict\n- **Consensus:** [where they align]\n- **Strongest dissent:** [most important disagreement]\n- **Premise check:** [did the Skeptic challenge the question itself?]\n- **Recommendation:** [the synthesized path]\n```\n\nKeep it scannable on a phone screen.\n\n## Persistence Rule\n\nDo **not** write ad-hoc notes to `~\u002F.claude\u002Fnotes` or other shadow paths from this skill.\n\nIf the council materially changes the recommendation:\n- use `knowledge-ops` to store the lesson in the right durable location\n- or use `\u002Fsave-session` if the outcome belongs in session memory\n- or update the relevant GitHub \u002F Linear issue directly if the decision changes active execution truth\n\nOnly persist a decision when it changes something real.\n\n## Multi-Round Follow-up\n\nDefault is one round.\n\nIf the user wants another round:\n- keep the new question focused\n- include the previous verdict only if it is necessary\n- keep the Skeptic as clean as possible to preserve anti-anchoring value\n\n## Anti-Patterns\n\n- using council for code review\n- using council when the task is just implementation work\n- feeding the subagents the entire conversation transcript\n- hiding disagreement in the final verdict\n- persisting every decision as a note regardless of importance\n\n## Related Skills\n\n- `santa-method` — adversarial verification\n- `knowledge-ops` — persist durable decision deltas correctly\n- `search-first` — gather external reference material before the council if needed\n- `architecture-decision-records` — formalize the outcome when the decision becomes long-lived system policy\n\n## Example\n\nQuestion:\n\n```text\nShould we ship ECC 2.0 as alpha now, or hold until the control-plane UI is more complete?\n```\n\nLikely council shape:\n- Architect pushes for structural integrity and avoiding a confused surface\n- Skeptic questions whether the UI is actually the gating factor\n- Pragmatist asks what can be shipped now without harming trust\n- Critic focuses on support burden, expectation debt, and rollout confusion\n\nThe value is not unanimity. The value is making the disagreement legible before choosing.\n","# Council\n\nConvene four advisors for ambiguous decisions:\n- the in-context Claude voice\n- a Skeptic subagent\n- a Pragmatist subagent\n- a Critic subagent\n\nThis is for **decision-making under ambiguity**, not code review, implementation planning, or architecture design.\n\n## When to Use\n\nUse council when:\n- a decision has multiple credible paths and no obvious winner\n- you need explicit tradeoff surfacing\n- the user asks for second opinions, dissent, or multiple perspectives\n- conversational anchoring is a real risk\n- a go \u002F no-go call would benefit from adversarial challenge\n\nExamples:\n- monorepo vs polyrepo\n- ship now vs hold for polish\n- feature flag vs full rollout\n- simplify scope vs keep strategic breadth\n\n## When NOT to Use\n\n| Instead of council | Use |\n| --- | --- |\n| Verifying whether output is correct | `santa-method` |\n| Breaking a feature into implementation steps | `planner` |\n| Designing system architecture | `architect` |\n| Reviewing code for bugs or security | `code-reviewer` or `santa-method` |\n| Straight factual questions | just answer directly |\n| Obvious execution tasks | just do the task |\n\n## Roles\n\n| Voice | Lens |\n| --- | --- |\n| Architect | correctness, maintainability, long-term implications |\n| Skeptic | premise challenge, simplification, assumption breaking |\n| Pragmatist | shipping speed, user impact, operational reality |\n| Critic | edge cases, downside risk, failure modes |\n\nThe 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.\n\n## Workflow\n\n### 1. Extract the real question\n\nReduce the decision to one explicit prompt:\n- what are we deciding?\n- what constraints matter?\n- what counts as success?\n\nIf the question is vague, ask one clarifying question before convening the council.\n\n### 2. Gather only the necessary context\n\nIf the decision is codebase-specific:\n- collect the relevant files, snippets, issue text, or metrics\n- keep it compact\n- include only the context needed to make the decision\n\nIf the decision is strategic\u002Fgeneral:\n- skip repo snippets unless they materially change the answer\n\n### 3. Form the Architect position first\n\nBefore reading other voices, write down:\n- your initial position\n- the three strongest reasons for it\n- the main risk in your preferred path\n\nDo this first so the synthesis does not simply mirror the external voices.\n\n### 4. Launch three independent voices in parallel\n\nEach subagent gets:\n- the decision question\n- compact context if needed\n- a strict role\n- no unnecessary conversation history\n\nPrompt shape:\n\n```text\nYou are the [ROLE] on a four-voice decision council.\n\nQuestion:\n[decision question]\n\nContext:\n[only the relevant snippets or constraints]\n\nRespond with:\n1. Position — 1-2 sentences\n2. Reasoning — 3 concise bullets\n3. Risk — biggest risk in your recommendation\n4. Surprise — one thing the other voices may miss\n\nBe direct. No hedging. Keep it under 300 words.\n```\n\nRole emphasis:\n- Skeptic: challenge framing, question assumptions, propose the simplest credible alternative\n- Pragmatist: optimize for speed, simplicity, and real-world execution\n- Critic: surface downside risk, edge cases, and reasons the plan could fail\n\n### 5. Synthesize with bias guardrails\n\nYou are both a participant and the synthesizer, so use these rules:\n- do not dismiss an external view without explaining why\n- if an external voice changed your recommendation, say so explicitly\n- always include the strongest dissent, even if you reject it\n- if two voices align against your initial position, treat that as a real signal\n- keep the raw positions visible before the verdict\n\n### 6. Present a compact verdict\n\nUse this output shape:\n\n```markdown\n## Council: [short decision title]\n\n**Architect:** [1-2 sentence position]\n[1 line on why]\n\n**Skeptic:** [1-2 sentence position]\n[1 line on why]\n\n**Pragmatist:** [1-2 sentence position]\n[1 line on why]\n\n**Critic:** [1-2 sentence position]\n[1 line on why]\n\n### Verdict\n- **Consensus:** [where they align]\n- **Strongest dissent:** [most important disagreement]\n- **Premise check:** [did the Skeptic challenge the question itself?]\n- **Recommendation:** [the synthesized path]\n```\n\nKeep it scannable on a phone screen.\n\n## Persistence Rule\n\nDo **not** write ad-hoc notes to `~\u002F.claude\u002Fnotes` or other shadow paths from this skill.\n\nIf the council materially changes the recommendation:\n- use `knowledge-ops` to store the lesson in the right durable location\n- or use `\u002Fsave-session` if the outcome belongs in session memory\n- or update the relevant GitHub \u002F Linear issue directly if the decision changes active execution truth\n\nOnly persist a decision when it changes something real.\n\n## Multi-Round Follow-up\n\nDefault is one round.\n\nIf the user wants another round:\n- keep the new question focused\n- include the previous verdict only if it is necessary\n- keep the Skeptic as clean as possible to preserve anti-anchoring value\n\n## Anti-Patterns\n\n- using council for code review\n- using council when the task is just implementation work\n- feeding the subagents the entire conversation transcript\n- hiding disagreement in the final verdict\n- persisting every decision as a note regardless of importance\n\n## Related Skills\n\n- `santa-method` — adversarial verification\n- `knowledge-ops` — persist durable decision deltas correctly\n- `search-first` — gather external reference material before the council if needed\n- `architecture-decision-records` — formalize the outcome when the decision becomes long-lived system policy\n\n## Example\n\nQuestion:\n\n```text\nShould we ship ECC 2.0 as alpha now, or hold until the control-plane UI is more complete?\n```\n\nLikely council shape:\n- Architect pushes for structural integrity and avoiding a confused surface\n- Skeptic questions whether the UI is actually the gating factor\n- Pragmatist asks what can be shipped now without harming trust\n- Critic focuses on support burden, expectation debt, and rollout confusion\n\nThe value is not unanimity. The value is making the disagreement legible before choosing.\n",{"name":5,"metadata":24,"description":7},{"origin":25},"ECC","main","af388a77c2fe5e0b4fd879cca4300a0ffa9a6579","skills\u002Fecc-council",1,"https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis","https:\u002F\u002Fgithub.com\u002FTanNhatCMS","https:\u002F\u002Fmrkiet.name.vn","2026-11-07 14:23:08",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add TanNhatCMS\u002Fjarvis --skill council",{"tool":40,"command":41},"bunx","bunx skills add TanNhatCMS\u002Fjarvis --skill council",{"tool":43,"command":44},"pnpm","pnpm dlx skills add TanNhatCMS\u002Fjarvis --skill council","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fecc-council\u002FSKILL.md",true,[],[49,56,64,71,78,85],{"skillNo":50,"name":51,"nameZh":6,"description":52,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":53,"categories":54,"keywords":55,"publishedAt":19},"01M7EWYJR0J8DARY7E59Z6Y9MV","web-scrape","Turn web pages into LLM-ready markdown via the Firecrawl API (renders JS, anti-bot handling). Use when browser_open\u002Ffetch fails on JS-heavy pages, or when you need clean markdown\u002Fstructured extraction from a site. Requires FIRECRAWL_API_KEY.","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fweb-scrape\u002FSKILL.md",[],[],{"skillNo":57,"name":58,"nameZh":6,"description":59,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":60,"sourceHtmlUrl":61,"categories":62,"keywords":63,"publishedAt":19},"01M7EWYBN5P6F2AJG3FR24T9BP","design-taste-frontend","tasteskill v2, the anti-slop frontend skill. Art direction for websites, distilled from a study of 247 curated gallery sites (One Page Love, Awwwards Sites of the Day). Deals researched directions (idea, composition, type, palette, photographs, section blueprints) from a library, enforces a strict no-slop house style with a real-browser inspector, and runs a look-and-fix loop on screenshots. Use this whenever you build, design, redesign, restyle, polish or review a landing page, marketing site, portfolio, product page, one-pager, hero or any public-facing web page, in any stack (HTML\u002FCSS, React, Next.js, Vue, Svelte, Astro, Tailwind) — also when the user says a page looks generic, templated, \"AI-made\", sloppy, or asks to make it look designed, premium, award-level or less like every other site. Not for dashboards or app screens.","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Ftaste-design\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Ftaste-design\u002FSKILL.md",[],[],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":70,"publishedAt":19},"01M7EWY8FQFNQ2GB7NZZWGSSDX","test-driven-development","Use when implementing any feature or bugfix, before writing implementation code","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fsuperpowers-tdd\u002FSKILL.md",[],[],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":19},"01M7EWY5SHBFRH1HDHVWM9K7TV","systematic-debugging","Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fsuperpowers-debugging\u002FSKILL.md",[],[],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":19},"01M7EWY3NM0Z0JAKS7HDZ24K66","requesting-code-review","Use when completing tasks, implementing major features, or before merging to verify work meets requirements","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fsuperpowers-code-review\u002FSKILL.md",[],[],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":19},"01M7EWY0WRMWX4M9ZFY0WKC593","brainstorming","You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fsuperpowers-brainstorming\u002FSKILL.md",[],[]]