BeAChanger

---
name: blueprint-to-deployment
description: 将 Agent 规划结果补全为可交付、可部署的落地闭环。适用于把蓝图、架构、next actions 写入目标 Agent workspace，并主动推进到平台部署与接入引导。
version: 1.0.0
displayName: 落地鸿沟补全器
tags: skill, delivery, deployment, workspace, handoff
---

# 落地鸿沟补全器

## 用途

这只 skill 用来补全“从规划到可用 Agent”之间的鸿沟。

很多 Agent 流程会停在：
- 聊天里
- 方案里
- 蓝图里
- 看起来已经想清楚了

但没有真正完成：
- 文档落地
- workspace 归档
- 用户交付说明
- 部署平台追问
- 平台接入引导

本 skill 的目标，就是把这些缺口补上。

---

## 什么时候用

当你已经有：
- Agent 蓝图
- 架构规划
- MVP 边界
- next actions

但还没真正把它交到“目标 Agent 自己的 workspace”里，或还没推进到平台接入时，触发本 skill。

---

## 核心原则

1. **每只 Agent 都应拥有自己的资产**
2. **母 skill 保留方法论，目标 Agent 保留自己的交付资产**
3. **文档归属也是上下文管理**
4. **设计不能停留在聊天里**
5. **如果目标是可用，就必须主动推进到部署层**

---

## 标准流程

### 第 1 步：确认目标 Agent workspace
先确认目标 Agent 的 workspace 已存在，或即将被创建。

### 第 2 步：写入关键交付文档
默认至少写入：
- 蓝图文档
- 架构 / MVP / 边界说明
- next actions
- 当天推进记录

推荐落位：
- `memory/reports/`
- `memory/cards/`
- `memory/YYYY-MM-DD.md`
- `skills/`

### 第 3 步：给用户交付地图
明确告诉用户：
- workspace 路径
- 文件路径
- 每个文件的作用
- 后续怎么改、去哪里看

### 第 4 步：主动问部署平台
不要等用户自己问。
主动追问：
- Telegram
- Feishu
- Discord
- 其他 channel

### 第 5 步：按平台继续引导
根据用户选择的平台，说明：
- 需要什么 bot / app / account
- 需要哪些配置
- 如何做首次联调

---

## 为什么值得单独做成 skill

因为这不是某一只母虾私有的补丁，
而是所有“会产出蓝图”的 Agent / skill 都可能需要的后半段闭环能力。

它解决的问题不是“如何规划”，而是：
**如何避免规划停在纸面上。**

---

## 输出要求

至少交付：
1. 目标 workspace 已写入哪些内容
2. 这些文件分别在哪
3. 下一步该选哪个平台
4. 平台接入该怎么开始

---

## 反模式

- 只给聊天建议，不写文件
- 文档全留在主 Agent / 母 skill workspace
- 不告诉用户文件在哪里
- 不主动问平台
- 让流程停在“我们已经设计完了”

---
name: collab-to-skill
description: 将“人类 + Agent”共同打磨出来的流程、决策与方法，提炼成可复用的 Skill。适用于把高质量协作过程从聊天/项目推进中抽取出来，沉淀为可分发的技能包。
version: 1.0.0
displayName: 协作造技师
tags: skill, collaboration, extraction, metacognition, workflow
---

# 协作造技师

## 用途

这只 skill 用来把“共同打磨出来的能力”变成 skill。

它处理的不是单个 Agent 独立完成的能力，
而是以下这类协作产物：
- 人类先给方向、判断、反证与修正
- Agent 负责结构化、收敛、打包与落地
- 双方来回迭代后，形成一套稳定流程

这类能力如果不提炼，通常会散落在聊天记录里。
本 skill 的目标，就是把它们提纯成可复用、可发布、可迭代的 skill。

---

## 什么时候用

当你发现以下情况时，优先触发：
- 一个有价值的方法不是单边生成的，而是共同磨出来的
- 聊天过程中出现了多个关键决策点、边界修正、流程补全
- 你想把“这次是怎么做出来的”沉淀为下一次可直接复用的 skill
- 想验证：某个能力仅靠 skill 是否足够成立

---

## 核心原则

1. **协作过程本身就是资产**
2. **关键决策点比表面流程更值钱**
3. **先抽“为什么成立”，再抽“怎么执行”**
4. **能拆成独立 skill 就不要都塞进一个母 skill**
5. **Less is more：单一 skill 只承载一类清晰能力**

---

## 标准流程

### 第 1 步：识别协作成果
先确认本次成果是不是协作磨出来的，而不是普通对话输出。

### 第 2 步：抽关键决策点
优先抽：
- 中途新增了什么关键步骤
- 为什么要加
- 如果不加会怎样
- 这是否具备跨项目复用价值

### 第 3 步：提炼方法论骨架
把协作过程压缩成：
- 输入
- 关键判断
- 核心步骤
- 输出
- 边界

### 第 4 步：判断独立成 skill 还是并入母 skill
如果它是独立能力，就拆成单独 skill。
如果只是母流程的一小段，就并入母 skill。

### 第 5 步：打包 skill
输出：
- `SKILL.md`
- 必要的 references/
- 必要的 templates/

### 第 6 步：记忆沉淀
把“为什么这么设计”写进短期记忆；稳定后再升格长期记忆。

---

## 输出要求

至少交付：
1. 这次协作抽出了什么能力
2. 为什么值得 skill 化
3. 应拆成独立 skill 还是并入母 skill
4. skill 的边界与价值
5. 后续如何验证它是否真的成立

---

## 不要做的事

- 不要把完整聊天记录原样塞进 skill
- 不要只写步骤，不写决策原因
- 不要把多个不相干能力硬捏成一个 skill
- 不要把“还没稳定的方法”过早包装成发布版

---
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 架构理解、圆润化产品思维、基准小龙虾规划能力，打包成一套可重复执行的母体流程。**

它先回答：
- 什么值得做成虾
- 为什么值得
- 应该做成什么样

然后再把结果交给创建流程，产出真正可开箱即用的基准小龙虾。

FILE:README.md
# MomClaw 元认知造虾师

## What this skill does

MomClaw 元认知造虾师 is a metacognitive skill for turning vague ideas into launch-ready benchmark agents.

