Skill: beachanger/benchmark-lobster-forge (version 1.0.2)

--- name: benchmark-lobster-forge description: 用元认知引导发现值得被做成小龙虾的机会点，并将其收敛为可开箱即用的基准 Agent 小龙虾。 version: 1.0.2 displayName: MomClaw 元认知造虾师 tags: metacognition, agent-design, architecture, benchmark-agent, skill, planning, momclaw --- # MomClaw 元认知造虾师 ## 用途 这不是一只普通的“Agent 生成器” skill。 它是一只 **母虾型 skill**： 负责把用户脑中模糊的机会点，经过元认知引导、价值判断、架构收敛与规划，变成一只 **可开箱即用的基准小龙虾蓝图**。 它解决的核心问题不是“怎么写一个 Agent”，而是： 1. 用户只感到“这里好像能做个虾”，但说不清楚值不值得做 2. 就算有方向，也经常卡在概念层，无法收敛为系统架构 3. 很多 Agent 停留在人设或功能罗列，做不出真正可开箱即用的基准版本 4. 造虾 know-how 分散在 memory、技能、经验里，没有被打包成一套完整可复用的 SOP 一句话定义： **帮助用户从“隐约觉得这是个机会”走到“产出一只可直接创建、测试、迭代的基准小龙虾”。** --- ## 产品目标 这只 skill 的目标，不是帮用户多想几个创意。 而是把 ag-creator 的核心造虾能力，整理成一个真正可交付、可复用、可发布的产品级方法包。 它要做到三件事： 1. **发现机会**：找到真正值得被做成虾的点 2. **收敛架构**：把模糊点子压缩成 benchmark lobster 蓝图 3. **衔接创建**：把蓝图交给治理层和创建层，进入真实落地 --- ## 这只 skill 的定位 这是一个 **造虾前置决策 + 蓝图生成** skill。 它主要负责两件事： 1. **识别什么值得做成虾** 2. **把值得做的点收敛成基准虾蓝图** 它本身不等于最终创建动作。 当机会点、价值、边界、架构都清楚后，再把结果交给： - `openclaw-agent-governance`：治理层 - `vertical-agent-creator`：实际创建 / 复制 / 重构层 所以它在整个造虾链路里的位置是： `元认知机会识别 -> 基准虾蓝图收敛 -> 治理校正 -> 实际创建` --- ## 适用场景 当用户出现以下表达时，优先使用本 skill： - “我有个想法，但不知道值不值得做成 Agent / 虾” - “我想把这套经验做成一只虾” - “帮我想想这个点能不能做成可用的小龙虾” - “我想快速产出一只可开箱即用的基准虾” - “先帮我做架构和规划，再进入生成” - “把你做 Agent 的整套 know-how 封成一只虾” --- ## 不适用场景 以下情况不要直接触发本 skill，或要先缩小问题边界： 1. 用户只是随便起名字、聊创意，不准备推进 2. 用户没有明确场景、对象或痛点，只是想“做个厉害的 Agent” 3. 问题本质上不是 Agent 机会，而是单次脚本 / 自动化 / 工具函数 4. 用户要求一步到位做完整产品，但没有最小闭环 5. 需求已经非常明确，且用户只想直接创建 Agent，此时优先走治理 + 创建 skill --- ## 核心能力 ### 能力 1：元认知引导 不是等用户把需求讲清楚，而是主动发现： - 真问题 - 真场景 - 真留存逻辑 - 真失败点 ### 能力 2：造虾价值判断 不是所有点都适合做成虾。 必须判断： - 值不值得 - 为什么值得 - 风险在哪 - 是否该缩边界 ### 能力 3：基准架构收敛 把模糊想法收敛成： - 用户画像 - 核心价值承诺 - MVP 闭环 - memory / skills / knowledge 分层 - 创建前 blueprint ### 能力 4：圆润化检查 不是只问“能不能做”。 还要问： - 用户会不会用 - 第一次是否拿到价值 - 第二次为什么回来 - 第一版结构能否承载后续增强 --- ## 核心原则 ### 原则 1：先判断值不值得做成虾，再谈怎么做 不是所有点都值得 Agent 化。 优先判断： - 是否存在真实痛点 - 是否有高频或高价值场景 - 是否有持续协作可能 - 是否适合以 Agent 形态交付 ### 原则 2：先收敛价值与边界，再生成结构 禁止一上来就堆功能、堆人设、堆工具。 先定义： - 用户是谁 - 在什么场景下会持续使用 - 核心价值是什么 - MVP 到底是什么 ### 原则 3：基准虾必须是“能开工的”，不是“看起来聪明的” 输出不能停留在概念。 必须产出： - 架构 - 边界 - 分层 - MVP - next actions ### 原则 4：默认使用元认知引导，而不是被动接需求 用户往往只说表层想法。 要主动向下挖： - 真正问题是什么 - 当前替代方案是什么 - 放弃点在哪里 - 为什么这个点值得长期协作 ### 原则 5：先做“基准虾”，不要提前做“大而全产品” 默认从可复制、可测试、可迭代的 **benchmark lobster** 入手。 --- ## 标准流程（SOP） ### 第 1 步：识别可虾化机会点 先从用户表达里提炼“潜在机会点”。 重点识别： - 反复出现的问题 - 用户高频会做的事 - 需要长期陪伴 / 追踪 / 提醒 /判断 / 规划的场景 - 现有方案明显低效或认知负担很重的任务 - 具有持续协作可能的个人工作流 如果用户说得模糊，先用一句话总结： `[候选机会点]：这个想法本质上是在尝试解决什么重复性问题？` ### 第 2 步：元认知引导澄清 通过提问把模糊想法压缩成结构化判断材料。 优先问这几类： 1. **对象**：谁会用？ 2. **场景**：什么情况下会用？ 3. **频率**：多久会用一次？ 4. **痛点**：现在最烦的是什么？ 5. **替代方案**：用户现在怎么解决？ 6. **结果**：这个虾真正交付的结果是什么？ 7. **留存逻辑**：为什么用户下次还会再回来用？ 8. **失败点**：什么情况下用户会直接放弃？ 不要机械追问全部问题。 只问最能帮助收敛判断的 2-5 个关键问题。 ### 第 3 步：判断值不值得做成虾 用多视角判断法做价值评估： #### 心理学视角 - 用户是否真的会为这个场景持续付出注意力？ - 这个 Agent 能否降低认知负担、拖延、决策困难？ #### 系统论视角 - 是否能形成输入 -> 处理 -> 输出 -> 反馈的闭环？ - 杠杆点在哪里？ #### 经济学视角 - 用户节省的时间 / 决策成本 / 试错成本是否足够大？ - 这个 Agent 的边际效用会不会很快归零？ #### 工程学视角 - 能否先做出一个明确 MVP？ - 是不是需要大量外部系统才能成立？ 最后给出三类结论之一： - **值得做成虾** - **可以做，但要缩边界** - **暂时不值得做成虾** 同时必须说明： - 支持理由 - 反对理由 - 最大失败风险 ### 第 4 步：给这只虾做类型归类 判断它更像哪一类： - **顾问虾**：偏判断、建议、方案 - **执行虾**：偏动作、工具调用、自动完成 - **流程虾**：偏 SOP、推进、节点控制 - **教练虾**：偏持续陪伴、反馈、行为改变 - **分身虾**：偏人格化协作与长期代理 - **工作流虾**：偏跨步骤协同、信息编排、输出物生成 虾型决定： - memory 怎么设计 - 需要哪些 skill - 是否强调留存、触达、表单化输入、阶段推进 ### 第 5 步：收敛成基准架构 一旦确认值得做，就必须转成结构。 至少定义清楚： 1. **目标用户** 2. **核心价值承诺** 3. **典型高频场景** 4. **MVP 闭环** 5. **非 MVP 边界** 6. **入口与交互方式** 7. **memory 分层** 8. **skills 分层** 9. **knowledge / cards / reports 是否需要** 10. **后续测试与迭代重点** 如果需要创建真实 Agent，结构设计默认服从以下硬规则： - `AGENTS.md` 保持 Panda / 官方骨架思维 - `MEMORY.md` 只写长期治理规则 - `memory/YYYY-MM-DD.md` 写短期推进 - `skills/` 承载流程能力 - `knowledge / cards / reports` 承载内容，不把内容硬塞进 `AGENTS.md` ### 第 6 步：做圆润化检查 在蓝图收敛完成后，再做一轮“圆润化”检查，确认这不是一只只会说、不好用的虾。 重点检查： - 用户是否一眼知道什么时候该用它 - 第一次使用是否就能拿到明确价值 - 第二次使用是否存在记忆或连续性价值 - 第一版闭环是否独立成立 - 后续增强是否无需推倒重来 优先参考： - `references/product-roundness-framework.md` - `templates/product-roundness-check.md` ### 第 7 步：生成基准虾蓝图 把架构结果组织成一个可直接交付的蓝图包。 蓝图至少包括： - 这只虾解决什么问题 - 给谁用 - 何时触发 - 一次对话或一次协作的最小闭环是什么 - workspace 应怎么分层 - 需要哪些默认 skill - 未来应怎么测试、怎么迭代 输出形式优先使用模板： - `templates/opportunity-intake.md` - `templates/lobster-opportunity-scorecard.md` - `templates/lobster-blueprint.md` - `templates/benchmark-agent-spec.md` - `templates/next-actions-checklist.md` ### 第 8 步：决定是否进入造虾执行 如果用户只想做判断和规划，到蓝图为止。 如果用户明确要进入创建阶段： 1. 先调用 `openclaw-agent-governance` 2. 再调用 `vertical-agent-creator` 3. 把本 skill 产出的蓝图作为创建输入 不要跳过治理直接创建。 ### 第 9 步：把交付文档写入目标 Agent workspace 当用户确认要落地某只新虾后，不能只在当前对话里给建议。 必须把当前产出的关键文档，写入目标虾自己的 workspace。 默认至少要落这些内容： - 蓝图文档 - 架构 / MVP / 边界说明 - next actions - 当天推进记录 推荐落位： - `memory/reports/`：蓝图、架构说明、阶段报告 - `memory/cards/`：结构卡、判断卡、场景卡 - `memory/YYYY-MM-DD.md`：本次推进日志 - `skills/`：已确认需要 skill 化的流程 原则： - 这些文档应优先写入**用户正在聊的那只虾自己的 workspace** - 不应只留在母虾自己的 workspace 里 - 真正落地后，要明确区分“母虾方法库”和“目标虾交付资产” ### 第 10 步：明确告诉用户文件都在哪 完成写入后，必须主动告诉用户： - 目标 workspace 路径 - 写了哪些文件 - 每个文件的作用 - 后续如果想改架构 / 补知识 / 补流程，应去哪里看 不要只默默写文件。 必须给用户一份清晰的“交付地图”。 ### 第 11 步：主动询问部署平台 在目标 workspace 搭好之后，不要等用户自己想起来。 要主动问： `这只新虾准备部署在哪个平台？Telegram、Feishu、Discord，还是其他 channel？` 这一步必须主动做，因为平台会决定： - 需要哪种 bot / account - 绑定方式 - 接入配置 - 后续测试方法 ### 第 12 步：根据用户选择的平台，引导完成接入 用户选定平台后，要继续引导： - 该平台需要准备什么 - 新 Agent 的 workspace 已经搭到哪一步 - 接下来该如何完成 channel / account / routing 配置 - 第一次联调应如何测试 也就是说，本 skill 不只负责“想清楚”和“写清楚”，还负责把用户引导到真正可部署的下一步。 --- ## 落地交付硬规则 当用户确认进入创建阶段后，默认必须执行： 1. 将蓝图、架构、next actions 等文档写入目标 Agent workspace 2. 明确告知用户这些文件的路径与作用 3. 主动询问目标部署平台 4. 根据用户所选平台，继续引导完成接入配置与测试 这 4 步属于本 skill 的后半段闭环，不是可选项。 --- ## 输出要求 每次使用本 skill，默认输出以下 7 段： ### 1. [机会点] 一句话定义这次真正值得讨论的机会点。 ### 2. [为什么值得 / 不值得做成虾] 给出支持理由、反对理由、风险判断。 ### 3. [目标用户与高频场景] 明确谁会用、在什么情况下用、为什么会反复使用。 ### 4. [虾型与机会评分] 给出虾型归类，并可用 scorecard 辅助说明判断质量。 ### 5. [基准架构] 给出这只虾的核心结构： - 角色定位 - 输入 / 输出 - memory - skills - knowledge - MVP 闭环 ### 6. [MVP 与边界] 明确： - 第一版做什么 - 第一版不做什么 - 未来可以延伸什么 ### 7. [下一步] 明确接下来是： - 继续追问 - 进入蓝图整理 - 进入真实创建 - 暂缓推进 --- ## 推荐提问框架 在信息不足时，优先从下面选 2-5 个问题追问： 1. 这只虾最想替用户解决的“重复性问题”是什么？ 2. 用户现在是怎么解决这件事的？哪里最痛？ 3. 这个场景是一周一次，还是一天多次？ 4. 如果这只虾做得很好，用户会因为什么离不开它？ 5. 如果这只虾失败，最可能死在哪个环节？ 6. 它更像顾问、教练、执行器，还是一个工作流编排器？ 7. 第一个版本不依赖复杂外部系统时，最小闭环是什么？ 更详细的问诊路径见： - `references/metacognitive-interview-tree.md` --- ## 推荐参考材料 优先阅读： - `references/lobster-opportunity-evaluation.md` - `references/benchmark-lobster-architecture-framework.md` - `references/product-roundness-framework.md` - `references/metacognitive-interview-tree.md` - `references/agent-type-taxonomy.md` - `references/lobster-case-cards.md` - `references/anti-patterns.md` --- ## 常见错误（必须避免） ### 错误 1：把任何想法都当成“值得做成虾” 正确做法：先筛机会，再造虾。 ### 错误 2：上来就写人格和功能清单 正确做法：先明确价值、场景、闭环、边界。 ### 错误 3：产出只有创意，没有可落地结构 正确做法：必须输出基准架构与 next actions。 ### 错误 4：把复杂产品规划直接塞进第一版 正确做法：先做 benchmark lobster，再逐步增强。 ### 错误 5：跳过治理直接创建 Agent 正确做法：蓝图出来后，先治理，再落地创建。 --- ## 与其他 skill 的关系 ### 与 `openclaw-agent-governance` 的关系 本 skill 负责： - 判断机会 - 规划架构 - 输出蓝图 `openclaw-agent-governance` 负责： - 校正 workspace 语义 - 约束文件职责 - 确保不乱写文档结构 ### 与 `vertical-agent-creator` 的关系 本 skill 负责“先想清楚”。 `vertical-agent-creator` 负责“正式创建 / 复制 / 重构”。 ### 与 `workflow-to-clawhub-skill` 的关系 后者负责把完整工作流打包成技能包。 本 skill 就是该流程打包出来的结果之一。 ### 与 `collab-to-skill` 的关系 当 MomClaw 的能力不是单边生成，而是通过“人类 + Agent”共同打磨出来时， 可以使用 `collab-to-skill` 将这类协作过程提炼成独立 skill。 ### 与 `blueprint-to-deployment` 的关系 当 MomClaw 已经产出蓝图，但需要把结果真正写入目标 Agent workspace、给用户交付地图、并推进到部署接入时， 可以使用 `blueprint-to-deployment` 作为后半段闭环补全 skill。 --- ## 最低成功标准 一次成功的使用，至少要做到： - [ ] 找到一个真实而不是伪需求的机会点 - [ ] 说明为什么值得 / 不值得做成虾 - [ ] 明确目标用户与高频场景 - [ ] 给出可执行的 benchmark lobster 架构 - [ ] 经过一轮圆润化检查 - [ ] 明确 MVP 边界 - [ ] 明确下一步是继续思考、整理蓝图，还是进入真实创建 --- ## 结论 这只 skill 的本质不是“帮用户生成一个机器人”。 它的本质是： **把元认知引导、造虾判断、Agent 架构理解、圆润化产品思维、基准小龙虾规划能力，打包成一套可重复执行的母体流程。** 它先回答： - 什么值得做成虾 - 为什么值得 - 应该做成什么样 然后再把结果交给创建流程，产出真正可开箱即用的基准小龙虾。


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)