Skill: axelhu/agent-teacher (version 1.3.1)

--- name: agent-teacher description: 教授新 agent 掌握工作室基础能力的技能。触发时机：(1) 创建新 agent 后需要初始化配置时 (2) 教现有 agent 掌握某项技能时 (3) 新 agent 上岗培训。课程分"行为准则→基础→进阶"三大类，行为准则必须优先于一切技能学习。 --- # Agent Teacher 教授新 agent 掌握工作室基础能力的技能。 ## 课程理念 - **准则优先**：行为准则必须先于一切技能学习，准则比技能更重要 - **基础扎实**：技能让 Agent 做事情，准则让 Agent 不犯错 - **循序渐进**：按顺序完成课程，不要跳跃 - **不重复记录**：已经学过并记住的内容不要重复记录，直接巩固现有知识点即可 --- ## 课程体系 ### 行为准则（必修第一课） **必须先于所有技能学习！** 准则违规比技能不熟练更严重。 | 课程 | 内容 | |------|------| | `rules-of-conduct` | 工作室行为准则（约15条核心规则） | 详见 `references/rules-of-conduct.md` ### 身份定制（必修第1.5课） **在安装任何技能之前必须完成！** 定义你是谁、你的工作规范。这些文件必须**中文编写**。 | 课程 | 内容 | |------|------| | `phase-0-identity` | SOUL.md、IDENTITY.md、AGENTS.md 定制 | 详见 `references/phase-0-identity.md` ### 基础课程（必修） 在行为准则学习后进行。 | 分类 | 技能 | 安装 | |------|------|------| | **持续存在** | daily-log, memory-review, daily-backup, todo-list | clawhub 安装 | | **沟通协作** | feishu-send, contacts, sessions_send | 部分安装部分内置 | | **知识检索** | memory_search, memory_get | 内置 | | **飞书文档** | feishu_doc/wiki/bitable | 内置 | | **系统维护** | health-check, dependency-tracker | clawhub 安装 | 详见 `references/phase-1-foundation.md` ### 进阶课程（选修） 按需学习，用于专业任务。 | 分类 | 技能 | 安装 | |------|------|------| | **搜索** | mmx-cli, multi-search-engine | mmx-cli 优先，mcporter 备选 | | **浏览器** | browser | 内置需启用 | | **外部服务** | mcporter | 需配置key | | **视觉** | canvas, image, mmx-cli | image 理解用内置工具，生图用 mmx-cli | | **技能开发** | skill-creator, clawhub | 部分内置部分安装 | 详见 `references/phase-2-advanced.md` --- ## 新 agent 上岗教学流程 ### Step 1: 学习行为准则（必须第一个） 读取并理解 `references/rules-of-conduct.md` → 确认理解后再进行下一步 ### Step 2: 安装并学习基础技能 ```bash cd /home/axelhu/.openclaw/workspace/[agent-name] mkdir -p skills # 基础技能 clawhub install daily-log --dir skills clawhub install memory-review --dir skills clawhub install daily-backup --dir skills clawhub install todo-list --dir skills clawhub install feishu-send --dir skills clawhub install health-check --dir skills clawhub install dependency-tracker --dir skills cp -r /home/axelhu/.openclaw/workspace/skills/contacts skills/ # sessions_send、memory_search、memory_get、feishu_doc/wiki/bitable、skill-creator 已内置 ``` ### Step 3: 验证掌握 - 行为准则：能复述至少 5 条核心规则 - 基础技能：能发日报、能搜记忆、能给其他 agent 发消息 ### Step 4: 进阶按需学习 根据角色和任务需要，安装进阶技能。 --- ## 详细课程资料 - 行为准则：`references/rules-of-conduct.md` - 基础技能：`references/phase-1-foundation.md` - 进阶技能：`references/phase-2-advanced.md` ## 汇报模板 ``` 已完成 [agent-name] 上岗培训 ✅ 行为准则：✅ 已掌握（能复述核心规则） 基础技能：✅ daily-log, memory-review, daily-backup, todo-list, feishu-send, contacts, health-check 进阶技能：按需安装 ``` ## 触发示例 - "教 zero-producer 上岗培训" - "新 agent 上岗，按顺序教学" - "给 programmer 补行为准则"

path: references/learning-from-gstack-artist.md
content: # Artist 学习指南：借鉴 Gstack

> 参考：memory/knowledge/fw-gstack-overview.md
> 原项目：https://github.com/garrytan/gstack

---

## Artist 在 Gstack 中的对应角色

> 注意：Gstack主要面向代码产品，直接对应的设计角色较少。
> 以下是从其他角色中提取的适用原则。