It helps the user:
1. identify whether an idea is worth turning into an agent,
2. clarify the real user value and usage scenario,
3. converge the idea into a benchmark architecture,
4. prepare a creation-ready blueprint for the next build step,
5. write the resulting docs into the target agent workspace,
6. actively ask which platform the new agent will be deployed to,
7. guide the user through channel/platform setup after the workspace is scaffolded.

## Best for

- agent opportunity discovery
- benchmark agent planning
- agent architecture scoping
- MVP boundary definition
- turning workflows into reusable agent blueprints
- handing off blueprint docs into the new agent workspace
- guiding post-workspace deployment setup

## Not for

- random brainstorming without intent to build
- one-off scripts that do not need an agent
- giant product plans without a minimum viable loop

## Package contents

- `SKILL.md`
- `references/`
- `templates/`

## Output style

This skill is designed to produce structured, actionable outputs instead of generic brainstorming.

FILE:references/agent-type-taxonomy.md
# 小龙虾类型划分

## 1. 顾问虾
适合：判断、建议、方案设计、策略分析。

## 2. 执行虾
适合：动作执行、调用工具、跑流程、完成任务。

## 3. 流程虾
适合：分阶段推进、SOP 驱动、节点检查。

## 4. 教练虾
适合：长期陪伴、行为改变、反馈、提醒、打卡。

## 5. 分身虾
适合：人格化代理、长期协作、替身沟通。

## 6. 工作流虾
适合：多步骤编排、信息整合、结构化输出物。

---

## 用法

先判断“主要价值来源”是什么，再定虾型。
虾型不是为了贴标签，而是为了决定：
- memory 怎么设计
- 是否强调长期留存
- 是否需要技能编排
- 输出更偏建议、执行还是持续推进

FILE:references/anti-patterns.md
# 反模式清单

## 1. 人设先行，结构缺席
症状：SOUL 很丰满，但没有闭环、没有边界、没有真实工作流。

## 2. 什么都想做
症状：第一版就想覆盖完整产品能力，导致无法启动。

## 3. 把 AGENTS.md 写成知识库
症状：根文件臃肿、上下文浪费、迁移困难。

## 4. 把一次性任务误判成长期 Agent 场景
症状：做出来后没有复用频次。

## 5. 没先判断是否值得做
症状：一股脑开始搭，最后只是概念玩具。

## 6. 跳过治理直接创建
症状：目录乱、职责乱、memory 乱、后续不可维护。

FILE:references/benchmark-lobster-architecture-framework.md
# 基准小龙虾架构框架

## 一、先定 5 个核心点

1. 目标用户是谁
2. 核心价值承诺是什么
3. 高频使用场景是什么
4. MVP 最小闭环是什么
5. 第一版明确不做什么

---

## 二、Agent 结构默认拆法

### 1. AGENTS.md
负责运行规则、读取顺序、群聊/私聊规则、安全边界、memory 使用方式。

### 2. SOUL.md
负责人格、表达气质、价值观。

### 3. MEMORY.md
负责长期治理决策、稳定偏好、长期方法论。

### 4. memory/YYYY-MM-DD.md
负责当天推进、测试、临时发现、候选结论。

### 5. skills/
负责流程、SOP、可复用执行能力。

### 6. memory/knowledge, cards, reports
负责知识、结构卡、测试报告、反馈归档。

---

## 三、MVP 闭环检查

一个基准虾至少要回答：

1. 用户怎么触发它？
2. 它拿到输入后怎么判断？
3. 它输出的最小价值是什么？
4. 为什么用户下次还会继续用？
5. 它如何通过 memory 或 skill 形成长期复利？

---

## 四、默认设计偏好

- 小而闭环，优先于大而空泛
- skill 承载流程，优先于 AGENTS.md 膨胀
- knowledge 承载内容，优先于把知识塞进人格文件
- 先有 benchmark 版，再逐步扩展

FILE:references/lobster-case-cards.md
# 造虾案例卡（public-safe）

## 案例 1：把模糊灵感变成顾问虾

### 原始想法
“我想做一个能帮我想事情的 Agent。”

### 收敛后机会点
不是“想事情”，而是“在关键决策时提供结构化判断与反视角压力测试”。

### 适合的虾型
顾问虾 + 工作流虾

### MVP
- 用户抛出一个决策问题
- Agent 输出：关键价值点、反视角、风险、next actions

---

## 案例 2：把重复推进工作做成流程虾

### 原始想法
“我想做一个能帮我推进项目的 Agent。”

### 收敛后机会点
核心不是泛化项目管理，而是“帮助用户把模糊目标拆成阶段动作，并持续推进”。

### 适合的虾型
流程虾 + 教练虾

### MVP
- 用户输入目标
- Agent 拆为阶段计划
- 每轮推进时复盘进度并给下一步

---

## 案例 3：把经验沉淀做成工作流虾

### 原始想法
“我想把一套方法变成可复用能力。”

### 收敛后机会点
把 end-to-end workflow 打包成 skill 或基准 Agent，而不是留在聊天记录里。

### 适合的虾型
工作流虾

### MVP
- 输入一套方法
- 输出 skill 化结构、模板、交付清单

FILE:references/lobster-opportunity-evaluation.md
# 值得做成虾吗？——机会点评估框架

## 目标

用于判断一个点是否真的适合被做成小龙虾，而不是停留在“看起来很酷”的创意层。

---

## 一、先看 4 个必要条件

一个点至少要满足其中 3 个，才值得优先推进：

1. **真实痛点**
   - 用户现在确实痛
   - 不是“想象中可能有需求”

2. **重复场景**
   - 不是一次性任务
   - 最好具有周频、日频或阶段性反复出现的使用机会

3. **长期协作可能**
   - Agent 不是答一轮就结束
   - 有记忆、追踪、规划、反馈、复盘等长期价值

4. **最小闭环可成立**
   - 不依赖巨量外部系统
   - 第一版能先跑一个简单但完整的价值链路

---

## 二、再看 4 个反证问题

如果以下任一项答案非常明显是“是”，要慎重：

1. 这个问题其实用一个脚本或表单就够了吗？
2. 这个需求本质上只是“想让 AI 显得聪明”吗？
3. 这个场景是否过于低频，以至于用户不会形成使用习惯？
4. 这个想法是不是在第一版就强依赖复杂数据、复杂权限或复杂运营？

---

## 三、判断结论模板

### 值得做成虾
适合当：
- 真实高价值问题
- 有使用复利
- Agent 比普通工具更有优势

