没有显式 workflow 入口时，routing-development-workflows 只依据当前批准、范围、风险和验证事实选择一个 fast | standard | full | blocked 结果，并把 workflow_route、范围摘要、风险事实、实施批准、目标 capability 和下一步组成稳定六字段交接。它不创建 PRD、spec、plan，不修改代码，也不把路由决定当作实施批准。
fast：用户已明确批准当前实施范围，目标与非目标稳定，没有公共契约、架构、共享核心、数据、迁移、权限、安全、资金、并发、事务、一致性、生产配置或外部状态边界，并且一个定向验证 seam 足以证明结果。standard：普通产品行为仍需需求或技术澄清，但没有已确认的 full 风险；任何重要路由事实未知时也保守进入 standard。full：存在上述高风险或跨边界事实，保留完整逐级文档、批准、验证和评审门。blocked：缺少必要授权、规则不可读、仓库根不确定或必需 capability 不可用，无法安全交接。
用户已显式点名 PRD、spec/plan、开发提示词、已批准 bounded implementation 或 AGENTS rule governance 时，该请求位于总路由适用范围外，直接进入对应能力且不产生 workflow_route。
Bug 或技术维护请求只有在现象明确、但根因或影响边界仍未知时，才先做一次有界只读诊断。诊断只读取相关规则、代码、配置、测试、已有日志、Git status 和 diff，不在目标仓库运行可能写缓存或产物的复现、测试、构建或生成命令，也不建立整仓快照。静态证据不能确认的事实继续标为未知并进入 standard，不把未知解释为安全。
creating-product-requirements 把产品意图收敛为一个稳定主题。范围类型只能是 product、phase 或 feature。一轮可以询问一至三个真正互不依赖的问题；只要一个答案会改变其它问题的适用性、选项或优先级，就只问当前决定性问题。只有需求理解置信度至少为 95%，且用户确认当前摘要后，才创建 PRD。
请求基于一份当前可靠、独立评审和用户均已批准的 PRD 增加或改变产品行为时，默认另建增量 PRD：正文标明批准基线，只写当前确认摘要中的变化、受影响上下文和验收，不覆盖或复刻完整基线。基线审批不自动批准增量；增量使用自己的路径、主题、八字段、独立评审和用户批准状态。没有相关批准基线，或用户明确确认要形成覆盖完整范围的合并替代文档时，才使用完整 PRD。工作流不设置篇幅、复杂度或审查成本上限，也不规定引用永远优于必要重述；无论采用引用还是重述，都不能引入确认摘要之外的产品行为。
进入任何 PRD 状态、路径选择或八字段输出前，先识别用户最终要求的交付物。最终只需要旁白、脚本、文案、提纲、文章或其他内容文档，且用户没有明确要求 PRD，也不在定义后续产品行为或开发范围时，本 skill 不适用；内容的结构、时长或覆盖范围变化本身不构成产品需求。主 Agent 直接返回原任务制作内容，不创建 PRD，不输出八字段，也不进入 spec 或 plan。
默认路径：
docs/requirements/YYYY-MM-DD-<topic>.md
PRD 必须经过独立评审和用户明确批准，才能进入技术设计阶段。来自总路由的 standard | full 与风险事实保存在正文 工作流分流 中，并作为独立 route handoff 传给下游；它不是第九个 requirements 字段。route 缺失、重复、冲突或不可靠时按 full 处理。全部门禁打开后，skill 先写入并验证批准状态与 requirements 八字段；下游能力在当前运行时可用时，主 Agent 无需用户再次输入 skill 名称或路径，直接在同一会话进入技术规格阶段。
creating-development-specs-and-plans 先校验已批准 PRD，再以相同的依赖感知规则澄清技术选择并生成 technical spec。可靠 standard route 会在 spec 用户批准前同时生成 implementation plan 草案，并把两者作为一个 technical package 交给同一位 reviewer；package 通过后，spec 独立评审与 plan 评审可以真实记录为已通过，但 spec 用户批准和实施门仍保持待批准/关闭。随后只给用户两个无默认值的选择：仅批准当前 spec，或批准当前 spec 并另行授权按当前 reviewed plan 实施。用户批准未发生实质变化的已评审 spec 后，只同步两份文档中的批准 metadata，不使 package review 失效；实施授权保留在当前对话和普通交接文本中，不增加文档字段或持久状态。
full、route 缺失或 route 不可靠时保留逐级顺序：spec 独立评审→用户批准→创建 plan→独立 plan 评审→单独请求实施授权。spec 或 plan 的批准、reviewer verdict 都不能替代用户对当前范围的实施授权。spec 实质变化会同时使 spec review、用户批准、plan review 与相关实施授权失效；仅 plan 实质变化使 plan review 与相关实施授权失效。双门全部打开后，主 Agent 重新验证 PRD、spec、plan 与十四字段快照，再自动进入会话路由。
已批准 PRD 是 technical spec 和 implementation plan 的产品范围上限。两份文档只能增加满足批准验收/非目标、适用规则或仓库已确认风险所需的最小技术细节；新增产品行为、持久身份、状态机、信任边界、共享框架、基础设施、验收或测试范围属于扩围，必须返回需求与用户批准，不能由技术文档或 reviewer 直接加入。
只有关键结果会改变调用方动作或数据/一致性影响时，spec 才使用结果/失败表；相同动作和影响的结果合并，不穷举推测、不可达或纯内部理论分支。Outcome ID 与 Guarantee ID 均不再是默认必填。数据库、事务或锁只写批准行为或已确认风险真正依赖的引擎事实和边界，不机械展开版本、读转写、busy、deadlock、timeout 或故障注入。追踪关系改为“批准需求/确认风险 → 最小技术保证 → 最小充分验证”，不得为了追踪完整性新增机制、基础设施或测试矩阵。
spec 对每项完成标准区分验收类型：只有可重复验证、且低层测试不能充分证明的发布关键跨层技术闭环进入最小关键 E2E 集合；易用性、内容质量和视觉体验由目标用户在发布候选环境中人工验收。两类验收分别写明执行者、环境、步骤、通过条件和证据。人工验收不能替代关键技术回归，E2E 不能冒充产品体验验证。
implementation plan 继承这项分类并写出具体范围：逐条列出精确 E2E 场景、命令和断言，再逐条列出目标用户人工验收任务、负责人、通过条件和留存证据；实施者不得自行增加更广的 E2E 或把主观体验改写为自动化断言。
implementation plan 把任务拆分用于实施和定向验证，不据此自动增加独立评审门。默认在所有任务完成、集成并通过相关验证后，由一名未参与实现的评审者依据批准需求、适用规则、已确认风险和验证证据检查最新完整 diff。每项 finding 分类为 BLOCKING_IN_SCOPE、SCOPE_CHANGE_REQUIRED 或 NON_BLOCKING_NOTE，并指定唯一处理对象 builder | planner | user | record-only；P0、P1、P2 只表达优先级，不改变 finding 分类、处理对象、verdict 或批准边界。只修复有范围内依据的 BLOCKING_IN_SCOPE。
只有 builder 与 planner 都确认关键段落难度或风险高，或后续任务依赖尚未验证的关键基础时，才增加中间里程碑评审。通过后只记录评审范围、结论、验证证据和失效条件四项轻量 checkpoint；未失效的局部结论可以复用，失效时只重审受影响范围，最终仍检查后续变化、集成关系和最新完整 diff。checkpoint 不是状态机、实施授权或评审豁免。只要仍有安全的范围内最小修复且受影响验证可执行，就继续修复并由同一 reviewer 复审；轮次、耗时、文件数和 finding 数量都不是停止条件。只有需要扩围、用户决定或额外授权，没有安全修复或新有效证据，或者必要环境、工具、同一 reviewer、评审输入或 verdict 不可用或不可靠时才停止并报告真实阻塞。用户方向可以解决范围选择，但不能替代正确性或评审证据。
默认路径：
docs/specs/YYYY-MM-DD-<topic>-design.md
docs/plans/YYYY-MM-DD-<topic>.md
本功能生效后从头创建的 PRD、technical spec 和 implementation plan 使用完整中文 frontmatter 键及中文生命周期值，例如“产品需求 / 技术规格 / 实施计划”“产品 / 阶段 / 功能”“待批准 / 已批准”和“待评审 / 已通过”。路径、stable topic、reviewer role、ISO 日期以及 skill 间传递的 requirements 八字段、workflow 十四字段继续使用原有技术值和英文 canonical 字段；renderer、CLI 与 JSON shape 不变。
既有英文 PRD、spec 和 plan 属于 english-legacy：正文维护、批准失效、批准和重新评审都继续写回英文 schema，不因本功能自动改写，也不批量迁移历史文档。读取端同时接受完整 chinese-current 和兼容的 english-legacy；mixed schema、语义重复、冲突、畸形 flat scalar、未知 Unicode key 或不受支持的中文值一律按不可靠状态失败关闭，不选择较有利的批准值。
plan discovery 保留非对称兼容边界：新中文 plan 使用 评审模式: 技术包 | 逐级。技术包允许 计划评审状态: 已通过 与 技术规格用户批准: 待批准 同时成立，但由此派生的 implementation_gate 仍为 blocked；逐级 plan 必须先有 spec 用户批准。既有可靠中文 plan 缺少评审模式但 spec 已批准时保持兼容，历史英文 frontmatter 继续使用既有 review-only 合同，legacy header 只接受 ASCII 英文字段。
generating-development-prompts 接收已验证的十四字段，结合当前会话、仓库、权限、工具和 Agent 能力给出 current-session、new-session 或 blocked。current-session 建议继续当前会话；当前用户已经明确授权当前范围时不重复索取，否则等待用户显式实施批准。spec、plan、reviewer verdict 或其它范围的历史批准都不能被推断为本次授权。current-session 不生成提示词也不开始实施，只说明获批开工后将在首个新鲜 GREEN、扩张写入前和最终 diff 执行比例检查；new-session 才生成单一 Markdown 代码框中的自包含提示词；blocked 明确缺失证据或确定性阻塞。自动路由回复仍以同一中文十四字段视图结尾，不修改文档批准状态。
显式的手动提示词请求保持兼容：它读取用户指定或从 docs/specs/、docs/plans/ 自动发现的 spec、plan 路径和仓库证据，显式路径优先；plan 未批准或状态未知时仍可生成提示词，但提示词必须在修改前阻断实施。没有上游十四字段时不伪造 requirements 或双门状态。
生成的实施合同把已批准需求（无可靠 PRD 时为用户明确冻结并批准的范围）设为产品范围上限，要求每项任务执行 TDD 和影响范围匹配的验证，并在首个新鲜 GREEN、扩张写入前和最终 diff 检查剩余工作。只有批准验收、适用规则、已确认风险、当前候选回归或具体可观察失败能支持当前必需；其余想法延后，仅移除本任务创建且经证据确认没有独立价值的内容，真实扩围、新公共契约或新高风险边界则暂停请求用户决定。低概率本身不触发设计、开发、测试扩张或阻断性评审；缺少当前依据和具体高风险后果时省略扩张或只记录非阻断建议，二者同时存在时只采取风险相称的最小措施。该检查复用新鲜验证，不新增持久状态或跟踪制品。实施合同默认只在集成后对最新完整 diff 做首次独立整体评审。提示词保留三类 finding、最小范围内修正和扩围返回需求批准的合同；同一评审者只复审原阻断项、变更区域和修复回归。只有 builder 与 planner 都确认难度或风险高的关键段落，或后续任务依赖尚未验证的关键基础时，才增加中间评审；适用的用户或项目规则明确要求更强评审时仍优先服从。通过后只记录评审范围、结论、验证证据和失效条件，最终评审先判断证据是否失效；APPROVED 后停止。只要仍有安全的范围内最小修复和可执行的受影响验证，就继续修复、验证并由同一 reviewer 复审；只有真实阻塞才停止，不设置固定轮次上限。
目标会话第一次实际需要委派时读取可按名称启动的个人全局 Agent，建立只存在于当前对话上下文的 inventory，记录 name、description 与读取可靠性。后续委派复用该 inventory；只有配置变化、首次读取失败、按名称启动失败、inventory 与可观察能力冲突或用户显式要求时刷新一次。刷新后仍失败则保留能力缺口，不静默降级。
PRD workflow 的 requirements 八字段按下表成为 spec/plan 十四字段的前八项：
| requirements 八字段 | spec/plan 十四字段前缀 | 转换规则 |
|---|---|---|
requirements_path |
requirements_path |
字段名和值原样保留 |
requirements_topic |
requirements_topic |
字段名和值原样保留 |
requirements_scope |
requirements_scope |
字段名和值原样保留 |
understanding_confidence |
requirements_understanding_confidence |
只重命名字段，值原样保留 |
understanding_user_confirmation |
requirements_understanding_confirmation |
只重命名字段，值原样保留 |
requirements_user_approval |
requirements_user_approval |
字段名和值原样保留 |
requirements_independent_review |
requirements_independent_review |
字段名和值原样保留 |
specification_gate |
specification_gate |
字段名和值原样保留 |
进入下游前复验失败时不选择下游、不构造十四字段，上游仍以真实八字段或 unknown 状态结束。进入下游后复验失败时仍输出完整十四字段：requirements 侧按已确认规则关闭 specification_gate，spec/plan 侧保留可靠路径与真实状态，并令 implementation_gate: blocked。
plan 评审通过后必须重新验证并冻结十四字段快照，再进入三态路由。自动路由回复仍以同一十四字段快照结尾；路由结论、理由和可复制提示词位于该快照之前。
八字段和十四字段的英文 canonical 名称、允许值、门禁计算及 skill 间传递保持不变；旧英文八字段和十四字段输入继续兼容。三个交接 skill 各自发布字节一致、运行时自包含的 scripts/render_handoff.py，以严格 JSON 输入校验 canonical、gate 和显示映射，不 import 兄弟 skill。
只有普通、预期内、非阻塞且不要求正式确认或批准的澄清使用 compact 视图，固定为连续三行且没有空行、列表标记或末尾内容：
当前阶段：<需求澄清 | 技术规格澄清 | 实施计划澄清>
主题：<stable-topic | 未确定 | 未知>
下一步：<当前动作>
暂停或恢复点、需求摘要确认、PRD/spec/实施批准、确定性阻塞、文档阶段完成和跨 skill 或会话路由使用完整中文八字段或十四字段。纯进度回复不属于 compact；无法可靠分类时保守使用完整状态。十四字段中的计划状态继续结合 plan 路径与评审状态区分“未开始”“未通过”“已通过”和“未知”。
每个 skill 都先验证并冻结英文 canonical 快照，再调用自身 renderer。renderer 或映射失败时 stdout 为空；调用方保留 canonical 和门禁事实，停止本次自动交接，只输出可定位的阻塞说明且不附加状态块，不输出残缺、混合或英文 fallback 状态块。
这项显示变化不改变 render_prompt.py stdout 的字节级合同。自动 new-session 回复把 prompt renderer 的唯一动态代码框放在 handoff renderer 生成的中文十四字段状态块之前，状态块位于动态代码框之外；手动请求没有可靠上游快照时仍只返回 render_prompt.py stdout。
implementing-bounded-changes 用于现有或开发中项目里已经明确改动点和方案、且用户已明确同意推进的小改动或 Bug 修复。它不生成提示词，也不要求为了小任务创建 PRD、spec、plan 或进度文档。
实施前在当前会话冻结目标、首版必要项、明确延后项、预计文件或模块、改动点、方案、非目标、验证范围和文档影响，不另建跟踪制品。若实现将新增持久状态或状态机、为同一行为引入第二套抽象或实现路径、增加验收外页面或流程，或明显超出预计文件范围并触及新的共享/高风险边界，必须在生产写入前暂停，说明原因和更小替代方案，只有用户明确批准修订后的最小切片才能继续。
行为变化使用比例化 RED→GREEN；默认只运行最小充分的定向验证，可以使用边界清晰的 Sub Agent。当前任务在会话内记录验证命令、覆盖范围、相关状态和明确结果；只要相关生产代码、测试、fixture、配置、依赖、命令和环境未变，已通过结果可以复用，评审开始、Agent 交接或进度汇报本身不触发重跑。相关变化只使受影响结果失效；最后一次相关变化后只运行一次仓库要求的上层或最终门。该父门已覆盖失效的 focused seam 时，由父门直接提供 GREEN，不在它前面再跑一次相同 focused 检查。超时、中断或结果不完整不能记为通过，重试前先定位原因。
首次取得新鲜 GREEN 后、任何可能扩张的生产写入前，以及最终 diff 检查时，受控实施执行同一轻量比例检查，不在每次编辑后重复。每个剩余缺口先核对批准验收、已确认风险、适用规则、当前候选回归或具体可观察失败，并在内部判断更小方案：有当前依据且仍缺失的标为 REQUIRED_NOW，只继续该缺口；可能有用但当前无依据的标为 DEFER，停止增加生产行为；仅本任务新增且被证据证明没有独立价值的内容可标为 REMOVE，无引用或临时形态本身不是删除依据；只有范围扩张、新公共契约或新高风险边界标为 PAUSE 并在写入前请求用户决定。正常 REQUIRED_NOW 静默继续；DEFER 和 REMOVE 只在最终交付中简报，不出现在 commentary、进度或交付前消息；只有 PAUSE 即时打断用户。判断不创建状态机、文档或追踪工具；未变化的验证直接复用，移除内容改变相关输入时只重跑受影响验证。
如果当前任务的实际 diff 和验证形成了可复用、项目特定且现有规则未覆盖的“变更范围→验证命令”映射，受控实施只在会话内临时使用并保留候选证据，不直接修改 AGENTS.md。规则治理入口再基于该证据展示目标、适用边界和精确候选 diff，由用户选择加入或拒绝；拒绝不影响当前实施，也不在同一逻辑任务中重复提示。不会从通用占位模板推断项目命令。
评审要求先服从当前用户指令和适用项目规则，Skill 默认值不另设与高优先级决定冲突的硬门。局部、可逆、由确定性行为测试覆盖且不触及共享契约或高风险边界的轻量行为变更，默认可免独立评审；纯文档、格式或确定性机械改动在具有最小充分静态检查时同样可豁免。无论是否评审，都必须检查最终 diff，并报告具体分级或豁免依据。
中等任务根据实际边界、可逆性、共享影响和验证覆盖判断，不因任务数量、行为变化或任务标签自动要求评审。数据模型、迁移、权限、安全、资金、不可逆操作、并发、事务、一致性及项目规则认定的其它高风险边界，默认必须由一位未参与实现的评审者检查最新完整 diff。评审 findings 固定分为 BLOCKING_IN_SCOPE、SCOPE_CHANGE_REQUIRED 和 NON_BLOCKING_NOTE；优先级标签本身不构成阻断，缺少批准验收、现有契约、适用规则、当前回归或具体高风险正确性依据的普通 P2 只记录，不进入自动修复—复审循环。低概率本身不构成设计、实现、测试或阻断性评审依据；同时存在当前依据和具体高风险后果时，只采取风险相称的最小措施。只修复 BLOCKING_IN_SCOPE，并由同一评审者复审；只要仍有安全的范围内最小修复且受影响验证可执行，就持续收敛，不以固定轮次、耗时、文件数或 finding 数量停止。APPROVED 后立即停止；需要扩围或用户决定、没有安全修复或新有效证据，或者必要能力或评审证据不可用或不可靠时，报告真实阻塞并停止。
用户批准只覆盖冻结范围。实现或评审发现必须改变公共契约、依赖、架构、数据、权限、迁移、并发、一致性或其他已确认边界时，停止修改并重新请求用户批准。受控实施入口不得绕过目标仓库明确要求的产品、设计、迁移、安全或发布门。
managing-agents-rules 独立处理长期项目规则和 Codex 全局规则，不替代 PRD、spec、plan、开发提示词或受控实施。它在实质性开发首次生产写入前检查项目根 AGENTS.md；任务完成时只从当前 diff、验证、纠正或稳定运维证据中筛选可复用候选。
缺失项目根规则时先展示有仓库证据的最小候选 diff；已有但不可读时阻断生产写入，不把不可读误判为缺失。每个项目级或全局目标分别展示目标、证据、范围理由和当前最小 diff，批准只对该目标和当前 diff 有效；写入前基线变化会使批准失效。没有合格候选时不发出规则治理提示，也不把会话状态持久化到项目或用户目录。
候选 diff 在回复中只完整显示一次，并使用比 diff 内最长连续反引号更长的动态 Markdown fence；批准问题位于关闭 fence 之后。Codex 客户端不保证渲染 HTML disclosure，因此不使用 <details> 或 <summary> 折叠候选，避免标签外露或内层代码围栏提前截断 diff。
项目规则变更在适用的最终评审前进入最新仓库 diff 并重新验证。全局规则默认以当前 Codex home 的基础 AGENTS.md 为长期目标；非空 override 会遮蔽基础文件，因此只告警，只有用户显式选择后才把现有 override 作为独立目标。Git 初始化与规则文件创建始终是两个独立决定。
- 用户显式路径优先于默认路径。
- skill 之间只通过文档路径、评审状态和显式输出字段协作。
- skill 不通过相对 import、本机安装路径或 plugin cache 调用彼此。
- PRD、spec 或 plan 发生实质修改后，原有批准状态失效，必须重新评审或确认。
- 缺失、未知或无法验证的批准状态不得推断为已批准。
- 受控实施 skill 不读取或调用其它 skill；它只依据用户批准、当前会话范围卡和目标仓库证据执行。
managing-agents-rules不读取或调用其它 skill；它只治理长期规则，不接管实现、文档创作或评审职责。
PRD 阶段在内部固定维护 requirements 英文 canonical 八字段，对用户显示同序中文八字段。spec/plan 阶段校验并按上表保留这些 canonical 字段，再维护 requirements、spec、plan 和双门状态共十四字段；自动进入下游后，最终只保留一个中文十四字段结尾。prompt 路由保留同一 canonical 快照及其预验证中文视图，使当前或下一会话可以从文件证据恢复，而不是依赖聊天记忆。
具体字段和文档模板以各 skill 的 SKILL.md、references/ 与 assets/ 为准；公共契约变化必须同时更新上下游集成测试。
evaluations/ 只保存脱敏后的固定场景、判据和选中证据。可能包含用户上下文、原始 trace、stderr、task/thread 标识符或本机路径的材料只保存在被 .gitignore 排除的 work/ 中。版本化输出中的 /workspace/fixture 是唯一允许的固定合成仓库根，不代表真实机器路径；公开扫描允许该前缀，并拒绝常见 macOS、Linux、Windows 本机用户或临时路径以及其它 /workspace/... 根。
green/result.json 的 fresh_cases 记录 production 变化后实际重跑并纳入当前评审的场景。scripts/validate_repo.py --require-freshness 在干净 Git 树核对 RED → production → fresh GREEN → review 的祖先链；工作区可以复用满足祖先关系的干净前序，但从第一个变化阶段起必须形成连续 dirty 后序，current RED 两份证据和全部 fresh GREEN outputs 各自保持完整。全新 creation-only skill 在尚无 production commit 时，只有 registry、全部 publishable production、baseline 与 GREEN 证据均属于同一个完整工作区 bundle，才记录为 worktree-creation-current；已提交 skill 的后续 production 变化仍必须升级 current-RED profile。中间缺口、部分刷新或过期干净前序都会失败；非 Git 副本只能做结构检查，不能通过严格 freshness 门。