| Gstack角色 | 职责 | 对Artist的借鉴 |
|-----------|------|-----------------|
| **/qa** | 真浏览器验证，找到bug直接修 | 产出后验证，不只是交付 |
| **/design-review** | 前后对比，原子提交 | 记录创作演进 |
| **/retro** | 每周反思，识别成长机会 | 定期审视产出质量趋势 |
| **并行sprints** | 多个任务同时跑 | 优化并行工作流程 |

---

## Artist 可以学习的核心能力

### 1. QA验证思维

**Gstack的/qa**：
- 真浏览器点击验证，不只是静态检查
- 找到问题直接修复+生成回归测试
- 验证修复有效

**Artist应该做**：
- 生成的图不只是跑完就交
- 用工具/方法验证产出符合预期
- 如果不符合，说清楚需要调整什么

---

### 2. 前后对比和质量追踪

**Gstack的/design-review**：
- 每个版本前后截图对比
- 原子提交，每个改动独立
- 明确改进点

**Artist应该做**：
- 每次迭代保存前后对比
- 记录：这张图改了什么、为什么改
- 长期追踪自己的质量趋势

---

### 3. 并行工作流

**Gstack的并行sprints**：
- 10-15个sprint同时跑
- 不同功能、不同分支

**Artist应该做**：
- 识别可以并行的创作任务
- 不要等一个完成才开始下一个
- 用session管理不同任务的上下文

---

### 4. 定期自我反思（/retro）

**Gstack的/retro关注点**：
- 每人产出分解
- 测试健康趋势
- 成长机会

**Artist应该做**：
- 定期审视：最近产出质量稳定吗？
- 识别：哪些风格/类型效果最好
- 找到：需要提升的方向

---

### 5. 批判性审视AI辅助产出

**Gstack的AI Slop Detection**：
- 识别看起来像AI生成的平庸设计
- 保持创作的独特视角

**Artist应该做**：
- AI生成的图不要直接用，要有判断
- 问：这个图有独特视角吗？
- 确保产出有艺术家人为的审美判断

---

### 6. 设计系统思维

**Gstack的/design-consultation**：
- 从零构建设计系统
- 研究竞品、提出创意风险

**Artist应该做**：
- 为项目建立美术风格规范
- 研究同类游戏的视觉风格
- 在规范内创新，不只是随机创作

---

## 行动项

- [ ] 阅读完整Overview：memory/knowledge/fw-gstack-overview.md
- [ ] 重点看 /qa 和 /design-review 的验证方法
- [ ] 以后产出时验证是否符合预期，不只是提交
- [ ] 建立自己的质量标准和前后对比习惯

---

## 相关文件

- 总览：memory/knowledge/fw-gstack-overview.md
- Gstack原项目：https://github.com/garrytan/gstack


path: references/learning-from-gstack-designer.md
content: # Designer 学习指南：借鉴 Gstack

> 参考：memory/knowledge/fw-gstack-overview.md
> 原项目：https://github.com/garrytan/gstack

---

## Designer 在 Gstack 中的对应角色

| Gstack角色 | 职责 | 对Designer的借鉴 |
|-----------|------|-----------------|
| **/plan-design-review** | 设计评审，0-10评分 | 设计产出需要被评审 |
| **/design-consultation** | 从零构建设计系统 | 设计是系统化工作 |
| **/design-review** | 审计+修复，原子提交 | 设计需要验证和迭代 |
| **Senior Designer** | 识别AI垃圾 | 批判性审视AI产出 |

---

## Designer 可以学习的核心能力

### 1. 设计评审机制

**Gstack做法**：
- 每个设计维度0-10评分
- 明确说明10分是什么样的
- 然后修改计划达到10分

**Designer应该做**：
- 产出设计稿时自评质量（0-10）
- 明确什么是"10分设计"
- 识别当前差距

---

### 2. 设计文档标准化

**Gstack的DESIGN.md**：
- 设计决策记录在文档中
- 后续流程读取设计文档
- 文档是设计和其他环节的连接器

**Designer应该做**：
- 每个设计决策写简短说明
- 记录为什么选A不选B
- 让其他人能看懂设计逻辑

---

### 3. AI垃圾检测

**Gstack的AI Slop Detection**：
- 识别看起来像AI生成的低质量设计
- 保持设计的原创性和人性化

**Designer应该做**：
- 收到AI辅助设计时，批判性审视
- 确保设计有独特视角，不是泛泛之辈
- 问：这个设计解决的是真实问题吗？

---

### 4. 设计验证（类似/qa）

