菜单
Use when the user wants to review an existing technical blog article, check article quality, or get feedback on a written piece. Triggers on "review this article", "check this post", "看看这篇文章有什么问题", "帮我 review 一下", or when given a file path to an article for quality feedback.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
技术设计文档 SOP——从需求到设计方案，产出 Markdown 文件到 workspace/demo_agent/output/
Manager 与用户对话澄清需求的思考框架（4 维：goal/boundary/constraint/risk）。当人类消息 classify=new_requirement 时**一定**加载本 skill。逐维评估覆盖度、一次问 2-3 个问题、全覆盖后转 requirements_write。所有'帮我做 X / 新需求'触发都走此 skill。
Manager 扫描并列出已有 SOP 集合的 skill。当用户问'有哪些 SOP / 流程'或 Manager 自检是否需新建 SOP 时**一定**加载本 skill。扫 workspace/manager/skills/sop_* 目录，读每个 SKILL.md frontmatter 的 description，组装成列表。所有'列一下现有流程'触发都走此 skill。
团队邮箱操作（读自己 inbox 或给其他角色发邮件）。直接调用 send_mail / read_inbox / mark_done 工具，不要手动操作 JSON 文件。
QA 在沙盒里执行 qa/test_plan.md 所有用例、收集失败、写 defect 的 skill。当 QA 收到 type=task_assign 且 subject 含'测试执行/run tests'的邮件时**一定**加载本 skill。按 test_plan 跑 pytest → 通过标 pass、失败写 qa/defects/defect_{id}.md → 汇总 qa/test_report.md + task_done。如有 defect，顺带发 task_assign 给 RD 修复。所有'QA 真的跑测试'的时刻走此 skill。
RD 按 tech_design.md 在沙盒里实现代码 + 单测 + 跑 pytest 通过。当 RD 收到 type=task_assign 且 subject 含'实现代码/code'的邮件时**一定**加载本 skill。五层分目录写代码 + 单测 ≥80% 覆盖 + 最多 3 次失败重试 → task_done 回 Manager。所有'开始写 feature code'的时刻走此 skill。
| name | review-tech-article |
| description | Use when the user wants to review an existing technical blog article, check article quality, or get feedback on a written piece. Triggers on "review this article", "check this post", "看看这篇文章有什么问题", "帮我 review 一下", or when given a file path to an article for quality feedback. |
系统性 review 技术博客文章，覆盖五个维度，以编号列表呈现问题，等待用户选择后再进行修改。不得在用户确认前擅自修改文件。
1. 读取文章文件
2. 按五个维度逐一分析
3. 输出优先级摘要（置顶）+ 详细问题列表
4. 等待用户选择编号
5. 仅修改用户选中的条目
用 Read 工具读取用户指定的文章文件。
必须覆盖以下全部五个维度，每个维度单独成节：
| 维度 | 检查重点 |
|---|---|
| 技术准确性 | 代码示例是否正确、概念是否有误、术语是否准确、数据/版本号是否会过时 |
| 表达清晰度 | 句子是否易读、专业术语是否有解释、示例是否直观 |
| 结构完整性 | 章节是否完整、逻辑是否循序渐进、是否缺少关键内容 |
| 语言风格 | 语气是否一致、是否符合目标读者、用词是否自然、配图风格是否与系列文章统一 |
| 逻辑合理性 | 论证是否有支撑、前后是否矛盾、结论是否过于武断 |
必须按以下格式输出，不得省略任何部分：
## Review 结果
### 优先关注（置顶摘要）
| 编号 | 问题简述 | 维度 | 优先级 |
|---|---|---|---|
| 1 | xxx | 技术准确性 | 高 |
| 3 | xxx | 逻辑合理性 | 中 |
---
### 技术准确性
**问题 1 — [简短标题]**
[说明问题所在，引用原文或代码]
建议修改：[具体修改方案]
（其他维度同理）
---
**请告诉我你想修改哪几条（输入编号即可，例如：1 3）。没有问题的维度可以不列出。**
收到用户的编号后，逐条修改文章文件，修改完每条后简要说明改了什么。
| 错误 | 修正 |
|---|---|
| 未覆盖全部五个维度 | 五个维度必须逐一分析，哪怕没有问题也要写"暂无明显问题" |
| 优先级摘要放在末尾 | 必须置顶，让用户先看到最重要的问题 |
| 没有明确邀请用户选择 | 最后一行必须是"请告诉我你想修改哪几条" |
| 分析完直接修改文件 | 必须等用户选择编号后才能修改 |
| 全篇只列问题不给建议 | 每个问题必须附上"建议修改"方案 |
| 忽略配图风格一致性 | 同一系列文章的架构图/流程图应保持统一的配色、形状和排版风格（参考 source/_posts/ai-agent-skill/flow.png 的视觉基准：浅灰背景、蓝色圆角矩形、绿色胶囊入口、粉色菱形判断、橙色虚线旁注） |
| 连接线穿越框体 | 流程图/架构图的连接线不得穿越任何节点框体，必须沿框体外侧绕行；线上的标注文字不得覆盖任何框体 |