### 可以做，但要缩边界
适合当：
- 核心方向是对的
- 但当前范围太大、太散、太依赖外部条件

### 暂时不值得做成虾
适合当：
- 伪需求
- 一次性需求
- Agent 不是最佳形态

---

## 四、输出时必须包含

1. 支持理由
2. 反对理由
3. 最大失败风险
4. 推荐下一步

FILE:references/metacognitive-interview-tree.md
# 元认知引导问诊树

## 用途

当用户的想法还很模糊时，不要急着产出方案。
先用最少但最有效的问题，把机会点从“模糊直觉”压缩成“可判断对象”。

---

## 一、先判用户当前卡在哪

### 类型 A：只有朦胧想法
表现：
- “我感觉这里能做个虾”
- “好像这个方向有价值”

优先问：
1. 你最想解决的重复性问题是什么？
2. 现在最痛的环节是什么？
3. 这个问题多久会出现一次？

### 类型 B：有方向，但边界太大
表现：
- 一上来就是大产品
- 目标覆盖太多场景

优先问：
1. 如果只能保留一个最核心场景，是什么？
2. 第一版如果只服务一类人，会是谁？
3. 不接外部复杂系统时，最小闭环是什么？

### 类型 C：已经有目标，但不确定是否值得做成虾
表现：
- 在 Agent、工具、服务之间摇摆

优先问：
1. 为什么它一定要是 Agent，而不是脚本/表单/工作流？
2. 用户为什么会反复回来用，而不是一次性用完？
3. 这件事最需要判断、陪伴、追踪，还是执行？

---

## 二、8 类高价值引导问题

1. **问题本质**：真正想解决的是什么？
2. **用户对象**：谁最需要它？
3. **触发时机**：什么时候会想起它？
4. **频率强度**：高频还是低频？强痛还是弱痛？
5. **替代方案**：现在怎么解决？
6. **留存机制**：用户为什么下次还来？
7. **失败路径**：最容易放弃在哪？
8. **最小闭环**：第一版最小价值链是什么？

---

## 三、使用原则

- 不要一次问完全部问题
- 只问当前最能提升判断质量的 2-5 个
- 每轮追问后都要回收总结：我现在认为你的机会点是……
- 如果用户越说越散，就主动收敛，不继续发散脑暴

FILE:references/platform-deployment-guide.md
# Platform Deployment Guide

## 目标

当目标 Agent workspace 已建立后，不要停在文档规划。
继续主动询问用户要部署的平台，并引导其完成接入前置准备。

---

## 标准动作

1. 确认目标 Agent workspace 已建立
2. 确认关键文档已写入目标 workspace
3. 主动询问：部署在哪个平台
4. 根据平台给出接入步骤
5. 说明第一次联调怎么测

---

## Telegram

常见准备：
- BotFather 创建 bot
- 获取 bot token
- 明确要接群聊还是私聊
- 后续绑定 agent / account / routing

---

## Feishu

常见准备：
- 创建应用
- 获取 app 凭据
- 明确收消息场景（群聊 / 单聊）
- 后续配置事件订阅与接入

---

## Discord

常见准备：
- 创建 bot application
- 获取 token
- 邀请进目标服务器 / 频道
- 后续做 routing / 绑定 / 联调

---

## 原则

- 主动问，不等用户自己想起来
- 平台问题要在 workspace 建好后尽快确认
- 引导目标是让用户知道“下一步该怎么接上去”

FILE:references/product-roundness-framework.md
# 圆润化产品框架（public-safe）

> 这里用“圆润”表示：让一个 Agent 从概念和结构上更完整、更顺滑、更可持续使用，而不依赖任何私密上下文。

## 一、什么叫“圆润”

一个圆润的产品，不只是功能完整，而是：

1. 用户一看就知道什么时候该用它
2. 第一次使用就能拿到明确价值
3. 第二次还愿意回来用
4. 不会因为结构混乱而越做越重
5. 能逐步迭代，而不是第一版就崩掉

---

## 二、圆润的 5 个维度

### 1. 价值圆润
- 价值承诺清晰
- 用户能立刻感知收益

### 2. 交互圆润
- 用户知道如何开始
- 输入负担不过重
- 输出直达价值点

### 3. 结构圆润
- AGENTS / MEMORY / skills / knowledge 分层清楚
- 不把知识、流程、人格糊在一起

### 4. 留存圆润
- 不是一次性回答工具
- 有追踪、复盘、提醒、持续判断或阶段推进机制

### 5. 迭代圆润
- 第一版可上线
- 第二版有明确增强方向
- 不需要推倒重来

---

## 三、圆润化检查问题

1. 用户第一次进来会不会不知道怎么开口？
2. 第一轮对话后能不能拿到明确结果？
3. 第二次回来时，这只虾能不能体现记忆或连续性？
4. 如果删到只剩一个最小闭环，这只虾还成立吗？
5. 如果以后要增强，它的结构能不能承载扩展？

FILE:templates/benchmark-agent-spec.md
# Benchmark Agent Spec

## Agent 名称

## 用户画像

## 角色定位

## 核心任务

## 高价值场景

## 不适用场景

## Root 文件建议
- AGENTS.md：
- SOUL.md：
- USER.md：
- MEMORY.md：
- TOOLS.md：

## memory 分层建议
- 长期：
- 短期：
- knowledge/cards/reports：

## 技能建议
- 必需 skills：
- 可选 skills：

## MVP

## 边界

## 测试重点

## 后续迭代方向

FILE:templates/lobster-blueprint.md
# Lobster Blueprint

## 1. 机会点

## 2. 为什么值得 / 不值得做成虾
- 支持理由：
- 反对理由：
- 最大风险：

## 3. 目标用户与高频场景

## 4. 虾型归类
- 顾问虾 / 执行虾 / 流程虾 / 教练虾 / 分身虾 / 工作流虾

## 5. 核心价值承诺

## 6. 基准架构
- 输入：
- 输出：
- memory：
- skills：
- knowledge/cards/reports：

## 7. MVP 闭环

## 8. 第一版不做什么

## 9. 下一步

FILE:templates/lobster-opportunity-scorecard.md
# Lobster Opportunity Scorecard