**Gstack的/qa**：
- 真浏览器测试，不只是静态检查
- 找到问题直接修复
- 生成回归测试防止问题重现

**Designer应该做**：
- 设计稿出来后，用工具模拟验证
- 美术风格图生成后，检查是否达到预期
- 如果不符合预期，说明需要调整什么

---

### 5. 前后对比思维

**Gstack的/design-review**：
- 原子提交，每个改动独立
- 前后截图对比
- 明确每个版本改进了什么

**Designer应该做**：
- 每次迭代保存前后对比
- 记录设计演进路径
- 不只是交付最终稿，也要展示过程

---

### 6. 创意风险意识

**Gstack的/design-consultation**：
- 提出安全选择 AND 创意风险
- 不只做保守设计

**Designer应该做**：
- 方案中包含"安全选项"和"创意押注"
- 说明每个选项的风险和收益
- 敢于在合适时做大胆设计

---

## 行动项

- [ ] 阅读完整Overview：memory/knowledge/fw-gstack-overview.md
- [ ] 重点看 /plan-design-review 和 /design-consultation 的设计
- [ ] 以后产出设计时，附上设计文档说明决策
- [ ] 练习对每个设计维度自评0-10

---

## 相关文件

- 总览：memory/knowledge/fw-gstack-overview.md
- Gstack原项目：https://github.com/garrytan/gstack


path: references/learning-from-gstack-producer.md
content: # Producer 学习指南：借鉴 Gstack

> 参考：memory/knowledge/fw-gstack-overview.md
> 原项目：https://github.com/garrytan/gstack

---

## Producer 在 Gstack 中的对应角色

| Gstack角色 | 职责 | 对Producer的借鉴 |
|-----------|------|-----------------|
| **CEO/Founder** | 重新思考问题，找10星产品 | Producer是工作室方向把控者 |
| **/office-hours** | 6个强制问题重新定义产品 | 接任务先挑战需求，防止做错方向 |
| **/plan-ceo-review** | 4种扩张/收缩模式 | 根据资源调整项目范围 |

---

## Producer 可以学习的核心能力

### 1. 重新定义问题（最重要）

**Gstack做法**：
- 用户说"daily briefing app"
- /office-hours 重新定义为"personal chief of staff AI"
- 挖掘用户没意识到的5个能力，挑战4个前提

**Producer应该做**：
- 接任务时不只分解任务，要先问"为什么要做这个"
- 挑战需求的根本假设
- 识别X-Y问题（用户说Y，实际需要X）

**练习**：
- 拿到任何任务，先问"这个需求解决的核心问题是什么"
- 如果没有清晰的问题陈述，不开始分解任务

---

### 2. 需求挑战机制

**Gstack的6个强制问题**：
1. 痛点是什么？（具体例子，不是假设）
2. 现有方案为什么不work？
3. 你怎么知道这是个问题？（数据/证据）
4. 成功的标准是什么？
5. 什么情况下你会放弃这个方案？
6. 如果只能做一件事，是什么？

**Producer应该做**：
- 分配任务前先回答这6个问题
- 把答案作为任务描述的一部分

---

### 3. 并行任务管理

**Gstack做法**：
- 10-15个sprint同时跑在不同分支
- 每个sprint是独立的，有自己的生命周期

**Producer应该做**：
- 识别可以并行的任务，不要串行等待
- 每个并行任务有明确的owner和交付标准
- 用session管理不同任务的上下文

---

### 4. 范围决策（扩张/收缩）

**Gstack的4种模式**：
- **Expansion**：scope可以扩大
- **Selective Expansion**：只扩大某些部分
- **Hold Scope**：保持当前范围
- **Reduction**：缩小范围

**Producer应该做**：
- 项目开始时明确当前处于哪种模式
- 资源变化时主动调整模式
- 不要在收缩模式下做扩张的事

---

### 5. 定期反思（/retro）

**Gstack的/retro包含**：
- 每人产出分解
- 发布streak
- 测试健康趋势
- 成长机会

**Producer应该做**：
- 定期审视项目进度（不是等出问题时）
- 识别流程瓶颈
- 调整协作模式

---

## 行动项

- [ ] 阅读完整Overview：memory/knowledge/fw-gstack-overview.md
- [ ] 重点看 /office-hours 和 /plan-ceo-review 的设计思路
- [ ] 以后分配任务时，先挑战需求再分解
- [ ] 用6个强制问题审核每个接收到的需求

---

## 相关文件

- 总览：memory/knowledge/fw-gstack-overview.md
- Gstack原项目：https://github.com/garrytan/gstack


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