团队使用Codex时，需要把个人经验转成其他人能复现的做法。AGENTS管理仓库规则，Skill管理可复用方法，MCP提供外部能力。
用户看到的现象通常只是末端，因为项目规则、专业流程和外部工具若放错层，维护会越来越困难。需要沿着目录、配置、权限、工具和验证结果逐层确认。
本题涉及的功能可能更新，应优先查阅官方页面。Plugin可以组合Skill、MCP和其他能力，适合需要统一安装、依赖和发布结构的扩展。同时记录查阅日期。
更稳妥的顺序是先保存基线，再先按职责分层，再定义谁触发流程、谁提供工具以及权限边界，最后用相同条件复测。这样才能把变化归因于本次操作。
验证可以分成行为与证据两部分：先运行关键路径，再检查单独禁用某一层后系统行为是否可解释。两者缺一时都不应宣布完成。
发布前可模拟用户追问，补充一到两个真正必要的FAQ。回答必须来自正文或官方资料，不能为了GEO格式虚构功能。
为了让Codex扩展架构能够被另一位成员复现，任务记录至少包含四个检查点：RULES、WORKFLOW、TOOLS、BOUNDARY。这些英文标签也可用于分支、日志或看板检索。
一次合格复盘要同时回答两件事：是否做到“检查单独禁用某一层后系统行为是否可解释”，以及是否出现“把秘密和实时数据写进AGENTS或Skill会造成过期与泄露”。前者决定是否继续，后者决定是否暂停、回滚或补充授权。
当官方文档与旧教程冲突时，应优先核对当前官方页面和实际版本。无法确认的功能不要写成确定事实。
涉及外部集成时，可先验证一个只读工具，再逐步开放写入。每增加一种副作用，都要补充权限、审批和回滚检查。
适用范围必须写清，因为把秘密和实时数据写进AGENTS或Skill会造成过期与泄露。对个人测试目录可接受的做法，不一定适合生产或团队仓库。