| 维度 | 分数（1-5） | 说明 |
|---|---:|---|
| 真实痛点强度 |  |  |
| 使用频率 |  |  |
| 持续协作可能 |  |  |
| Agent 形态匹配度 |  |  |
| MVP 易成立性 |  |  |
| 留存潜力 |  |  |
| 结构清晰度 |  |  |

## 总结
- 推荐结论：
- 最大风险：
- 建议下一步：

FILE:templates/next-actions-checklist.md
# Next Actions Checklist

- [ ] 已确认机会点是否值得做成虾
- [ ] 已明确目标用户与高频场景
- [ ] 已完成虾型归类
- [ ] 已定义 MVP 闭环
- [ ] 已明确第一版边界
- [ ] 已产出基准架构蓝图
- [ ] 如需真实创建：先走 openclaw-agent-governance
- [ ] 再走 vertical-agent-creator
- [ ] 创建后补测试与迭代计划

FILE:templates/opportunity-intake.md
# Opportunity Intake

## 候选机会点
- 

## 谁会用
- 

## 什么情况下会用
- 

## 现在怎么解决
- 

## 最痛的地方
- 

## 这个点为什么可能值得做成虾
- 

## 如果失败，最可能死在哪
- 

## 当前判断
- 值得做成虾 / 可以做但要缩边界 / 暂时不值得

FILE:templates/platform-deployment-intake.md
# Platform Deployment Intake

## 目标平台
- Telegram / Feishu / Discord / 其他：

## 当前状态
- workspace 是否已搭好：
- 文档是否已写入目标 workspace：

## 该平台需要准备什么
- bot / app / account：
- token / credential：
- channel / group / chat：

## 接下来要做什么
1. 
2. 
3. 

## 首轮联调方式
- 

FILE:templates/product-roundness-check.md
# Product Roundness Check

- [ ] 用户一眼知道这只虾什么时候该用
- [ ] 第一次使用就能获得明确价值
- [ ] 输入成本不过高
- [ ] 输出不是泛泛建议，而是有结构的结果
- [ ] 第二次使用存在记忆或连续性价值
- [ ] 第一版闭环独立成立
- [ ] 未来增强不需要推倒重来

FILE:templates/workspace-handoff-map.md
# Workspace Handoff Map

## 目标 Agent workspace
- 路径：

## 已写入文件

### 1. 蓝图 / 报告
- `memory/reports/`
- 作用：存放架构蓝图、MVP 说明、阶段报告

### 2. 卡片 / 结构卡
- `memory/cards/`
- 作用：存放判断卡、结构卡、场景卡、回复卡

### 3. 当天推进记录
- `memory/YYYY-MM-DD.md`
- 作用：记录这次创建推进、已确认结论、待办

### 4. skills
- `skills/`
- 作用：存放已确定需要 skill 化的流程能力

## 后续怎么看
- 想改架构：先看 `memory/reports/`
- 想补知识：补到 `memory/knowledge/`
- 想补流程：补到 `skills/`
- 想看本次推进：看 `memory/YYYY-MM-DD.md`

---
name: fitclaw-public-core
description: Public-safe FitClaw coaching workflow covering onboarding, hydration, nutrition, and training structure. Use when demonstrating a reusable AI fitness coaching method without exposing private user data or live production configuration.
---

# FitClaw Public Core

## Purpose

This is the public-safe packaging layer for FitClaw.

It is not the live production workspace.
Its purpose is to expose the reusable coaching workflow only.

---

## Release Gate

This package is review-first.

That means:
1. prepare the candidate package locally,
2. review it carefully,
3. publish only after explicit approval.

Without explicit approval, this package should remain in staging only.

---

## Included public workflow scope

This package currently focuses on four reusable workflow blocks:
1. onboarding
2. hydration support
3. nutrition guidance
4. training framework guidance

---

## Hard boundary

Never treat this package as a dump of the live FitClaw project.

Only include:
- reusable workflow logic
- public-safe templates
- generalized examples
- sanitized references

Never include:
- credential files
- private user media
- private user reports or history
- private runtime bindings
- private operational materials embedded in scripts or examples

---

## Packaging rule

If this package is prepared for ClawHub, it must pass privacy review first.
The public asset is the method, not the real operating state.

---

## Current candidate modules

- fitclaw-onboarding-public
- fitclaw-hydration-public
- fitclaw-nutrition-public
- fitclaw-training-public

These modules were rewritten into public-safe references before publish.

---

## Output goal

A publishable public-safe skill package that demonstrates the FitClaw coaching method without leaking private or operational data.

FILE:references/fitclaw-hydration-public.md
---
name: fitclaw-hydration-public
description: Public-safe hydration support workflow for AI fitness coaching. Use when calculating a simple daily hydration target, setting lightweight reminders, and helping users build a sustainable hydration habit without fake precision.
---

# FitClaw Hydration Public

## Purpose

This is the **public-safe hydration module** extracted from FitClaw.

Its role is not to create fake precision.
Its role is to help users:
- understand a reasonable hydration target,
- turn that target into an easy daily rhythm,
- and stay consistent through light reminders and check-ins.

---

## Use this when

Use this workflow when:
- a user wants help with daily water intake,
- hydration habits are weak or inconsistent,
- or hydration is part of a broader coaching routine.

---

## Core goal

Make hydration actionable and sustainable.

The user should feel:
- this is simple enough to follow,
- specific enough to matter,
- and not so precise that it becomes annoying.

---

## Minimum inputs

To estimate a hydration target, preferably know:
- sex / gender context if relevant to the coaching logic
- current body weight
- whether it is a training day
- whether the user wants reminders

If some information is missing, use a temporary estimate and label it as temporary.

---

## Example target logic

A simple baseline approach:
- male baseline: `2.5L`
- female baseline: `2.0L`
- adjust `±0.2L` for every `±10kg` from a `60kg` reference
- add `+0.5L` on training days
- keep the result within a reasonable band such as `1.8L ~ 3.5L`

This is a practical coaching estimate, not a medical prescription.

---

## Workflow

### Step 1 — Estimate a daily target
Use the user's body weight and training-day status to produce a practical hydration goal.

### Step 2 — Explain the logic simply
Do not just state a number.
Briefly explain:
- baseline amount,
- training adjustment,
- final target.

### Step 3 — Turn the number into an easy schedule
Translate the target into a few time anchors, for example:
- morning
- late morning / afternoon
- training window
- post-training if relevant

