writing-plans

如果激活模式为显式模式（`~/.config/aegis/config.toml` 中设置了 `activation_mode = "explicit"`，或环境中存在 `AEGIS_ACTIVATION_MODE=explicit`），且当前用户请求未明确按名称调用 Aegis 或此技能，则退出并返回快速路径：简洁作答，不采用此工作流的检查清单、 流程仪式或文档要求。如果用户明确提到了 Aegis 或此技能，则正常继续。

执行

→ 已有父级计划／规格，且任务是一个小型执行切片？→ 使用无计划切片通道。 → 属于机械性或范围明确的变更，且没有持久边界（不新增所有者、 契约、架构、公共 API、迁移或兼容性表面）？→ 使用 无计划切片通道，无需父级文档。 → 已批准的新工作流规格／需求，或出现升级触发条件？→ 为没有任务背景的工程师编写实施计划。

对于持久计划：确认范围和验收标准，梳理当前所有者／文件， 记录 TDD 路径，将工作分解为可执行任务，定义验证和退役方式， 自我审查，保存，然后选择执行路径。除非存在真实的授权或安全边界需要用户介入，否则继续。

将任务与用户要求的结果绑定：对象、操作、条件和交付物。包括最终交付步骤， 并在用户可见的环节提供证据，而不只是实现／测试。明确列出未满足的需求和依赖项； 项目级目标并不授权开展超出本请求范围的工作。复用现有的范围／验收栏位；无需额外创建目标文档。

当工作新增所有者、契约、架构、公共 API、架构边界、迁移、 持久化、安全／权限、分发／发布表面，或验证边界不明确时， 从无计划切片通道升级。

编写计划

此技能用于将已批准的需求转化为范围明确、可执行的计划。计划必须回答： 要做哪些更改、为何需要改代码、哪些现有所有者和文件会发生变化、 哪些内容保持兼容、如何验证结果、仍有哪些风险，以及旧路径是被退役还是有意保留。 计划只是方法包的指导，不能授权权威性完成认定。

TDD 路径门控

在分解任务之前，记录 TDD Route，包括模式（off | auto）、决策 （strict | light | skipped）、依据、测试立场、原因和验证方式。

严格的 RED / GREEN 步骤仅适用于用户／项目明确要求 TDD，或 TDD Route: strict 的情况。 在 off 模式下，除非明确的严格模式授权另有规定，否则使用 skipped。已批准的计划或风险标签本身并不构成严格模式授权。

在 auto 模式下，如果存在行为、错误修复、共享／核心、契约、 持久化、权限、迁移、生产者／消费者或有意义的回归信号，则选择 strict。仅当工作 规模很小、风险低、由单一所有者负责、不涉及行为变化或严格模式信号，且有明确的针对性检查时，才选择 light。没有明确的用户 TDD 请求，绝不能作为选择 light 的依据；必须记录自动决策本身。

如果风险仍不明确，应返回需求分析、调试或计划审查阶段，然后再分解任务；不要根据不确定性推断 TDD 路径。

只有在 strict 决策并说明授权依据时，才可规定失败测试、RED、GREEN 和 REFACTOR 步骤。否则，规划最小变更，并进行诊断性复现或变更后的回归验证。若缺少自动决策，则应在制定实施任务前返回路径选择阶段。

入口与产物选择

**开始时说明：**在编写计划的路径上，说明此技能正在创建实施计划。在 Planless Slice Lane 中，则说明当前通道，不要声称正在创建计划。

**执行上下文：**默认复用当前分支／工作区。只有需要独立历史记录、并发检出、阻止无关的脏状态，或用户／仓库明确授权时，才需要新建分支或工作树。

**输入：**已批准的需求、Spec Brief 或 Design Spec。

默认计划路径：docs/aegis/plans/YYYY-MM-DD-<feature-name>.md。计划不应放在 work/ 中；用户和仓库的授权优先于默认设置。

例外：当现有的父计划／规格已涵盖当前的微小执行切片，或变更属于机械性或范围明确且无需父级文档时，使用 Planless Slice Lane。不要保存新计划。输出精简的 Slice Card：

