ORANGE BOOK · CODEX

附录 C Skills 模板集

用法：mkdir -p ~/.codex/skills/<skill-name> 然后把对应的 SKILL.md 内容粘进去即可。

C.1 weekly-report（周报生成）

---
name: 周报生成
description: 根据本周日志和 git commit，生成一份按"完成/进行中/风险/下周"四块结构化的周报草稿
keywords: [周报, 周记, 周总结, weekly, report]
version: 1.0.0
author: orange-book
---

## 何时使用

- 用户说"写周报"、"我要写周报"、"帮我整理本周工作"
- 不调用：日报（用 daily-report Skill）、月报（用 monthly-report Skill）

## 输入

- 本周日志路径（默认 ~/Documents/work-log/）
- Git 仓库路径（如有，默认 ~/code/）
- 周报受众（默认"直属经理"）
- 是否包含数字（默认是）

如未提供，主动问。

## 步骤

1. 读取日志目录下日期为本周一到本周五的 .md 文件
2. 如有 Git 仓库，运行 `git log --since="last monday" --author="$(git config user.name)" --oneline` 获取本周 commit
3. 按四块整理：
   - 完成：3-5 件，按重要性降序，每件 1-2 行 + 数字依据
   - 进行中：列出 + 进度 + 预计完成日
   - 风险：列出 + 影响 + 应对方案
   - 下周计划：≤3 件 + 明确目标
4. 全文删除主观虚词："我觉得"、"应该是"、"可能"、"差不多"
5. 输出到当前目录 weekly-report-YYYY-WW.md（WW 为周数）

## 输出

- 文件：weekly-report-YYYY-WW.md
- 长度：300-600 字
- 风格：动词开头、客观、有数字

## 验收

- 4 块都不为空（如某项无，写"无"而非省略）
- 完成项每件有数字或"已完成"标识
- 下周计划 ≤3 件
- 没有主观虚词

C.2 meeting-minutes（会议纪要）

---
name: 会议纪要整理
description: 把会议录音转写或随手记录，整理成"决议/待办/风险/参考"四块的标准纪要
keywords: [会议纪要, 会议记录, 会议总结, meeting, minutes]
version: 1.0.0
---

## 何时使用

- 用户提供会议录音、转写文本、或会中速记笔记
- 用户说"整理会议纪要"、"会议总结"

## 输入

- 原始材料：录音转写文件 / 速记笔记 / 视频转写
- 会议元数据：时间、参会人、主题（如未提供主动问）

## 步骤

1. 通读原始材料
2. 抽取"决议"：会议达成的明确结论（不是讨论中的提议）
3. 抽取"待办"：每条标注 owner（必须有人）+ deadline（必须有日期）+ 完成标准
4. 抽取"风险"：会议中提到但未解决的问题
5. 抽取"参考"：值得记下的数据、链接、引用
6. 输出到当前目录 meeting-YYYY-MM-DD-{主题}.md

## 输出格式

```markdown
# 会议纪要 - {主题}

**时间**：{时间}
**参会**：{参会人}
**记录**：{记录人}

## 决议
- ...

## 待办

| 待办 | Owner | Deadline | 完成标准 |
|------|-------|----------|----------|
| ...  | ...   | ...      | ...      |

## 风险
- ...

## 参考
- ...

验收

  • 决议是"明确达成"的，不是"提到过"的
  • 每个待办有 owner + deadline
  • 风险项可执行（不是"要小心"这种空话）
  • 没有"大家说"、"有人说"等模糊主语，必须具名

## C.3 email-draft（邮件起草）

```markdown
---
name: 邮件起草
description: 根据收件人、主题、要点起草邮件，自动调整语气和长度
keywords: [邮件, email, 写邮件, 起草邮件, draft email]
version: 1.0.0
---

## 何时使用

- 用户说"帮我写一封邮件"、"起草邮件"、"draft email"

## 输入

需要从用户处获得：
- 收件人（关系：客户 / 上级 / 平级 / 下级 / 外部合作方）
- 主题
- 要点（1-N 条）
- 期望语气（正式 / 友好 / 紧急 / 道歉 / 感谢）
- 期望长度（一段 / 三段 / 详细）

如未提供，主动问最关键的（收件人 + 要点）。

## 步骤

1. 根据收件人关系调整称呼和语气
2. 第一段：开门见山说明邮件目的（≤2 句）
3. 中间段：按要点展开（用 bullet 或编号）
4. 结尾段：明确"我希望对方做什么"或"何时回复"
5. 签名（默认用用户的名字）
6. 自检：
   - 没有"应该是"、"可能"等模糊词
   - 没有错别字
   - 关键日期 / 数字醒目（加粗）
