代理就绪度审计
对照以下清单审计当前仓库，并报告差距。此为只读审计：绝不修改、创建或删除仓库文件。
第1步：发现技术栈
在判断任何事项之前，先识别：
- 语言、框架、包管理器、单体仓库结构
- 使用的 linter、formatter 和 typechecker
- 测试运行器
- 钩子管理器（husky、lefthook、pre-commit、simple-git-hooks、普通 .git/hooks）
- CI 系统及其配置
- 代理指令文件（AGENTS.md、CLAUDE.md、.cursorrules、copilot-instructions 等）
- 包含技能、runbook、提示词或工作流文档的目录
使用仓库实际使用的工具进行评估。除非当前工具无法胜任，否则不建议更换工具。
预算
- 从目录列表、配置文件和指令文件开始。使用 grep、计数和文件列表，而不是完整阅读源代码文件。
- 对每个主要包最多抽样3个代表性文件。
- 如果仓库过大无法覆盖，说明哪些部分未被检查。
第2步：评估每个清单项
每项分配一个状态：
- PASS：清晰到位且有效
- PARTIAL：存在但不完整、过时、未强制执行或不一致
- MISSING：你检查了但不存在
- N/A：不适用于此技术栈（说明原因）
- UNCLEAR：无法检查（说明阻碍因素，如外部CI或仓库部分未检查）
每条状态需要提供证据：文件路径、配置键或简短引用片段（每条不超过15词）。绝不猜测：如果你检查了但没找到，标记 MISSING；如果无法检查，标记 UNCLEAR。
清单
-
共享代理指令
- 所有代理和新工程师都读取的单一根级指令文件
- 涵盖代码风格规则（导出风格、导入结构、文件组织、反模式）
- 要求在信任边界验证外部数据
- 说明哪些测试值得编写
- 定义完成门禁：lint、typecheck 和相关测试必须在提交前通过
- 当前且具体。抽查3到5条规则与实际代码对比，并报告代码是否遵循
-
仓库中的工作流技能
- 将重复性工作流以分步技能或 runbook 形式记录在代码旁
- 覆盖范围：提交、打开/堆叠PR、代码审查、通过CI的PR流程、依赖变更、本地化
- 覆盖特定技术栈的工作流（数据层、路由、设计系统、代码生成等）
- 每个技能包含触发器、有序步骤和完成定义
- 技能是唯一真实来源，不重复也不矛盾
-
约定通过 lint 规则强制执行
- 文档化的约定有匹配的 lint 规则
- 自定义 lint 规则或插件覆盖项目特定用法（数据获取、样式、测试、翻译）
- 针对常见代理错误的反模式规则：链式或不必要的类型断言、松散类型参数（unknown/any）、空对象条件展开，以及代码库中发现的任何重复低质量模式
- 规则是错误级别，非警告级别，且无全局禁用
-
自动化门禁
- 预提交钩子格式化、lint 和 typecheck 更改的代码
- 预推送钩子 lint 或测试受影响的包，包括依赖项
- CI 重新运行相同检查，因此钩子无法绕过
- 钩子速度合理
- 钩子已接线：钩子配置已提交，存在安装步骤（prepare 脚本、设置文档或 core.hooksPath），且其所调用的命令存在。通过读取文件验证；绝不运行钩子
-
监督与结构
- 架构决策已文档化
- PR 审查要求在合并前（如果可见，检查分支保护或 CODEOWNERS）
- 包和模块边界清晰且已强制执行
第3步：发现未文档化的约定
抽样代码以寻找虽被一致应用但未写在任何地方的模式，以及代理常搞错但未文档化的模式（松散类型、未经验证的外部数据、不一致的导出、重复逻辑）。列出最优先添加到指令文件或转为 lint 规则的前5个候选。
第4步：报告
输出：
- 总结表：项目、状态、一行证据
- "差距"部分：每个 PARTIAL、MISSING 或 UNCLEAR 项、问题是什么以及为何对代理可靠性重要
- 按优先级排序的推荐列表（最高杠杆率优先），每个包含具体下一步和大致工作量（小/中/大），以该仓库现有工具的角度表述
- 第3步中的前5个约定候选
直截了当。不要用夸奖填充。如果某件事没问题，说 PASS 然后继续。
报告后，主动提供搭建缺失部分的帮助（入门指令文件、技能模板、lint 规则存根），但在被要求之前不要创建任何内容。