### Step 4 — Use light reminders only
Reminders should feel supportive, not nagging.
A good rule is a few checkpoints per day, plus a training-day top-up reminder when relevant.

### Step 5 — End the day with a lightweight reflection
Use a simple check-in:
- roughly hit target / missed it / overshot it,
- and what to adjust tomorrow.

---

## Recommended response structure

### Initial hydration setup
- daily target
- brief explanation of how it was estimated
- simple distribution suggestion
- ask whether the user wants reminder timing built around their routine

### Routine-based reminder setup
- propose a few concrete time anchors
- explain how training changes hydration needs
- keep the tone practical and easy

### End-of-day review
- ask whether the target was roughly met
- suggest one small improvement for tomorrow

---

## Memory / storage guidance

If the runtime supports user memory, store:
- hydration target
- reminder preference
- rough adherence trend

Public-safe rule:
- do not assume private file paths
- do not require a specific local workspace layout in the public version

---

## Guardrails

- Do not pretend to know the user's exact water intake when you do not.
- Do not present hydration to the milliliter as if it were perfectly tracked.
- Do not use long moralizing lectures.
- Do not treat hydration as the sole lever of progress.

---

## Success criteria

This module succeeds if:
- the target feels believable,
- the schedule feels easy to follow,
- and the user can actually keep the habit going.

It fails if:
- the target feels random,
- the reminders feel oppressive,
- or the method turns into fake precision.

FILE:references/fitclaw-nutrition-public.md
---
name: fitclaw-nutrition-public
description: Public-safe nutrition coaching workflow for AI fitness coaching. Use when analyzing meals, guiding food choices, and generating practical macro-based nutrition suggestions without relying on private user data or internal-only knowledge paths.
---

# FitClaw Nutrition Public

## Purpose

This is the **public-safe nutrition module** extracted from FitClaw.

Its role is to help an AI coach do nutrition guidance in a way that is:
- structured,
- practical,
- quantitatively useful,
- and still understandable to a normal person.

This public version keeps the method,
not the private operating environment.

---

## Use this when

Use this workflow when:
- a user asks whether a meal is appropriate,
- a user asks how to eat around fat loss / muscle gain / recomposition,
- a coach needs to generate an initial macro-based nutrition structure,
- or the user needs practical guidance for takeout, social meals, or next-meal adjustments.

---

## Core goal

Nutrition advice should feel concrete and coach-like.

That means:
- evaluate structure before giving slogans,
- prioritize protein and meal composition,
- translate goals into macro ranges,
- and give the user a realistic next action.

This module should not collapse into:
- vague “eat clean” advice,
- generic calorie talk,
- or moralizing food language.

---

## Main modes

### Mode 1 — Meal guidance mode
Use when the user asks about a specific meal, takeout order, or social eating situation.

Questions include:
- “Can I eat this?”
- “How should I order this?”
- “How much should I eat?”
- “What should I change in the next meal?”

### Mode 2 — Structured nutrition plan mode
Use when enough baseline information exists to generate a broader nutrition plan.

Prefer knowing:
- goal direction (fat loss / gain / recomposition)
- sex / gender context if relevant to the coaching logic
- body weight
- training frequency
- meal pattern and food environment
- major behavioral constraints

---

## Decision sequence

### In meal guidance mode
1. Check protein adequacy first
2. Then estimate total energy range
3. Then check carbohydrate / fat structure
4. Then suggest the next adjustment

### In structured plan mode
1. Confirm current goal direction
2. Set training-day macro targets
3. Set rest-day macro targets
4. Turn those targets into meal structure
5. Give a one-day example
6. Give a simple adjustment rule for the next 1–2 weeks

---

## Example macro logic

A practical coaching method may start from body weight-based macro ranges.
For example:

### Muscle gain starting ranges
- carbohydrate: around `3.5–4.5 g/kg` for men, `3.0–3.5 g/kg` for women
- protein: around `1.5–2.0 g/kg`
- fat: around `1.0 g/kg`

### Fat-loss starting ranges
- carbohydrate: often around `2.0–3.0 g/kg` depending on phase and activity
- protein: often around `1.2–1.5+ g/kg`
- fat: often around `0.8 g/kg`

### Rest day logic
- reduce carbohydrates relative to training days
- usually keep protein similar
- usually keep fat stable unless there is a clear reason to change it

These are coaching starting points, not medical prescriptions.
The real test is whether the user can execute them and whether progress data confirms they work.

---

## Recommended output structure

### Structured plan output
1. training-day macro targets
2. rest-day macro targets
3. estimated energy range (mark as estimate)
4. meal distribution ideas
5. a simple “how to eat tomorrow” example
6. a short adjustment rule for the next 1–2 weeks

### Meal guidance output
1. what the meal likely contains
2. whether protein is adequate
3. rough energy and structure judgment
4. what the main problem is, if any
5. what to do in the next meal or later in the day

---

## Coaching style

Good nutrition coaching sounds like:
- practical
- quantitative enough to be actionable
- honest about uncertainty
- focused on the biggest lever first

Bad nutrition coaching sounds like:
- “just eat less”
- “just avoid carbs”
- “just eat clean”
- false precision for meals that are impossible to measure exactly

---

## Memory / storage guidance

If the runtime supports user memory, store:
- goal direction
- broad nutrition structure
- recurring food behavior problems
- recent adherence trend

Public-safe rule:
- do not assume private local knowledge paths
- do not assume a private workspace layout
- keep references abstract unless a public reference pack is bundled

---

## Guardrails

- Do not ignore protein priority.
- Do not give macro numbers without explaining the reason.
- Do not pretend uncertain meals are measured with exact precision.
- Do not make food guidance shame-based.
- Do not rely on internal-only knowledge paths in the public version.

---

## Success criteria

This module succeeds if:
- the user knows what to do next,
- the advice is specific enough to execute,
- and the nutrition logic feels coherent rather than random.

It fails if:
- the user gets only slogans,
- the advice is overly abstract,
- or the module hides uncertainty and pretends to know more than it does.

FILE:references/fitclaw-onboarding-public.md
---
name: fitclaw-onboarding-public
description: Public-safe onboarding workflow for an AI fitness coach. Use when welcoming a new user, collecting lightweight baseline information, and moving them into the next assessment step without interrogating them or overcommitting too early.
---

# FitClaw Onboarding Public

## Purpose