7. 输出邮件草稿（不发送）

## 输出

- 直接展示邮件正文
- 标注：收件人称呼、主题建议、附件提醒（如有）
- 提示用户检查后发送

## 验收

- 收件人关系适配（不要给客户发"哥们"）
- 长度跟要求匹配
- 末尾有明确"action item"
- 不出现敏感信息

C.4 code-review（代码评审）

---
name: 代码评审
description: 对一份 PR 或一段代码做四维度 review：安全、性能、可读性、规范
keywords: [code review, 代码评审, pr review, 评审]
version: 1.0.0
---

## 何时使用

- 用户提供 PR 链接、diff、或一段代码
- 用户说"review 一下"、"看看这段代码"、"check this PR"

## 输入

- 要 review 的内容（PR / diff / 文件 / 代码片段）
- 项目背景（参考项目根的 AGENTS.md）
- 重点关注的维度（默认全四维）

## 步骤

1. 通读代码，理解意图
2. 按四维度检查，每个维度给出问题（如有）：
   - **安全**：注入风险、敏感信息、权限漏洞、依赖漏洞
   - **性能**：明显的性能问题、N+1 查询、内存泄漏
   - **可读性**：命名、结构、复杂度、注释缺失
   - **规范**：是否符合项目 AGENTS.md 的规范、命名约定
3. 区分严重程度：
   - ❌ Blocker（必须改才能 merge）
   - ⚠️ Major（建议改）
   - 💡 Suggestion（可改可不改，只是建议）
4. 输出结构化 review 评论

## 输出

```markdown
## Review 结果

### 总评
{一段话总结}

### 必须修复（Blocker）
1. {问题} —— 文件 / 行号 —— 建议
...

### 建议修复（Major）
1. ...

### 优化建议（Suggestion）
1. ...

### 亮点
- {做得好的地方}

验收

  • 四维度都看了（即使没问题也说明"已检查"）
  • 严重程度分级清晰
  • 每个问题都有具体位置 + 建议改法
  • 同时指出"做得好的"，不只是挑毛病

## C.5 daily-news（每日行业新闻）

```markdown
---
name: 行业晨报
description: 抓取昨天的行业关键新闻，整理成 5 条要闻 + 简短点评
keywords: [晨报, 早报, brief, news, 行业新闻]
version: 1.0.0
---

## 何时使用

- 用户说"X 晨报"、"今日 X 新闻"、"morning brief"

## 输入

- 行业关键词（如 AI、新能源、消费、教育）
- 抓取范围：默认昨天（北京时间 0:00 - 23:59）
- 信息源：references/sources.md（按行业分类）
- 数量：默认 5 条

## 步骤

1. 用 In-App Browser 访问对应行业的信息源
2. 提取昨天发布的所有新闻标题
3. 按重要性打分（融资 > 产品发布 > 技术突破 > 观点 > 八卦）
4. 选 TOP 5
5. 每条生成：
   - 标题
   - 一句话要点（≤30 字）
   - 50 字点评（"为什么重要"，不是简单复述）
   - 出处链接
6. 输出整体简报到当前目录 brief-{行业}-YYYY-MM-DD.md

## 输出

```markdown
# {行业} 晨报 - {日期}

## 1. {标题}
**要点**：{一句话}
**点评**：{50 字}
**出处**：{链接}

...

验收

  • 5 条都有出处链接
  • 点评不是简单复述，要有"为什么重要"
  • 没有重复（同一事件不同来源算一条）
  • 标题准确，不夸张

## C.6 pdf-summary（PDF 总结）

```markdown
---
name: PDF 总结
description: 总结一份 PDF 文档，输出"核心论点 + 关键证据 + 推荐人群"
keywords: [PDF 总结, pdf summary, 文档摘要, 论文总结]
version: 1.0.0
---

## 何时使用

- 用户提供 PDF 文档
- 用户说"总结这个 PDF"、"summarize"、"摘要"

## 输入

- PDF 文件路径
- 期望长度（默认 500-800 字）
- 期望视角（默认"读者视角"，可选"批判视角"）

## 步骤

1. 读取 PDF 全文
2. 识别文档类型：论文 / 报告 / 书籍 / 文章 / 手册
3. 按类型抽取结构：
   - 论文：研究问题 / 方法 / 结论 / 局限
   - 报告：核心结论 / 关键数据 / 行动建议
   - 书籍：核心观点 / 论证脉络 / 适用读者
   - 文章：核心观点 / 主要论据 / 反对声音
4. 输出结构化总结
5. 末尾加"3 个延伸思考问题"

## 输出格式

