メニュー
召集四方会议处理模糊决策、权衡取舍及继续/停止决策。当存在多个有效路径且需要在选择前进行结构化异议时使用。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Build a fully automated AI-powered data collection agent for any public source — job boards, prices, news, GitHub, sports, anything. Runs on a schedule, enriches data with a free LLM (Gemini Flash), stores results in Notion/Sheets/Supabase, and learns from user feedback. Runs 100% free on GitHub Actions. Use when the user wants to monitor, collect, or track any public data automatically.
Open plans and HTML artifacts in a local browser canvas where the human annotates elements, chats, and approves or requests changes without leaving the page. Use when presenting a plan for review, or when feedback like "move this, change that" is easier pointed at than typed.
Open plans and HTML artifacts in a local browser canvas where the human annotates elements, chats, and approves or requests changes without leaving the page. Use when presenting a plan for review, or when feedback like "move this, change that" is easier pointed at than typed.
Instinct-based learning system that observes sessions via hooks, creates atomic instincts with confidence scoring, and evolves them into skills/commands/agents. v2.1 adds project-scoped instincts to prevent cross-project contamination.
基于本能的学习系统，通过钩子观察会话，创建带置信度评分的原子本能，并将其进化为技能/命令/代理。v2.1版本增加了项目范围的本能，以防止跨项目污染。
任意の自動コンパクションではなく、タスクフェーズを通じてコンテキストを保持するための論理的な間隔での手動コンパクションを提案します。
| name | council |
| description | 召集四方会议处理模糊决策、权衡取舍及继续/停止决策。当存在多个有效路径且需要在选择前进行结构化异议时使用。 |
| origin | ECC |
在模糊决策时召集四位顾问：
这适用于模糊性下的决策制定，而非代码审查、实施规划或架构设计。
在以下情况使用顾问团：
示例：
| 不应使用顾问团的情况 | 应使用 |
|---|---|
| 验证输出是否正确 | santa-method |
| 将功能拆解为实施步骤 | planner |
| 设计系统架构 | architect |
| 审查代码中的错误或安全漏洞 | code-reviewer 或 santa-method |
| 直接的事实性问题 | 直接回答 |
| 明确的执行任务 | 直接执行 |
| 声音 | 视角 |
|---|---|
| 架构师 | 正确性、可维护性、长期影响 |
| 怀疑论者 | 质疑前提、简化、打破假设 |
| 实用主义者 | 交付速度、用户影响、运营现实 |
| 批评者 | 边缘情况、下行风险、失败模式 |
三个外部声音应作为全新子代理启动，仅提供问题和相关上下文，而非完整对话历史。这是反锚定机制。
将决策简化为一个明确提示：
如果问题模糊，在召集顾问团前先提出一个澄清性问题。
如果决策与代码库相关：
如果决策是战略/通用性的：
在阅读其他声音之前，写下：
先完成此步骤，以确保综合意见不会简单镜像外部声音。
每个子代理获得：
提示模板：
你是四声部决策委员会中的[角色]。
问题：
[决策问题]
背景：
[仅包含相关片段或约束条件]
回复格式：
1. 立场 — 1-2句话
2. 理由 — 3个简洁要点
3. 风险 — 你建议中最大的风险
4. 意外点 — 其他声部可能忽略的一个方面
直接明了，不要含糊。控制在300字以内。
角色重点：
你既是参与者也是综合者，因此需遵循以下规则：
使用以下输出格式：
## 委员会：[简短决策标题]
**架构师：** [1-2句立场陈述]
[1行理由说明]
**怀疑论者：** [1-2句立场陈述]
[1行理由说明]
**实用主义者：** [1-2句立场陈述]
[1行理由说明]
**批评者：** [1-2句立场陈述]
[1行理由说明]
### 裁决
- **共识点：** [各方达成一致之处]
- **最大分歧：** [最重要的争议点]
- **前提检验：** [怀疑论者是否质疑了问题本身？]
- **建议方案：** [综合后的行动路径]
确保在手机屏幕上可快速浏览。
不要从此技能向 ~/.claude/notes 或其他隐藏路径写入临时笔记。
若顾问团实质性改变了建议：
knowledge-ops 将经验教训存储在正确的持久化位置/save-session（若结果属于会话记忆）仅在决策改变实际内容时进行持久化。
默认为一轮。
若用户要求另一轮：
santa-method — 对抗性验证knowledge-ops — 正确持久化重要决策变更search-first — 在顾问团前收集外部参考资料（如需要）architecture-decision-records — 当决策成为长期系统策略时正式化结果问题：
我们现在应该以 alpha 版本发布 ECC 2.0，还是等到控制平面 UI 更完善后再发布？
可能的顾问团形态：
价值不在于达成一致。价值在于在选择前让分歧清晰可见。