This is the **public-safe onboarding module** extracted from FitClaw.

Its job is simple:
- welcome a new user,
- establish trust,
- collect the minimum baseline profile,
- and move the user into the next useful step without turning the conversation into an interrogation.

This public version keeps the method,
not the live production state.

---

## Use this when

Use this workflow when:
- the user is new,
- their baseline profile is incomplete,
- or the coaching flow is still at the welcome / profile-building stage.

---

## Core goal

Finish lightweight baseline onboarding while preserving momentum.

The user should feel:
- welcomed,
- understood,
- and guided into the next step.

They should **not** feel like they are filling out a bureaucratic intake form.

---

## Minimum information to collect

Keep the initial baseline compact. Prioritize:
- preferred name
- sex / gender context if relevant to the coaching method
- age
- height
- current body weight
- broad goal direction: fat loss / muscle gain / recomposition

---

## Workflow

### Step 1 — Welcome with confidence and warmth
Briefly explain:
- who you are,
- how you will help,
- and that this is a long-term coaching relationship, not a one-off answer.

### Step 2 — Confirm how to address the user
Start with the user's preferred name or form of address.

### Step 3 — Collect baseline gradually
Ask only **1 to 2 questions per turn**.
Do not stack too many intake questions at once.

### Step 4 — Give only low-risk guidance if profile is incomplete
If the user still has major gaps in baseline data:
- give only temporary, low-risk suggestions,
- and clearly say the more accurate plan depends on a fuller baseline.

### Step 5 — End onboarding by moving to the next concrete step
Once baseline data is sufficient,
move the user into the next stage.
For a body-composition coaching flow, that next stage is often:
- current condition capture,
- goal clarification,
- or deeper assessment.

Do **not** jump several stages ahead at once.

---

## Recommended response structure

### Welcome turn
- who you are
- how you will support the user
- ask how to address them

### Baseline follow-up turn
- briefly restate what is already known
- ask only the next 1 to 2 key questions
- explain in one sentence why these answers matter

### Baseline complete turn
- briefly summarize the baseline profile
- state the next step clearly
- request only that next step, not multiple future steps at once

---

## Memory / storage guidance

If the runtime supports memory or user profiles, store:
- preferred name
- baseline body data
- broad goal direction
- current stage in the workflow

Public-safe rule:
- do not assume any specific private workspace path
- do not hardcode private storage locations
- describe the storage need generically unless the target system is explicitly known

---

## Guardrails

- Do not ask 3+ baseline questions in one turn unless the user explicitly wants a rapid intake.
- Do not output a full formal plan before the baseline is sufficient.
- Do not request multiple image/reference inputs at the same moment if the method depends on stepwise progression.
- Do not pad the interaction with generic customer-service filler.

---

## Success criteria

This module succeeds if:
- the user feels the flow is easy to enter,
- the baseline gets completed without friction,
- and the conversation moves naturally into the next coaching step.

It fails if:
- the interaction feels like a form,
- the user gets overloaded,
- or the coach jumps into premature prescription.

FILE:references/fitclaw-training-public.md
---
name: fitclaw-training-public
description: Public-safe training workflow for AI fitness coaching. Use when selecting a training split, building a sustainable training structure, calibrating starting loads, and guiding users through progression without relying on private internal-only knowledge paths.
---

# FitClaw Training Public

## Purpose

This is the **public-safe training module** extracted from FitClaw.

Its job is not to dump a random workout list.
Its job is to help an AI coach:
- choose an appropriate training structure,
- explain why that structure fits the user,
- calibrate starting loads conservatively,
- and guide progression through feedback.

This public version keeps the method,
not the private operating environment.

---

## Use this when

Use this workflow when:
- a user needs an initial training framework,
- a coach is choosing between a 3-day and 4-day split,
- a user says they are ready to start training,
- or a user reports workout performance and needs adjustment.

---

## Core goal

Training guidance should create a loop, not a one-time list.

That means:
- choose a split that matches real frequency and recovery,
- use movement categories and anchor lifts,
- set conservative starting loads,
- and update the plan from actual performance.

---

## Baseline inputs

Before giving a structured training framework, preferably know:
- training days per week
- session duration
- training setting (gym / home / mixed)
- recovery constraints or injuries
- at least a few strength anchors

Strength anchors ideally include:
- one push pattern
- one pull pattern
- one lower-body pattern
- optionally one hinge / posterior-chain movement

Each anchor is more useful if it includes:
- exercise
- load
- reps
- whether it was near failure

---

## Decision sequence

### Step 1 — Choose the split
A practical default logic:
- if frequency is unclear, start with a 3-day structure
- if the user can reliably train 4–5 times per week and recovery is reasonable, a 4-day split often works well
- avoid prematurely over-fragmenting into a 5-day split unless the context clearly supports it

### Step 2 — Explain the choice
Do not just announce the split.
Explain:
- why this structure fits frequency,
- why it fits recovery,
- and what problem it solves.

### Step 3 — Define day structure
Give each day a clear role, for example:
- push
- pull
- legs + core
- optional weak-point / accessory day

### Step 4 — Calibrate starting loads
Use recent working-set data when available.
If data is vague, ask a single calibration question before pretending to know exact loads.

### Step 5 — Turn the framework into execution
When the user is actually starting the session, provide:
- today's goal
- warm-up guidance
- working sets
- rest timing
- breathing / execution cues when useful

### Step 6 — Adjust from feedback
Use reported reps, fatigue, difficulty, and movement quality to decide whether to:
- increase load,
- add reps,
- hold steady,
- or stay conservative.

---

## Practical split examples

### 4-day example
- Day 1: back + rear delts + biceps
- Day 2: chest + front/side delts + triceps
- Day 3: legs + core
- Day 4: weak-point or accessory emphasis

### 3-day example
- Day 1: push
- Day 2: pull
- Day 3: legs + core

These are workflow examples, not mandatory laws.
The real point is matching the structure to the user's frequency and recovery reality.

---

## Load calibration guidance

Use this order:
1. recent working-set data first
2. rep + load data to estimate a reasonable starting zone
3. if data is unclear, ask one clarifying question
4. if a movement has no anchor, stay conservative instead of bluffing

Good public-safe guidance sounds like:
- “Start here, then adjust based on your first session feedback.”

Bad guidance sounds like:
- pretending exact loads are known without usable anchor data.

---

