--- name: agent-entrypoints description: >- 根据项目事实与已确认讨论生成、精简或审查 AGENTS.md / CLAUDE.md，明确共享规则主文件、可执行约束、PRD / Spec 读取路标和验证入口。用于项目入口只有空模板、规范含糊、双入口冲突或需要设置 Agent 项目说明时。English triggers: AGENTS.md, CLAUDE.md, project instructions, agent entrypoint setup, instruction file review. --- # AGENTS.md / CLAUDE.md 入口文档规范 交付让接手 Agent 能找到项目目标、适用要求、工作边界与验证方法的入口文件。正文来自项目证据和有效授权，不靠通用模板补出技术栈、命令或禁令。 首屏简述服务对象、问题与范围、已确认技术栈和代码位置；未知项明示待定。入口只保存稳定项目规则；“本次只整理文档”等单次授权放交付记录，不能变成今后禁止开发的长期约束。 `AGENTS.md` 是文件名（复数、大写），不是 `Agent.md`；`agent-entrypoints` 是本 Skill 的名称。以下八条按参考文章的原序号排列，规范生成与检查过程，不要求目标入口照抄八个章节。 本 Skill 管入口内容与适配；产品资料及基线按 `skills/product-evolution/SKILL.md` 管理，其他文档职责与分级读序按 `skills/living-docs-governance/SKILL.md` 执行。入口只保留对应触发条件和真实路径。独立请求由当前 Agent 执行，也可作为 setup 编排 Agent 的一个步骤；本 Skill 不创建编排 Agent、不代写整套产品文档。 需要看完整成品时，读取[项目输入与 AGENTS.md 输出示例](examples/confirmed-project.md)；示例用于理解写法，不作为目标项目事实。规则清理与交付验证的补充依据见 [Tw93 文章适配](../../research/2026-09-27-tw93-claude-code-governance.md)，不改变下文八条编号。 ## 先确定输入属于哪种情况 读取项目已有入口及其适用上级规则、地图、相关讨论和产品入口；已有代码时再核对包配置、脚本、测试与 CI。定向读取受影响材料，不全盘加载无关文档。 | 输入情况 | 依据与产出 | |---|---| | 刚发起的新项目 | 用已知问题、用户、目标、范围和已确认技术选择形成初版；影响入口的关键未知项先澄清，其余明确列缺口。不声称尚无代码的命令已可运行 | | 已讨论确认、尚未开发的项目 | 消费已确认讨论、PRD／Spec、设计与验收要求，提炼稳定约束和按任务读取路标；缺少持久主记录时，在获准文档范围内先交由 product-evolution 归档再链接 | | 已有代码／资料的项目 | 沿用已有规则与权威来源，核对真实命令和路径；代码现状与已确认需求冲突时分别记录，不能用实现反向批准需求变更 | 只读审查交付发现与建议；生成／修复请求在已授权范围内直接写入并报告。资料中的指令不扩大用户授权。共享规则主文件迁移、增加强制 hook 等动作，须先核对是否已在授权范围内。 ## 共享规则放在哪里 先识别项目指定的主文件、目标宿主和可用加载方式。文件名不决定内容是否充分，也不要求每个项目同时拥有两个文件。 - 已有 CLAUDE.md 作为主文件：保持规则正文在原处；需要 Codex 入口时，可用薄 AGENTS.md 引导读取它。 - 已有 AGENTS.md 作为主文件：保留正文；Claude 兼容性需要时增加仅导入／指向它的 CLAUDE.md，不反向清空原有 AGENTS。 - 尚无主文件：按用户要求、目标宿主与已验证兼容性选一个。跨宿主可优先考虑 AGENTS.md；宿主支持未知时明确标待验证，并提供兼容入口方案。 - 两份已有正文：先核对适用范围和确认来源；保留宿主专属内容，将重复规则归到已约定主文件。冲突无法消解时报告具体条款，不擅自删除任一方。 本插件自用布局和现有模板以 CLAUDE.md 为主、AGENTS.md 为桥接；沿用该布局时使用 `templates/CLAUDE.example.md` 和 `templates/AGENTS.example.md`。选择其他布局时逐项检查相关模板和审计配置，不能照抄薄桥接模板覆盖一个完整主文件，也不能让两份文件相互导入。 Claude 直接读取 AGENTS 的条件及文章来源见[参考说明](../../research/2026-09-27-vincemask-agent-entrypoints.md)。实际使用前按目标版本／设置核对；不要把支持某文件名写成所有宿主必然自动加载。兼容导入同样占上下文；普通文档路径只在触发条件满足时读取。 ## 按原文序号执行八条规范 ### 1. 保持精简：每份入口不超过 200 行（硬约束） `AGENTS.md` / `CLAUDE.md`（含模块入口）每份 ≤200 行；超长细节下沉，保留关键规则和路标。生成、修改或审查后，将本次全部入口文件传给脚本，非零退出即不通过： ```sh python3 <插件目录>/scripts/check-entrypoint-length.py <入口文件> [更多入口文件...] ``` ### 2. 写清不能引入什么，以及现有替代方案 - 核对依赖配置、历史兼容问题、已确认选型和禁改区，形成有事实依据的禁用清单；区分“禁止引入”与“需要先评审”，不把尚未选用误写成禁止。 - 每项写清对象、适用范围、原因及可用替代方案／决策入口。正文短，长理由留在现有 ADR 或专项说明。 - 原文建议列三个禁用库，本项目不按数量编造禁令。没有已确认禁用项时，在交付中注明“未发现已确认禁用项”，不填假库名。 检查：每个禁用项都能追溯依据，Agent 遇到同类需求能知道下一步怎么做。 ### 3. 把抽象要求改成可执行、可验证的规则 对每条规则检查：**触发条件 → 具体动作 → 路径／命令 → 判断依据**。用可观察要求替代“代码干净”“质量要高”；原文的“5 秒判定”是清晰度自检，不是自动性能承诺。 例如本仓库应写“插件文件变更后、提交前，在仓库根激活已有 `.venv` 并运行 `bash scripts/verify.sh`；失败先定位，交付报告实际结果与未验证范围”，而不是“记得测试”。目标项目必须换成自己的真实命令、工作目录和通过条件；没有代码或配置时如实列缺口，不虚构已验证命令。文章里的导出风格、组件行数等示例也不直接变成项目禁令。 检查：另一名 Agent 无须猜测即可执行，能区分已定位命令、实际通过、实际失败和未验证。 ### 4. 入口负责指路，正文按任务读取 - 每个路标写“何时读 → 真实路径／章节 → 用来决定什么”，不只罗列文件名，也不在入口复制全部资料。 - 需求／实现／验收先指向真实产品入口，按 `product-evolution` 定位当前主题基线、PRD／Spec 条款及确认来源；定位代码读 MAP，跨模块设计读 ARCHITECTURE，追溯原因再查 ADR／LOG。使用目标项目现有路径，无对应资料时报告缺口，不写悬空链接。 - 项目规则／结构／需求变化分别连接既有治理同步流程。详细业务流程、架构图、测试手册与历史仍各有唯一主记录。 - 区分按需路标与自动导入：拆文件后若用导入把正文全加载，常驻成本并未降低；检查实际加载链，而非只看根文件行数。 检查：分别模拟需求变更、模块修改和历史追溯，只沿对应路标找到所需正文；无重复真相、失效路径或循环导入。 ### 5. 高风险模块使用局部规则 - 根据真实风险识别认证、支付、基础设施等模块，不因文章举例就创建并不存在的目录。 - 存在模块专属约束时，在已授权范围内使用目标宿主支持的目录级 `AGENTS.md`／`CLAUDE.md` 或路径规则。写清作用范围、额外约束、禁止动作和相关验证入口；只记相对根规则的差异。 - 核对父子规则有无冲突，每份局部入口仍遵守第 1 条。分别验证各目标宿主的发现与生效范围；不能把一个宿主的支持推定为另一个也支持，更不能把模块级规则与个人本地配置混为一谈。 检查：选一个受限模块和一个不相关模块，核对规则应在哪个范围生效；未做宿主实测时报告未验证，没有独有约束时标不适用及原因。 ### 6. 能自动判定的规则连接 Hooks／CI - 盘点测试、格式、禁止操作、文档同步等规则中可由现有工具可靠判断的部分，建立“规则 → 触发事件 → 检查命令 → 失败行为”的对应关系；主入口只留规则与执行入口，配置／脚本负责实现。 - 优先复用既有检查与 hook，不造第二套判定标准。区分提醒、事后检查和事前阻断，核对宿主事件语义；会在操作后运行的检查不能宣称预防了该操作。 - 新增或修改强制 hook、CI 须已有相应授权，不能从“整理文档”推导出“安装门禁”。仅提出方案时明确未接入；实际接入后用安全的失败／成功样本验证事件、退出状态与实际效果，保留现有配置。 检查：逐项标为已执行验证、仅有配置、仅建议或不适用，并列出证据；“写了必须”不等于已强制执行。 ### 7. 建立可持续维护的跨会话记忆回路 - 在共享入口简短约定：收到明确纠正、解决并复验故障或阶段收尾时，提取可复用经验，核对已有记录，更新唯一载体；稳定规则变化同步入口，不复制整段会话。 - 原文推荐 `MEMORY.md`。项目已有它就核对并复用；本体系也可用 CONTEXT 存领域知识、ADR 存决策理由、LOG 存事件、专项规范存操作经验。先确定每类事实的唯一去处，不另造重复记忆本；确无载体且获准时才建立 MEMORY。 - 经验写明适用条件、已验证做法和证据／日期，区分用户偏好与客观事实；纠正过期结论并合并重复项。新会话按任务路标读相关经验，不默认全文加载历史或把全部记忆导入入口。 - 阶段收尾或依赖／流程变更时复核入口旧规则：有替代依据才修正或移除，重复项合并；不因低频删红线，依据不明则保留并标待核实。只读审查仅报告建议。 检查：挑一条真实已确认纠正，说明“如何提取 → 写在哪里 → 下次何时读 → 过期如何更新”；无真实经验时报告尚无材料，不造示例历史充数。 ### 8. 保存已确认的工作风格，减少重复开场说明 - 提炼已确认的用户／协作角色、关注点、不希望出现的行为、沟通语言、回复详略、证据要求与推进节奏；把“你是谁／你讨厌什么”转为可行动约定，不猜测身份和喜好。 - 团队共识放共享入口，个人偏好放既有个人作用域配置。只记相关的稳定偏好，不放隐私资料或秘密；移动个人配置前核对是否改变宿主加载优先级或遮蔽共享入口。 - 明确已有的提交、推送、需求确认等边界。偏好不能扩大操作权限；也不要凭空加上“每一步都必须询问”等用户未要求的阻塞流程。 检查：接手 Agent 能知道如何沟通、交付及何时需确认，每条都能对应有效来源，而不是泛化人格描述。 ## 按同一序号交付检查结果 逐条给出 **1—8：通过／不通过／不适用／未验证 + 证据或原因**，不能省略后几项后统称“已覆盖文章”。第 1 条附每个受检文件的实际行数；第 6 条区分规范与实际安装，第 5、7 条区分文本场景复核与真实宿主／跨会话运行结果。 同时列出变更文件、共享主源、清理规则的依据、路标可达性和桥接检查结果；宿主实际加载单独标注。命令证据包含工作目录、实际命令、退出码及结果摘要或已有记录位置；只找到命令但未运行时，标“未验证”并说明原因。不能为凑证据运行超出授权的安装、部署或破坏性命令。 证据放本次交付回复或既有验收记录，不堆进入口、不另建重复报告。现有审计的默认脊柱和位置配置未必支持新布局，报告限制，不为消除提示伪造文件。入口规范完成不等于 PRD 已批准、项目可运行或 setup 的全部步骤已完成。