菜单
用于审查当前仓库已有治理资产是否写乱层、放错位置或职责串位，尤其适合“检查当前规则是不是写乱层了”“审查 AGENTS、skills、scripts、hooks、rules 放得对不对”“看看哪些治理内容放错位置了”“给我当前仓库的分层整改建议”“检查运行时规则、hooks 和 rules 是否配置在合适的位置”这类场景。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
用于在一次任务、一次需求沟通或一次会话结束后，对刚产生的经验、错误、教训、规则或流程做分诊：判断这条内容是否值得沉淀、为什么会反复出现、应该放到哪一层，以及在当前仓库里应落到 AGENTS.md、目录 README、skill、脚本/checker、hook 候选，还是正式主定义文档。适用于“总结这次会话经验”“记录一个经验/教训”“记住这个错误/教训”“为什么重复出错”“这个问题应该放到哪”“这条规则该写到哪里”“这个流程该做成什么”等场景。
用于在本仓库生成或修改后台原型效果图，尤其是 04-原型效果图/后台管理 下的 HTML 页面，并要求优先复用已有公共组件。适用于“生成原型效果图”“新建原型页”“调整原型页面”“补一个页面状态”“统一原型样式”“组件化原型”“替换为公共组件”等场景。
| name | layer-governance-audit |
| description | 用于审查当前仓库已有治理资产是否写乱层、放错位置或职责串位，尤其适合“检查当前规则是不是写乱层了”“审查 AGENTS、skills、scripts、hooks、rules 放得对不对”“看看哪些治理内容放错位置了”“给我当前仓库的分层整改建议”“检查运行时规则、hooks 和 rules 是否配置在合适的位置”这类场景。 |
用于主动审查当前仓库已有治理资产的分层治理现状。
data-governance-layer-triage 的职责是给新经验找归宿；layer-governance-audit 的职责是检查现有治理资产的归宿是否合理。
这个技能只审、不改，不负责新经验首次落点，不审过程文档，也不审业务主定义本身。
.codex/rules/ 里的规则放得对不对”上述场景应改用 data-governance-layer-triage 或其他业务/文档工作流。
AGENTS.md，必要时 CLAUDE.mdREADME.md.codex/skills/*/SKILL.md06-工具脚本/README.md 与相关 .py 脚本.codex/config.toml 与 .codex/hooks/*.py.codex/rules/*.rulessettings 配置，再作为例外审计对象明确排除：
03-工作台/*00-项目总览/01-产品架构/02-PRD文档/90-归档记录/原因：本技能只审协作治理资产、项目级 rules、仓库级 hooks 和运行时治理配置，不审过程内容，也不审业务主定义本身。
按以下顺序执行：
AGENTS.md，确认顶层默认层是否承载了不该放在这里的内容。CLAUDE.md，确认它是否仍然只是引用或兜底，而不是形成独立规则集。04-原型效果图/后台管理/README.md04-原型效果图/后台管理/assets/README.md06-工具脚本/README.md.codex/skills 下技能，检查哪些本应上移、下沉或拆分。06-工具脚本/README.md，必要时再读相关 .py 脚本。.codex/rules/*.rules；当前仓库相关 rules 默认应沉淀在这里，并优先在该目录下审计。~/.codex/rules/*.rules 是否存在；用户级 rules 不作为主审计对象，只用于提示是否可能覆盖项目级意图、是否存在重复 prefix_rule、以及是否把本应项目私有的规则错误放在用户层。.codex/config.toml，确认 hooks 配置是否与当前治理分层一致。.codex/hooks/*.py，查看当前 hooks 脚本是否承担了正确职责；如果当前仓库使用 dispatcher hook，还要确认它是否按路径映射把检查分流到 repo / workbench / prd / prototypes，而不是对所有 Edit|Write 一律跑同一类检查。settings 配置；若存在，再判断这些 runtime config 是否真的必要、是否与 rules / hooks 职责重叠。验证项目级 .rules 时，优先使用 codex execpolicy check --rules .codex/rules/<file>.rules -- <command> 查看命中结果。
验证 hooks 时，先确认 .codex/config.toml 可正常解析，再确认 hook 脚本命中后是否返回预期的 hookSpecificOutput.additionalContext；如果是 dispatcher hook，还要验证不同路径是否映射到正确 scope，以及多 scope 输出顺序是否稳定。
不要默认运行 python 06-工具脚本/run_checks.py --scope ...。只有用户明确提到检查结果、结构告警或希望结合 Sensor 时，才按需参考脚本结果；且脚本结果只能作为辅助输入，不能代替分层判断。
按以下维度判断：
顶层默认层是否合理。
检查 AGENTS.md / CLAUDE.md 是否混入局部规则、多步流程、实现细节、专题检查；是否遗漏了已经应该上移的通用约束。
路径作用域层是否合理。
检查只对局部目录生效的规则是否被错误放到了全局；检查目录 README.md 是否承担了错误职责、重复顶层规则，或错误承担 workflow 职责。
skill 层是否合理。
检查 .codex/skills 中的技能是否真的是多步流程、专题检查或分支判断；检查哪些技能经验已经反复复用，应上移到 AGENTS.md；检查技能正文是否承担了目录规则、脚本说明或运行时规则职责。
执行层是否合理。 检查哪些真实执行动作仍只是提醒；检查哪些内容应升级为脚本、CLI、MCP 或 checker，而不是继续停留在文档里。
hook 层是否合理。
检查哪些零例外动作仍没进入仓库级 hooks；检查现有 hooks 配置和 hooks 脚本是否承担了不该承担的事，是否按路径映射做了正确分流，或是否把所有 Edit|Write 都粗暴压到同一类检查。
rules 层是否合理。
检查项目相关命令控制是否优先写在项目级 .codex/rules/；检查是否把本应仓库私有的规则错误放到用户级；检查项目级与用户级是否存在重复、冲突或覆盖；检查 .rules 是否承担了不该承担的职责，例如本应进 hooks、AGENTS.md、skill 或项目级 runtime config 的内容；检查是否存在过宽 prefix、规则漂移或职责串位。
runtime config 层是否合理。
当前仓库默认不应存在项目级 runtime config；如果例外新增了 settings 配置，检查这些运行时配置是否真的必要，是否与 rules / 仓库级 hooks 职责重叠，或是否形成新的历史兼容层。
写法是否合理。 检查重复、空话、过时、职责混杂、出口不清、文档或配置承担过重等问题。
必须使用以下格式输出：
【审计范围】
简要说明本轮读了哪些层和哪些关键文件，并说明是否读取了项目级 .codex/rules/ 以及是否发现用户级 ~/.codex/rules/。
【错层项清单】
逐条列出：
【治理升级候选】
分别列出：
AGENTS.mdREADME.mdskillhookscript/checker.codex/rules/【写法问题清单】
列出不是错层、但需要收紧写法、配置方式或职责边界的问题。
【本轮建议动作】
只给 3 到 5 条本轮最值得做的动作，按优先级排序。
run_checks.py；只有用户明确要求结合 Sensor 时才按需参考data-governance-layer-triage 的职责~/.codex/rules/ 当成当前仓库相关 rules 的默认主承载位；项目相关 rules 默认应优先进入 .codex/rules/