[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70FRGMP22WB6ZT07Z3FVZXM":3,"skill-same:01M70FRGMP22WB6ZT07Z3FVZXM":65},{"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":23,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":6,"ownerDescription":49,"updatedAt":50,"install":51,"resources":64},"01M70FRGMP22WB6ZT07Z3FVZXM","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.","mdnaimul22\u002Fhuman-skills","mdnaimul22","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F64520358?v=4","01M70FH95MH2H796Q01TYSFZ03","Naimul","01M70FH96798CQR4YHA13F17GA",3,"MIT","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Faffaan-m_ECC\u002Fcouncil\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35],"when","you","valid","paths","ambiguous","go","for","calls","use","decisions","voice","structured","2026-11-10 10:12:30",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":41,"description":7},{"origin":42},"ECC","main","74715deacdc69119d739f38916f8ee4f0f979ebf","skills\u002Fstorage\u002Faffaan-m_ECC\u002Fcouncil",0,"https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills","https:\u002F\u002Fgithub.com\u002Fmdnaimul22","AI Agents Workflows Automation | Specializing in Python, FastAPI, MCP Agents & Custom ERP.","2026-11-11 21:16:57",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add mdnaimul22\u002Fhuman-skills --skill council",{"tool":57,"command":58},"bunx","bunx skills add mdnaimul22\u002Fhuman-skills --skill council",{"tool":60,"command":61},"pnpm","pnpm dlx skills add mdnaimul22\u002Fhuman-skills --skill council","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Faffaan-m_ECC\u002Fcouncil\u002FSKILL.md",true,[],[66,74,100,120,139,154],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":73},"01M72JT3YP1SQHD0MANGDXQ4RT","higgsfield-websites","Build, edit, and deploy full-stack websites, apps and games via the Higgsfield CLI (`higgsfield website …`). Each is a React 19 + TanStack Start SSR app in one Cloudflare Worker (D1\u002FR2\u002FKV\u002FDO\u002FContainers). THREE product types, picked via `--type` on create: `website` (standalone, no Higgsfield integration — references\u002Fwebsite-flow.md), `app` (Sign in with Higgsfield + fnf SDK, Quanta — references\u002Fapp-flow.md), `game` (realtime multiplayer rooms — references\u002Fgame-flow.md). Routes to the right flow; each carries its own rules and deploy\u002Fpublish gates.\nUse when: \"build me a website\", \"make a landing page\", \"create a web app\", \"build a SaaS dashboard \u002F portfolio\", \"make me a game\", \"deploy this site\", \"publish\". Also owns GAME ART: \"make a spritesheet\", \"tileable texture\", \"animate a 3D character\", game music\u002FSFX — see the game-* references.\nNOT for: single image\u002Fvideo\u002Faudio generation (higgsfield-generate), product photos (higgsfield-product-photoshoot), marketplace cards (higgsfield-marketplace-cards).","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fhiggsfield-ai_skills\u002Fhiggsfield-websites\u002FSKILL.md",[],[],"2026-11-10 22:39:42",{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":92,"publishedAt":36},"01M70JPK8HAXXA85P7Q8NKZZYG","writing-skills","Use when creating new skills, editing existing skills, or verifying skills work before deployment","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fwriting-skills\u002FSKILL.md",[80,83,88,89],{"categoryNo":81,"categoryName":82,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":90,"categoryName":91,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[93,94,95,96,32,97,98,24,99],"writing","writing skills","editing","deployment","Existing","new","work",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":111,"publishedAt":36},"01M70JP4PHBH1CQVVDWZ94W159","writing-plans","Use when you have a spec or requirements for a multi-step task, before touching code","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fwriting-plans\u002FSKILL.md",[106,107,108],{"categoryNo":81,"categoryName":82,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},{"categoryNo":109,"categoryName":110,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000030","开发工程师",[93,112,113,25,24,114,30,32,115,116,117,118,119],"writing plans","plans","code","requirements","task","multi","spec","multi-step task",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":36},"01M70JNTYVGXFZT8PASZ844TH8","verification-before-completion","Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fverification-before-completion\u002FSKILL.md",[],[127,128,129,130,131,132,32,133,134,135,24,136,99,137,138],"verification","verification before completion","complete","about","output","assertions","prs","evidence","claim","claims","commands","running",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":146,"publishedAt":36},"01M70JNGVSQDESWN0Q5BPJ875V","using-superpowers","Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fusing-superpowers\u002FSKILL.md",[145],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[147,148,149,150,32,24,151,152,153],"using superpowers","superpowers","conversation","how to","how","find","questions",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":36},"01M70JN57CE588NPYPYTWH1DWG","using-git-worktrees","Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fusing-git-worktrees\u002FSKILL.md",[],[161,162,163,164,165,166,24,99,167,168,169,170,171,172,173,113,32,174,175],"using git worktrees","Using git","git","worktrees","git worktrees","implementation","git worktree","worktree","native","Tools","isolation","fallback","feature","via","workspace"]