Context Engineering 审查
从 context engineering 视角审查用户提供的内容，自动识别内容类型并选择最相关的审查维度，输出结构化审查报告。
工作流
Step 0: 获取审查目标
判定 $ARGUMENTS 的输入类型：
- 文件路径：
$ARGUMENTS看起来是一个文件路径（含/或.扩展名）→ 用 Read 读取文件 - Glob 模式：
$ARGUMENTS含通配符（*、**）→ 用 Glob 展开后逐一读取（上限 5 个文件，超出则优先入口文件和核心模块） - 直接内容：
$ARGUMENTS是一段代码或文本 → 直接作为审查内容 - 空参数：
$ARGUMENTS为空 → 询问用户提供文件路径或粘贴内容
对于多文件输入，先用 Read 读取各文件，合并为审查内容。若总量过大（>500 行），用 Grep 扫描关键特征辅助判定，优先深入审查核心文件。
Step 1: 识别内容类型
阅读 references/content-type-rules.md 中的识别规则。
根据文件扩展名、文件名、内容关键词和结构特征，判定内容属于以下哪种类型：
- Prompt 类 — AI 行为指令、系统 prompt、角色定义
- Agent 代码类 — 使用 LLM 框架的代码实现
- 架构文档类 — 系统架构、组件交互描述
- 设计文档类 — PRD、RFC、技术方案
- Skill/Workflow 定义类 — Agent skill 或工作流定义
- 通用文本 — 无法归入以上类别
按规则优先级匹配，匹配到第一个即停止。若内容类型模糊难以判定，向用户确认后继续。
Step 2: 选择审查维度
根据 references/content-type-rules.md 中的维度选择映射矩阵：
- 选定该内容类型的所有必选维度
- 扫描内容中的具体特征，参照特征驱动的维度追加规则，从候选维度中选择与内容高度相关的 1-2 个
- 确保最终维度数量在 3-5 个之间
向用户报告识别到的内容类型和选定的审查维度，然后继续。
Step 3: 逐维度审查
对 Step 2 选定的每个维度：
- 阅读 references/dimension-checklist.md 中对应维度的段落（只读选定维度，不读全文）
- 逐条对照检查清单审查内容
- 记录每条发现并标注严重等级：
- Critical — 将直接导致 context 失效、严重性能退化或系统性故障 - Important — 影响 context 质量或效率，但不会导致系统故障 - Suggestion — 优化建议，采纳后可提升 context 质量
- 对每条发现提供具体改进建议，指向内容中的具体位置（行号或段落）
审查原则：
- 基于证据：每条发现必须指向内容中的具体位置
- 不凭空创造：检查点不适用时跳过，不勉强标注
- 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 原则
- 二进制或非文本文件：告知用户不支持，建议提供对应的文档或源码
- 文件不存在或不可读：报告错误并终止
- 混合类型内容：以主要文件类型驱动维度选择，在报告中注明涉及多种类型