Menú
De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.
Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Un comando directo omite el prompt de revisión. Revisa el origen antes de ejecutarlo.
npx skills add https://github.com/mturac/everything-openai-codex --skill councilEl comando permanece en una sola línea. Desplázate horizontalmente para revisarlo antes de copiarlo.
¿Prefieres una copia local? Descarga los archivos que SkillsMP tiene disponibles ahora.
Mostrando SKILL.md
Use this skill to monitor and verify a deployed URL or public OSS launch surface after releases — checks HTTP endpoints, SSE streams, static assets, console errors, performance regressions, PR queue health, maintainer feedback, and listing-review blockers after deploys, merges, submissions, or dependency upgrades. Smoke / canary / post-deploy / PR-watch verification.
Build reputation-safe open-source marketing from verifiable project evidence, not hype, spam, or repeated public pings. Use for launch copy, directory targeting, community posts, proof packets, and maintainer-facing positioning.
Turn public launch, directory, community, or list rejections into repo fixes and better proof without arguing, spamming, or resubmitting blindly. Use after Hacker News, Product Hunt, GitHub list PR, marketplace, or community rejection.
Basado en la clasificación ocupacional SOC
| 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行理由说明]
### 裁决
- **共识点：** [各方达成一致之处]
- **最大分歧：** [最重要的争议点]
- **前提检验：** [怀疑论者是否质疑了问题本身？]
- **建议方案：** [综合后的行动路径]
确保在手机屏幕上可快速浏览。
不要从此技能向 ~/.codex/notes 或其他隐藏路径写入临时笔记。
若顾问团实质性改变了建议：
knowledge-ops 将经验教训存储在正确的持久化位置/save-session（若结果属于会话记忆）仅在决策改变实际内容时进行持久化。
默认为一轮。
若用户要求另一轮：
santa-method — 对抗性验证knowledge-ops — 正确持久化重要决策变更search-first — 在顾问团前收集外部参考资料（如需要）architecture-decision-records — 当决策成为长期系统策略时正式化结果问题：
我们现在应该以 alpha 版本发布 ecc 2.0，还是等到控制平面 UI 更完善后再发布？
可能的顾问团形态：
价值不在于达成一致。价值在于在选择前让分歧清晰可见。