## Recommended output structure

### Framework mode
1. why this split
2. weekly day structure
3. main movement categories per day
4. starting load guidance for 1–2 anchor lifts per day when possible
5. what the user should report back after training

### Execution mode
1. today's objective
2. warm-up
3. working sets
4. rest times
5. execution cues
6. what feedback to send back after the session

---

## Memory / storage guidance

If the runtime supports user memory, store:
- preferred split
- current cycle position
- strength anchors
- recent training feedback
- progression decisions

Public-safe rule:
- do not assume private workspace file paths
- do not depend on internal-only knowledge routes in the public version

---

## Guardrails

- Do not overcomplicate the split too early.
- Do not prescribe exact loads without enough anchor data.
- Do not present the framework as fixed forever.
- Do not detach exercise selection from recovery reality.
- Do not depend on internal-only knowledge paths in the public version.

---

## Success criteria

This module succeeds if:
- the user gets a framework they can actually run,
- the starting loads feel realistic,
- and the plan evolves through feedback rather than guesswork.

It fails if:
- the plan is overbuilt,
- the loads are bluff-based,
- or the user gets a template that ignores their real context.

FILE:templates/public-sanitization-checklist.md
# FitClaw Public Sanitization Checklist

## Remove before any publish
- live credentials or access material
- private user media
- private user reports or progress history
- personal identifiers and internal account identifiers
- local machine specific private paths

## Keep only if sanitized
- workflow logic
- generalized templates
- anonymous examples
- public-safe knowledge references

---
name: yuanyuan-blueprint-workshop
description: Turn a person's tacit know-how into a testable Agent Blueprint through a structured 5-step workshop: scenario discovery, SOP extraction, dependency mapping, blueprint generation, and skill sourcing. Use when helping someone discover whether they have a reusable method and transform it into a buildable lobster-agent blueprint.
---

# Yuanyuan Blueprint Workshop

## Purpose

This skill packages the full **Yuanyuan** workflow into one reusable workshop.

Its job is not to magically generate a finished product from one vague sentence.
Its job is to help a user:
1. discover a real scenario worth turning into an agent,
2. extract their implicit know-how,
3. map the required knowledge and tools,
4. produce a real Agent Blueprint,
5. plan how the missing skills should be sourced.

---

## Use this skill when

Use it when the user says things like:
- “I think I have some experience, but I don't know if it can become an agent.”
- “Help me turn my know-how into a lobster agent.”
- “I want to productize my method.”
- “Help me figure out whether this workflow is structured enough.”
- “Take me from idea → blueprint → skill gap plan.”

---

## Do NOT use this skill when

- The user only wants a small factual answer.
- The user already has a finished blueprint and only needs implementation.
- The user asks for direct coding or deployment without discovery.
- The task is only to install/publish one isolated skill.

---

## Core promise

This workshop should produce two feelings for the user:
1. **“The AI actually understands what I'm good at.”**
2. **“Aha — I really do have a reusable method.”**

If the interaction feels like a cold questionnaire or generic encouragement, the skill is failing.

---

## Hard rules

1. Do **not** jump straight into full product generation before structure is clear.
2. Do **not** confuse domain knowledge with decision logic.
3. Do **not** overpromise that every idea deserves to become an agent.
4. Do **not** replace user delivery with a file path.
   - Save files internally if useful.
   - But when delivering a blueprint or structured result, send the **full content directly in the chat**.
5. Do **not** install many skills blindly.
   - First reuse local capabilities.
   - Then search ClawHub.
   - Then vet/scan.
   - Only then install or write new skills.

---

## The 5-step workshop

### Step 1 — Scenario Discovery
Goal: narrow a vague direction into one concrete, testable scenario.

Questions to drive:
- What are you consistently better at than most people?
- What do people repeatedly come to you for?
- If we only productize one scenario first, which one should it be?

Judging standard:
- Input can be defined
- Judgment can be structured
- Output can be verified

Output:
- scenario definition
- target user
- core task
- initial verdict: suitable / not yet suitable

### Step 2 — SOP Extraction
Goal: extract the actual method, not just abstract knowledge.

Methods:
- Ask “When someone comes to you for this, how do you usually handle it?”
- Continuously restate structure back to the user
- Push on judgment criteria, branches, exceptions, and mistakes

Output:
- step list
- judgment points
- branch logic
- common pitfalls
- unclear gaps that still need follow-up

### Step 3 — Knowledge & Tools Mapping
Goal: identify what this future agent needs in order to really work.

Distinguish:
- public knowledge layer
- skill-private references
- real tools / APIs / automation dependencies

Output:
- knowledge sources
- tool dependencies
- priority of dependencies
- minimal viable dependency set

### Step 4 — Agent Blueprint Generation
Goal: turn the findings into a buildable blueprint.

The blueprint should at minimum include:
1. scenario definition
2. target user
3. core task
4. SOP flow
5. judgment rules
6. knowledge requirements
7. skill/tool requirements
8. risks and boundaries
9. test suggestions
10. next build steps

Delivery rule:
- Give the user the **full blueprint directly in chat**.
- Saving a file is optional internal archiving, not the deliverable itself.

### Step 5 — Skill Sourcing Plan
Goal: connect the blueprint to the platform layer.

Use this order:
```text
reuse local
→ search ClawHub
→ vet/scan
→ install if suitable
→ otherwise write the missing skill
```

Output:
- capability gaps
- locally reusable skills
- ClawHub search targets
- likely self-built skills
- fill order

---

## Recommended final deliverables

By the end of this workshop, aim to produce:
1. a **Scenario Definition**,
2. a **Structured SOP**,
3. a **Dependency Map**,
4. a **Full Agent Blueprint**,
5. a **Skill Sourcing Plan**.

---

## Success criteria

The workshop is working if the user says things like:
- “Yes, that's exactly my real value.”
- “I didn't realize my process was this clear.”
- “Now I can actually imagine this becoming an agent.”

The workshop is failing if it turns into:
- generic praise,
- shallow summarization,
- premature system design,
- or path-only delivery.

---

## References

Use the files under `references/` and `templates/` for deeper context and output scaffolds.

FILE:references/01-positioning.md
# Yuanyuan Positioning

Yuanyuan is not an execution-first agent.
Yuanyuan is a meta-cognitive coach that helps users discover whether they have reusable judgment, and turn that into a buildable Agent Blueprint.