Slice Card:
- Goal:
- Parent plan/spec:
- Files:
- Boundary:
- Verification:
- Stop:

在没有父级文档的分支上，Parent plan/spec: 的值为 none — direct bounded request。

Aegis 项目工作区

工作区应按项目授权按需创建。Aegis Method Pack 仓库不得创建或交付已启用的 docs/aegis/ 工作区。当持久计划必须初始化或更新另一个项目的工作区时，请阅读 expanded-planning-guidance.md 中的工作区部分。该部分负责 <aegis-workspace-helper> 和 INDEX.md 的命令细节，但不负责决定是否创建计划。

默认计划内容

精简输出约定：将以下内容自然地写入计划，不要堆叠成多张卡片：Aegis Visibility、已批准的范围和计划依据、必需的基准引用、文件／负责人、兼容性边界、Change Necessity、TDD 路径、任务、验证、风险和退役。除非触发以下条件，否则不要输出条件性结构。

Aegis Visibility 通常用一句话说明，是什么负责人、契约、退役、兼容性或验证方面的压力使持久计划变得有用。结构化追踪仅适用于审计、调试、发布、长期任务审查或明确要求的情况。

创建任务前，执行 Requirement Ready Check：确认已批准的来源、范围、场景和验收证据。如果缺少任何会影响决策的事项，不要创建实施任务；将最小缺口反馈给需求／规格负责人。

在任何非琐碎的源代码编辑或任何新的源代码路径之前，执行 Change Necessity。这由行为触发，而非由提示词触发。自然地说明为什么仅变更内容、不变更代码、文档或配置不足以满足需求，并指出最小代码边界。微型辅助函数、防护逻辑、分支、回退方案、适配器或负责人均不例外。no-change、docs/config-only 或 needs-clarification 结果会缩小代码计划范围或使其停止。

当变更涉及共享／核心行为或跨模块行为，以及公共 API、架构、契约、兼容性、持久化、缓存、导出／回读、回退、适配器、重复／旧版负责人、退役路径，或同时涉及生产者和消费者时，在任务前执行 Ripple Signal Triage。如果没有触发信号，不要添加任何输出。如果触发了信号，则指出规范负责人和受影响的下游消费者，说明真实来源／契约／回退／退役风险，并在相关任务中加入扩展验证。需要变更负责人／公共契约／真实来源、保留两个负责人，或添加回退方案、适配器或兼容性分支时，应返回设计阶段，或在实施前取得明确的事先对齐。

任务拆解前，执行精简的 Plan Pressure Test：检查负责人／契约／退役是否匹配、更高层架构路径、验证范围和任务可执行性。结果可以是继续、修订计划或返回设计阶段；该测试不具备审批权限。

条件式详细指导

对于界面/交互工作，组合使用 ui-ux-governance，并将已接受的体验标准及相应检查纳入受影响的任务。包括会改变可见状态或恢复方式的 API 变更；仅限后端的工作应保持原有范围。

仅阅读 expanded-planning-guidance.md 中与触发条件匹配的部分：

• 当具体的基线确认需要结构化，或需求就绪度不完整/存在争议时，阅读 ## Baseline And Requirement Detail；
• 当需要在任务分解前，通过 Existence Check、AEGIS_MINIMALITY_REFERENCE、Architecture Integrity Lens 或 first-principles-review 了解新界面或新负责方时，阅读 ## New-Surface And Architecture Detail；
• 当出现文件大小、所有者混杂、原地添加、适配器、回退或共享核心方面的显著压力时，阅读 ## Complexity Detail；
• 对于长时间运行、易需交接、由子 Agent 驱动、高风险的架构/契约/兼容性/退役交接，阅读 ## Execution Readiness Detail；
• 仅当保存需要初始化工作区或更新 INDEX.md 时，阅读 ## Workspace Save Detail；
• 仅当路线证据需要结构化交接时，阅读 ## Execution Route Detail；以及
• 仅对独立的高风险或交接繁重的审查，阅读 ## Expanded Plan Review。

直接触发条件涵盖基线就绪度、新界面或新负责方、复杂度压力、工作区持久化和执行交接。参考文件仅提供详细信息。此主文件负责路由、Plan 与 Planless 的选择、任务阻塞和执行交接。