```markdown
# PDF 总结：{标题}

**作者**：{...}
**类型**：{论文 / 报告 / 书籍 / ...}
**长度**：{X 页}
**推荐人群**：{...}

## 一句话总结
{核心论点}

## 核心观点
1. ...
2. ...
3. ...

## 关键证据
- ...

## 局限 / 反对声音
- ...

## 适合 / 不适合谁读
- 适合：{...}
- 不适合：{...}

## 延伸思考
1. ...
2. ...
3. ...

验收

  • 总结忠于原文，不胡编
  • 有"局限性"或"反对声音"段（避免片面）
  • 推荐人群具体（不是"所有人"）
  • 延伸思考问题开放、有深度

## C.7 commit-message（Git 提交信息）

```markdown
---
name: Git 提交信息
description: 根据 git diff 生成符合 Conventional Commits 的提交信息
keywords: [commit message, git commit, 提交信息]
version: 1.0.0
---

## 何时使用

- 用户即将 commit，需要提交信息
- 用户说"帮我写 commit message"、"commit msg"

## 输入

- 当前未提交的改动（运行 `git diff --staged` 获取）
- 项目类型（影响 type 选择）

## 步骤

1. 运行 `git diff --staged` 看本次改动
2. 判断改动类型（feat / fix / docs / refactor / test / chore / perf / style）
3. 判断 scope（如有清晰的模块边界）
4. 概括"做了什么"成 ≤50 字符的标题
5. 如果改动复杂，加 body（说明"为什么"，不是"做了什么"）
6. 如果是 breaking change，加 `BREAKING CHANGE:` footer

## 输出

{type}({scope}): {简短描述}

{可选的详细说明，解释为什么}