Its first value is not deployment.
Its first value is understanding, extraction, and structuring.

FILE:references/02-workflow.md
# Workflow Summary

Default sequence:
1. Scenario discovery
2. SOP extraction
3. Knowledge and tools mapping
4. Agent Blueprint generation
5. Skill sourcing

Never skip directly from vague idea to “finished product”.

FILE:references/03-testing.md
# Testing Rubric

Important dimensions:
- felt-understanding (“AI really got me”)
- scenario convergence
- SOP depth
- aha-moment intensity
- boundary honesty

Bad signs:
- generic encouragement
- questionnaire feel
- overconfident summarization
- path-only delivery

FILE:references/04-skill-sourcing.md
# Skill Sourcing Rules

Default order:
reuse local → search ClawHub → vet/scan → install if suitable → self-build if necessary.

Do not blindly install many skills.
The point is to generate a capability completion plan, not to bloat the agent.

FILE:templates/blueprint-template.md
# Agent Blueprint Template

## 1. Scenario Definition
## 2. Target User
## 3. Core Task
## 4. SOP Flow
## 5. Judgment Rules
## 6. Knowledge Requirements
## 7. Skill / Tool Requirements
## 8. Risks and Boundaries
## 9. Test Suggestions
## 10. Next Build Steps

FILE:templates/skill-sourcing-plan-template.md
# Skill Sourcing Plan Template

## 1. Capability Gaps
## 2. Locally Reusable Skills
## 3. ClawHub Search Targets
## 4. Likely Self-Built Skills
## 5. Fill Order

---
name: project-retrospective
version: 1.0.0
description: 自动项目复盘机制。当完成复杂项目后，自动提取最优路径生成skill，并记录踩坑经验到memory。
author: 小爪 (OpenClaw Community)
tags: [retrospective, learning, meta-skill, knowledge-management]
---

# 项目自动复盘机制

## 1. 概述

当完成一个复杂项目的开发后，自动将经验沉淀为可复用的知识。

**核心功能**：
- 自动识别复盘时机
- 提取标准化最优路径 → 生成skill
- 提取踩坑经验 → 记录到memory

## 2. 触发条件

满足以下**所有条件**时触发：

### 2.1 时间条件
- 对同一个项目的对话时长 ≥ 2小时
- 或消息轮数 ≥ 50轮

### 2.2 复杂度条件
- 经历了多次尝试和修正
- 遇到了多个问题和解决方案
- 涉及多个文件的创建和修改

### 2.3 用户触发
用户明确表示要总结，例如：
- "总结一下"
- "把这个过程和经验总结一下"
- "复盘一下"
- "记录下来"

## 3. 执行流程

### 步骤1：确认复盘意图
当检测到触发条件时，询问用户：
```
检测到你刚完成了一个复杂项目的开发。是否需要我帮你：
1. 提取标准化流程，生成可复用的skill
2. 记录踩坑经验到memory

这样下次遇到类似项目时可以直接参考。
```

### 步骤2：分析对话历史
- 提取项目目标和背景
- 识别关键步骤和决策点
- 找出遇到的问题和解决方案
- 总结最佳实践

### 步骤3：生成skill文档

**文件位置**：`/root/.openclaw/workspace/skills/<project-name>/SKILL.md`

**内容结构**：
```markdown
---
name: project-name
description: 简短描述这个skill解决什么问题
---

# 项目名称

## 1. 概述
- 适用场景
- 核心功能

## 2. 核心文件清单
- 需要创建/修改的文件列表

## 3. 详细步骤
- 步骤1：...
- 步骤2：...
- ...

## 4. 常见问题和解决方案
- 问题1：...
- 问题2：...

## 5. 案例分析
- 实际应用示例
- 经验教训
```

### 步骤4：生成memory文档

**文件位置**：`/root/.openclaw/workspace/memory/YYYY-MM-DD-<project-name>-pitfalls.md`

**内容结构**：
```markdown
# 项目名称踩坑记录

**日期**：YYYY-MM-DD
**项目**：项目描述

## 1. 问题1标题

### 问题描述
详细描述遇到的问题

### 尝试的解决方案
- ❌ 方案1 - 为什么失败
- ❌ 方案2 - 为什么失败
- ✅ 方案3 - 最终成功

### 最终解决方案
具体的解决步骤

### 经验教训
从这个问题中学到的经验

---

## 2. 问题2标题
...

---

## 总结和最佳实践
- 开发流程建议
- 文件管理建议
- 调试技巧
```

### 步骤5：确认和保存
- 展示生成的文档路径
- 询问用户是否需要修改
- 保存到对应位置

## 4. 使用示例

### 场景：开发FitClaw健身教练Agent

**对话时长**：约3小时
**消息轮数**：100+轮
**涉及文件**：10+个

**用户触发**：
```
用户："很好，然后小龙虾就先到这一段，然后我交接了。
然后这个过程中，你要做两个：
第一个：把做成一只垂直类的这种小龙虾的流程写成一个 skill
第二个：就是把我们踩过的坑你写在 memory 里面"
```

**系统响应**：
1. 创建skill：`vertical-agent-creator`
2. 创建memory：`2026-03-12-fitclaw-pitfalls.md`

## 5. 注意事项

### 5.1 何时使用
- ✅ 完成了复杂的多步骤项目
- ✅ 经历了多次尝试和修正
- ✅ 积累了可复用的经验
- ❌ 简单的一次性任务
- ❌ 没有通用价值的特定操作

### 5.2 文档质量
- 标准化流程要清晰、可复用
- 踩坑记录要详细、有价值
- 包含具体的代码示例和命令
- 记录失败的尝试和原因

### 5.3 命名规范
- skill名称：`<domain>-<function>`
- memory文件：`YYYY-MM-DD-<project>-pitfalls.md`

## 6. 参考案例

### 案例1：FitClaw开发
- **生成的skill**：`vertical-agent-creator`
- **生成的memory**：`2026-03-12-fitclaw-pitfalls.md`
- **价值**：下次创建垂直类Agent时可直接参考

### 案例2：生图功能实现
- **关键经验**：API key加密、容灾机制
- **踩坑点**：脚本丢失、路径限制
- **可复用性**：高（其他需要图片处理的项目都可参考）

---

**使用建议**：每次完成复杂项目后，主动触发复盘机制，持续积累可复用的知识库。