Context Engineering 审查

从 context engineering 视角审查用户提供的内容，自动识别内容类型并选择最相关的审查维度，输出结构化审查报告。

工作流

Step 0: 获取审查目标

判定 $ARGUMENTS 的输入类型：

1. 文件路径：$ARGUMENTS 看起来是一个文件路径（含 / 或 . 扩展名）→ 用 Read 读取文件
2. Glob 模式：$ARGUMENTS 含通配符（*、**）→ 用 Glob 展开后逐一读取（上限 5 个文件，超出则优先入口文件和核心模块）
3. 直接内容：$ARGUMENTS 是一段代码或文本 → 直接作为审查内容
4. 空参数：$ARGUMENTS 为空 → 询问用户提供文件路径或粘贴内容

对于多文件输入，先用 Read 读取各文件，合并为审查内容。若总量过大（>500 行），用 Grep 扫描关键特征辅助判定，优先深入审查核心文件。

Step 1: 识别内容类型

阅读 references/content-type-rules.md 中的识别规则。

根据文件扩展名、文件名、内容关键词和结构特征，判定内容属于以下哪种类型：

1. Prompt 类 — AI 行为指令、系统 prompt、角色定义
2. Agent 代码类 — 使用 LLM 框架的代码实现
3. 架构文档类 — 系统架构、组件交互描述
4. 设计文档类 — PRD、RFC、技术方案
5. Skill/Workflow 定义类 — Agent skill 或工作流定义
6. 通用文本 — 无法归入以上类别

按规则优先级匹配，匹配到第一个即停止。若内容类型模糊难以判定，向用户确认后继续。

Step 2: 选择审查维度

根据 references/content-type-rules.md 中的维度选择映射矩阵：

1. 选定该内容类型的所有必选维度
2. 扫描内容中的具体特征，参照特征驱动的维度追加规则，从候选维度中选择与内容高度相关的 1-2 个
3. 确保最终维度数量在 3-5 个之间

向用户报告识别到的内容类型和选定的审查维度，然后继续。

Step 3: 逐维度审查

对 Step 2 选定的每个维度：

1. 阅读 references/dimension-checklist.md 中对应维度的段落（只读选定维度，不读全文）
2. 逐条对照检查清单审查内容
3. 记录每条发现并标注严重等级：
   • Critical — 将直接导致 context 失效、严重性能退化或系统性故障
   • Important — 影响 context 质量或效率，但不会导致系统故障
   • Suggestion — 优化建议，采纳后可提升 context 质量
4. 对每条发现提供具体改进建议，指向内容中的具体位置（行号或段落）

审查原则：

• 基于证据：每条发现必须指向内容中的具体位置
• 不凭空创造：检查点不适用时跳过，不勉强标注
• CE 专注：关注 context engineering 特有视角，不重复通用代码审查已覆盖的内容
• 对于非 AI/agent 相关内容：聚焦通用 context 原则（信息组织、结构化、注意力管理），在报告中注明

Step 4: 生成审查报告

阅读 references/report-template.md 获取报告模板，按模板格式生成完整报告。

报告包含：

• 基本信息（内容类型、审查维度、日期、输入来源）
• 审查总结（1-3 句整体评价）
• 逐维度发现（表格形式，含严重等级、位置、发现、建议）
• 统计（按严重等级计数）
• 改进优先级（Top 3-5，按影响排序）
• 推荐阅读（指向相关 CE skill）

Step 5: 质量核验

逐项检查，发现遗漏时回到对应步骤修复：

• 内容类型识别正确且有依据
• 选定维度数量在 3-5 个之间
• 每条发现都指向内容中的具体位置
• 每条发现都有对应的改进建议
• 严重等级分配合理（Critical 仅用于真正严重的问题）
• 未凭空创造不存在的问题
• 报告格式匹配模板
• 改进优先级按影响排序

Edge Cases

• 内容过短（<20 行）：减少维度至 2-3 个，报告精简化
• 内容过长（>500 行）：分段审查，先整体扫描结构，再对关键段落深入分析
• 非 AI/agent 相关内容：仍可从通用 context 原则审查（信息组织、结构化、注意力管理），在报告开头注明审查聚焦于通用 CE 原则
• 二进制或非文本文件：告知用户不支持，建议提供对应的文档或源码
• 文件不存在或不可读：报告错误并终止
• 混合类型内容：以主要文件类型驱动维度选择，在报告中注明涉及多种类型