对于新界面，在创建任务前使用 Existence Check 和 docs/current/AEGIS_MINIMALITY_REFERENCE.md。如果现有负责方足以胜任，则复用该负责方。如果负责方、契约、职责重叠、更高层级的简化、回退或退役仍有风险，则在任务分解前使用 Architecture Integrity Lens 和 first-principles-review。

对于维护中的源代码，检查文件结构、负责方匹配度、原地添加风险以及是否存在更合适的边界。如果没有压力信号，简要说明原地编辑的决定即可。当存在压力时，加载扩展版 Plan-Time Complexity Check 和 Complexity Budget。超出预算时，必须调整任务边界、增加治理工作，或暂停并跟进。

对于常规的中/高风险交接，自然地说明 Intent Lock、Scope Fence、Baseline Lock、测试和漂移停止条件。仅当存在上述可审计交接触发条件时，才加载扩展版 Execution Readiness View。两种形式都不是 GateDecision、PolicySnapshot、审批门槛或完成授权。

如果计划必须在删除旧的内部路径、保留已验证的外部兼容性边界，或暂停以确认持久状态之间作出选择，则组合使用 anti-entropy-governance。它不授权执行破坏性操作。

在完成时保留已批准的 ADR 信号保留内容、源引用、备选方案、兼容性和基线同步问题；不要根据尚未执行的计划创建已接受的架构记忆。

Planless Slice Lane

在编写或保存计划之前，若符合以下任一准入条件，则使用 Planless Slice Lane：

• 父级规范或父级计划已定义该工作流，且当前请求是在执行或细化该父级中的一个有界任务
• 变更是机械性或有界的，无需父级文档（# Execute 下的无父级分支）

并且以下两项均成立：

• 不涉及新的负责方、契约、架构、公共 API、架构边界、迁移、持久化、安全/权限、分发/发布界面，也没有不明确的验证边界
• 可以通过 Slice Card 描述该切片

此路径可保持长任务的连续性，避免将执行记录转变为持久化规划产物。若父级范围或验收标准不匹配，应返回父级计划/规范，而不是另行创建微型计划。

计划与任务质量

拆分任务前先梳理文件。遵循现有的归属关系和命名方式。对于非简单计划，酌情沿用 CONTEXT-MAP.md 或 CONTEXT.md 中的相关现行术语；若存在实际的语义冲突，则转交给 establishing-project-context。

每份持久化计划都必须以 Goal、Architecture、Tech Stack、 Baseline/Authority Refs、Compatibility Boundary、TDD Route 和 Verification 开头。 然后定义规模小、顺序明确的任务，并写明确切文件、目的、必要的最小改动、兼容性影响，以及用于证明任务完成的命令和结果。只有在签名、契约或转换方式仍有歧义时才加入代码片段；不要在计划中重复实现内容。

对于错误修复、重构、契约变更或治理清理，在受影响的任务中明确写出 Repair Track 和 Retirement Track。保留旧归属方或回退方案时，必须说明理由和退役触发条件。

进行一次自审，检查是否覆盖已批准范围、占位符、归属方与类型的一致性、最小改动边界、兼容性、确切的验证方式、条件触发处理和退役安排。发现问题时直接修正。任务是执行单元，不是 Git 历史单元：协调者记录 TaskStartSnapshot，仅在整个任务完成审查并经过最新验证后，才创建一个范围明确的提交。

执行交接

由 Agent 负责选择执行路线。只有在任务确实相互独立、归属范围明确且协调收益大于成本时，才选择 subagent-driven；否则选择 inline。若子 Agent 不可用，则回退为 inline 执行。工作区处于脏状态本身并不决定采用哪条路线。

只有在授权、隐私、付费资源、外部操作、不可逆操作、范围、验收标准或工作区归属边界尚未明确时，才询问用户。否则立即继续。简要说明决定、依据、回退方案，以及 User confirmation required: no | yes — <boundary>；仅在完整的 Execution Route 架构有用时才加载参考资料。

对于 subagent-driven，使用 aegis:subagent-driven-development。对于 inline，使用 aegis:executing-plans。