{可选的 BREAKING CHANGE / Closes #xxx}


## 例子

简单：

feat(auth): add OAuth2 google login


复杂：

refactor(api): split user service into auth and profile

之前 UserService 同时负责认证和资料管理， 随着功能增加，类越来越大且测试困难。 拆成 AuthService + ProfileService 后， 每个服务职责单一，单测覆盖率从 60% 提到 90%。

Closes #234


## 验收

- type 准确（不要把 feat 写成 chore）
- 标题动词开头，现在时（add 不是 added）
- 标题 ≤50 字符
- body（如有）解释"为什么"
- 引用相关 issue / PR

C.8 readme-generator（README 生成）

---
name: README 生成
description: 给一个项目生成一份完整的 README.md，含介绍、安装、使用、配置、贡献指南
keywords: [README, readme generator, 项目文档]
version: 1.0.0
---

## 何时使用

- 用户提供项目目录
- 用户说"给我项目写个 README"、"generate README"

## 输入

- 项目根目录路径
- 项目类型（库 / 应用 / 工具 / 文档站）
- 目标读者（开发者 / 用户 / 两者）

## 步骤

1. 扫描项目结构（看 package.json / requirements.txt / Cargo.toml 推断技术栈）
2. 看现有的 README（如有）和 AGENTS.md
3. 看 src/ 主要文件理解项目做什么
4. 按下面结构生成 README

## 输出格式

```markdown
# {项目名}

> {一句话定位}

[![License]({...})] [![Version]({...})] [![Tests]({...})]

## 这是什么

{1-2 段，回答"做什么 / 解决什么问题 / 跟同类工具区别"}

## 截图 / Demo
（可选）

## 快速开始

```bash
# 安装
{install command}

# 跑起来
{run command}

详细文档

安装

...

配置

...

使用

...

例子

{2-3 个真实例子，从简到难}

API / CLI 参考

（如果是库 / CLI 工具）

开发

# clone
git clone ...

# 装开发依赖
...

# 跑测试
...

贡献

欢迎 PR！请遵守：

  • ...

License

{...}


## 验收

- 一段话能回答"这是啥"
- 快速开始能 5 分钟跑通
- 例子能直接复制运行
- 没有 "TODO" 占位（要么有内容，要么先不放该段）

C.9 translate-zh-en（中英互译）

---
name: 中英互译
description: 把文本在中英文之间翻译，自动适配技术 / 商务 / 文学等领域语气
keywords: [翻译, translate, 中译英, 英译中]
version: 1.0.0
---

## 何时使用

- 用户提供文本要求翻译
- 用户说"翻译"、"中译英"、"英译中"、"translate"

## 输入

- 待翻译文本
- 翻译方向（auto-detect / zh→en / en→zh）
- 领域（技术 / 商务 / 文学 / 日常，默认 auto-detect）
- 术语表：references/glossary.md（可选）

## 步骤

1. 检测原文语言和领域
2. 如有 references/glossary.md，加载对应领域的术语映射
3. 翻译时优先使用术语表
4. 适配语气：
   - 技术 → 准确、术语统一
   - 商务 → 正式、礼貌
   - 文学 → 流畅、有韵律
   - 日常 → 自然、口语
5. 翻译完做反向自检（中→英→中，看是否走样）
6. 输出译文 + 标注的术语 + 翻译说明

## 输出

译文

{翻译后的文本}

用到的术语

  • 原文术语 → 译文术语（来自 glossary）
  • ...

翻译说明

（如有取舍：意译了哪部分、为何选择 X 译法）


## 验收

- 术语跟 glossary 一致
- 没有漏译
- 没有错译（关键数字 / 名字保持原样）
- 中文译文符合中文表达习惯，不是"翻译腔"
- 英文译文符合英文表达习惯，不是 Chinglish

C.10 onboarding（新人入职辅导）

---
name: 新人入职辅导
description: 给新加入团队 / 项目的人提供"今天学什么 / 接下来一周做什么"的引导
keywords: [入职, onboarding, 新人, 入门, 上手]
version: 1.0.0
---

## 何时使用

- 新人加入团队 / 项目第一周
- 用户说"我刚加入"、"我是新来的"、"onboarding"

## 输入

- 新人角色（开发 / PM / 设计 / 运营 / ...）
- 加入的项目 / 团队
- 已有的相关经验（年限、之前用过的栈）

## 步骤

1. 读项目根的 AGENTS.md 和 README.md
2. 读 docs/onboarding/（如有）
3. 根据角色生成"第一天 / 第一周 / 第一个月"的清单
4. 每个清单项给：
   - 任务描述
   - 资源链接（项目内的文档 / 外部教程）
   - 完成标准
   - 找谁问

## 输出

```markdown
# {新人名} 的入职 Roadmap - {项目名}

欢迎加入！下面是你第一个月的引导。每天检查一下进度。

## 第 1 天：环境与认知
- [ ] 通读 README.md
- [ ] 通读 AGENTS.md，了解项目规则
- [ ] 装好开发环境（步骤见 docs/setup.md）
- [ ] 跑起来项目（验收：浏览器看到首页）
- [ ] 跟 mentor 1:1（30 分钟）

## 第 2-3 天：探索
- [ ] 跑通完整测试（pnpm test）
- [ ] 读 src/ 主要模块，画出依赖图（mermaid 格式）
- [ ] 找 3 个你看不懂的地方，列到 questions.md

## 第 4-5 天：第一个改动
- [ ] 找一个 "good first issue" 标签的 issue
- [ ] 在新分支实现
- [ ] 开 PR，请 mentor review

## 第 2 周：独立完成 1 个 ticket
- [ ] 选一个中等大小的 ticket
- [ ] 完整流程跑一遍：理解需求 → 设计 → 实现 → 测试 → PR

## 第 3-4 周：扩展贡献
- [ ] 完成 2-3 个 ticket
- [ ] 给项目文档提一个改进
- [ ] 一对一回顾 onboarding（这个 Roadmap 哪里需要改）

## 谁可以问
- 技术问题：@tech-lead
- 业务问题：@product-manager
- 流程问题：@mentor
- 用什么工具：本 AI 副驾驶

验收

  • 任务从"读 → 跑 → 改"逐步深入
  • 每天 1-3 个任务，不会过载
  • 每个任务有完成标准
  • 有"找谁问"清单
  • 末尾有"反馈循环"（让新人回头评价 onboarding）

---

## 安装这 10 个 Skills 的脚本

```bash
#!/bin/bash
# install-skills.sh
# 一键安装本附录的 10 个 Skills 到 ~/.codex/skills/

SKILLS_DIR="$HOME/.codex/skills"
mkdir -p "$SKILLS_DIR"

for skill in weekly-report meeting-minutes email-draft code-review \
             daily-news pdf-summary commit-message readme-generator \
             translate-zh-en onboarding; do
    mkdir -p "$SKILLS_DIR/$skill"
    echo "创建 $skill 目录"
    # 把对应 SKILL.md 内容写进去
done

echo "10 个 Skills 已就绪。重启 Codex 让它加载。"

怎么扩展自己的 Skills

下面这套"问 Codex"模板帮你快速建新 Skill：

我想做一个 Skill，做以下任务：
[描述任务]

请帮我：
1. 写一份 SKILL.md，按附录 C 的标准结构
2. 生成 keywords 和 description（让 Codex 能精准识别何时调用）
3. 列出验收标准
4. 建议是否需要 references / scripts / assets

放到 ~/.codex/skills/{你建议的名字}/ 下

Codex 会照办。你审一下，commit 进自己的 skills 仓库。