# sixhat-skill **Repository Path**: solar86/sixhat-skill ## Basic Information - **Project Name**: sixhat-skill - **Description**: 六顶思考帽的AI skill - **Primary Language**: Unknown - **License**: MIT - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2026-10-28 - **Last Updated**: 2026-10-29 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # sixhat-skill · 六顶思考帽（WorkBuddy 技能包） > 把 [sixhat](../sixhat) 的核心方法论做成一个 **WorkBuddy 技能**，投放到 WorkBuddy 技能市场。 > **零凭证、零外部依赖**：用 WorkBuddy 自己的模型演六顶帽子，脚本只做确定性的聚合。 ``` sixhat-skill/ ├── six-thinking-hats/ ← 技能本体（这就是要上传的 zip 的内容） │ ├── SKILL.md ← 技能定义（frontmatter + 执行指令） │ ├── references/ ← 知识：角色契约 / 编排 / 数据结构 / 简报格式 │ ├── scripts/sixhat.mjs ← 确定性内核（init / save / build / show / status / ask / answer） │ ├── templates/ ← 两份 JSON 模板 │ └── examples/ ← 三个完整跑通的例子 ├── tools/ │ ├── selftest.mjs ← 端到端自检（63 项断言） │ ├── lint-skill.mjs ← SKILL.md frontmatter 检查（打包前必过） │ ├── build-zip.mjs ← 打包成上传用 zip（零依赖 ZIP 写入器） │ └── verify-zip.py ← 压缩包与源码逐文件 sha256 比对 └── dist/ ← 打包产物（git 忽略） ``` --- ## 一、这是什么 用户说"我要不要接这个 Offer"，技能会： 1. 让 **六顶帽子**按固定八阶段开一场会（⚪白 → 🟢绿 → 🟡黄‖⚫黑 → 🔴红 → ⚫黑攻 → 🟡黄守 → 🔵蓝收敛） 2. 黄帽与黑帽**正面对撞**（不许合并成"利弊分析"） 3. 每顶帽子交一份**结构化 JSON** 4. 脚本据此算出**分歧矩阵 / 未解问题 / 盲区**，渲染成决策简报 + 六宫格 **它不产出答案，产出分歧结构。** 谁和谁在吵、哪些没解决、哪些维度没人提过——剩下的判断权还在用户手里。 ### v1.2.0 新增：六宫格文件 原项目的六宫格是 React 组件（技能没有 UI）。现在落成两个文件，`build` 时自动生成： | 文件 | 用途 | |---|---| | `six-grid.md` | 6 行 markdown 表格，直接贴进对话 | | `six-grid.html` | 2×3 网格，自带样式，浏览器直接打开 | 带 PRD §3.4 要求的**无障碍三重编码**（颜色 + emoji + 边框形状），参与的帽子在格子左边缘有冲突色条。 HTML 版用 Chrome headless 实测渲染通过。 ### v1.1.0 新增：交互式补充信息 白帽发现"缺了这条信息结论会翻面"时，会**停下来向提问者追问**（最多 3 条）， 拿到答案后让白帽重跑一轮再继续。补齐信息不是为了消灭分歧，是为了让分歧**长在事实上**，而不是长在假设上。 WorkBuddy 的技能没有表单/弹窗机制（开放平台里唯一能渲染表单的是连接器的凭证表单）， 所以交互手段就是**对话本身**：Agent 提问 → 结束本轮回复 → 等用户回答 → 下一轮接着跑。 状态全部落在运行目录的磁盘上，跨轮不靠记忆。 ```bash node scripts/sixhat.mjs ask --run <目录> # 取出要问用户的问题 node scripts/sixhat.mjs answer --run <目录> --file ans.json # 记录用户的回答 node scripts/sixhat.mjs status --run <目录> # 现在到哪了、下一步干什么 ``` 完整走一遍见 [`examples/example-clarification.md`](six-thinking-hats/examples/example-clarification.md)。 --- ## 二、为什么不做成"脚本调外部 LLM" 原项目 `sixhat` 的编排引擎会调 MiniMax-M3 的 API。但**WorkBuddy 技能不带模型额度**： - 执行技能的是 WorkBuddy 自己的助手，跑在**用户自己的账号**上； - 开放平台文档里唯一的凭证流程在「连接器」章节，且明确写着**凭证由用户自填、不得写进技能包**。 所以如果技能内置调外部大模型，就等于要求每个用户自己配 API key——把绝大多数人挡在门外。 **本技能的做法**：模型部分交给 WorkBuddy 的助手（用 `references/hat-prompts.md` 里的角色契约驱动）， **脚本只做模型做不好的确定性计算**： | 谁做 | 做什么 | 为什么 | |---|---|---| | WorkBuddy 的模型 | 扮演六顶帽子、写发言、写结构化 JSON | 它本来就是最强的通用模型 | | `scripts/sixhat.mjs` | 校验 JSON、构建分歧矩阵、盲区覆盖判定、渲染简报 | 这些必须是**确定性计算**——让模型自由发挥，它就会写成"利弊各有" | --- ## 三、技能规范（依 WorkBuddy 开放平台 `/docs/skill`） ### frontmatter（8 个必填字段全部齐备） ```yaml name: six-thinking-hats display_name: 六顶思考帽 display_name_en: Six Thinking Hats description: ... # 用途 + 触发词，195 字（上限 1024） description_zh: ... description_en: ... allowed-tools: Bash, Read, Write version: 1.0.0 examples_zh: [...] # 详情页「试试这样用」 examples_en: [...] author: "solar86" ``` ### 目录结构（与官方规范一致） ``` {skill-name}/ ├── SKILL.md ★ 必需 ├── references/ 参考资料（AI 执行时按需读取） ├── scripts/ 可执行脚本（AI 通过 Bash 调用） └── templates/ 模板文件 ``` > ⚠ 注意：**官方规范里没有 `assets/`**，模板目录叫 `templates/`。 > 另外 CodeBuddy 市场（`~/.codebuddy/skills-marketplace`）的校验器只允许 5 个 frontmatter 键， > 与 WorkBuddy 官方规范**不一致**——本项目**以 WorkBuddy 官方规范为准**。 --- ## 四、开发 ```bash # 端到端自检（造一场假讨论跑完整管线 + frontmatter 检查，49 项断言） node tools/selftest.mjs # 单独检查 SKILL.md 的 frontmatter node tools/lint-skill.mjs # 打包 → dist/six-thinking-hats-1.0.0.zip（frontmatter 不过则拒绝打包） node tools/build-zip.mjs # 确认压缩包与源码逐文件一致 python tools/verify-zip.py ``` ### ⚠ frontmatter 的 YAML 坑（踩过一次） 第一次上传开放平台失败，报： ``` Nested mappings are not allowed in compact mappings at line 6, column 17 ``` 原因是 `description_en` 的值里有 `Six Thinking Hats: run a six-role…`—— **YAML 的未加引号纯量不能含 `": "`**，解析器会把冒号后面当成一个新的嵌套映射。 这个错误**本地完全看不出来**：文件是纯文本，肉眼看着完全正常，只有 YAML 解析器才会炸。 所以固化了两道防线： - `tools/lint-skill.mjs` —— 检查每个值是否加引号、必填字段是否齐全、引号是否闭合； - `tools/build-zip.mjs` —— **打包前必过 lint**，坏掉的包不许离开这个仓库。 约定：**frontmatter 里所有字符串值一律加双引号**；值里要用引号就换成中文的「」。 脚本直接用： ```bash node six-thinking-hats/scripts/sixhat.mjs init --run ./runs/x --question "我要不要接这个 Offer？" node six-thinking-hats/scripts/sixhat.mjs save --run ./runs/x --hat white --round 1 --file w.json node six-thinking-hats/scripts/sixhat.mjs build --run ./runs/x node six-thinking-hats/scripts/sixhat.mjs show --run ./runs/x ``` **零依赖**：只用 Node 内置模块，Node ≥ 18。`scripts/sixhat.mjs` 不 import 任何第三方包。 --- ## 五、与原项目 `sixhat` 的关系 | | 原项目（Next.js 应用） | 本技能 | |---|---|---| | 形态 | 网页：SSE 流式 + 六宫格 UI + 决策简报 Tab | 技能：脚本聚合 + 文本交付 | | 模型调用 | 脚本调 MiniMax-M3（15 次/场，≈¥0.42） | **0 次额外调用**，用 WorkBuddy 自己的模型 | | 凭证 | `MINIMAX_API_KEY` | **不需要** | | 结构化输出 | strict tool（`output_config.format` 在 MiniMax 端无效、`tool_choice` 不可靠） | AI 写 JSON + 脚本校验（对 Claude/CodeBuddy 类模型足够可靠） | | 角色边界 | 靠 prompt + 调用 B 的结构化输出双重约束 | 靠 prompt + 脚本校验字段（**弱一档**，见下） | | 追问重答 | 未实现（PRD FR-5） | **已实现**（r3 轮次） | ### 有意做的两处改动 1. **盲区取并集**（原项目是二选一） 原项目 `deriveBlindspots`：蓝帽只要报了一条盲区，就完全不用系统按维度覆盖判定派生。 本技能改成 **蓝帽自报 ∪ 系统派生**——派生项是可复核的事实（关键词一个都没命中）， 丢掉它等于丢掉这个技能最有价值的确定性部分。 2. **六宫格取常规轮（r1）** 原项目踩过的坑 D-3：辩论轮把黑帽/黄帽的常规结论覆盖了。 本技能按轮次号取 `r1`，辩论轮（r2）与追问轮（r3+）单独列，**结构上不可能**再覆盖。 ### 已知的能力降级 - **没有实时流式**：原项目逐字冒泡 + 六宫格 UI 是产品体验的一半，技能形态天然是"跑完 → 交付文本"。 - **角色边界弱一档**：原项目靠"调用 A（自由发言）+ 调用 B（结构化）"两段式把散文和结构化分开， 结构化那段不经过发言的污染。技能形态下同一段上下文里既写散文又写 JSON，越界风险更高。 → 缓解手段：`scripts/sixhat.mjs save` 会做**角色越界软校验**（红帽出现"建议/方案"就告警）， 并在简报里保留每顶帽子的原文供人复核。 - **UI 层没有自动化测试**：这个仓库能测的是脚本与聚合逻辑；技能被 Agent 驱动的部分只能靠人工试用。 --- ## 六、上传到 WorkBuddy 技能市场 1. `node tools/build-zip.mjs` → 得到 `dist/six-thinking-hats-1.0.0.zip` 2. 开放平台 → 技能市场 → 右上角**【添加技能】→【创建技能】** 3. 按提示提交这个 zip 4. 解析失败时对照「技能基础结构」「子资源目录说明」自查；仍失败联系 `openworkbuddy@tencent.com` **上架前建议**：先在本地把 `six-thinking-hats/` 软链到 `~/.codebuddy/skills/` 或直接放进某个 WorkBuddy 工作区， 用真实问题跑一轮，确认「先分歧后共识、盲区念出来」这条呈现要求被执行到位。 --- ## 七、许可 MIT（与原项目 `sixhat` 一致）。 角色契约文字来自原项目 `lib/hats.ts`（源自 `artifacts/design/hat-prompts.md`）。