brainstorming

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

执行

→ 直接盘问或对计划／设计进行压力测试？→ 进入下方的 Grilling Mode。意在温和质疑？→ 用一句话确认模式。访谈期间不要开始常规设计产物、编写文档、任务规划或实现。 → 新功能、产品行为、UI／组件设计、架构／契约变更，或复杂度中等／较高且含糊的工作？→ 先设计。所需设计／规范获批前不得实现。

1. 探索项目背景 → 阅读权威文档，检查现有模式
2. 一次提出一个澄清问题（优先使用选择题）
3. 提出 2-3 种方案，说明权衡并给出推荐
4. 分节呈现设计 → 每节之后征求用户批准
5. 编写规范 → 自我审查 → 用户审阅 → 转入 writing-plans → 硬性门槛：对于符合此技能范围的任务，在设计／规范获批前，不要编写代码、搭建项目脚手架或调用实现技能。

路由示例

这些条目是方法行为的校准预期，不是运行时正则路由。Agent 根据证据选择路由；路由选择不是一个需要向用户提出的问题。

场景	路由
想法还没想清楚，先梳理功能设计	常规头脑风暴，先简洁输出
讨论公共 API 契约和兼容边界	常规头脑风暴，实现前先分节呈现设计
盘问／拷问／审问这个方案，不要顺着我	Grilling Mode
修复登录按钮的空指针	systematic-debugging
review 当前 PR / diff / 当前代码	requesting-code-review
给我一个有目标的方案	目标意图明确时使用 goal-framing；否则使用常规头脑风暴
把按钮文案从保存改成提交	快速路径；不走设计流程

将想法转化为设计

通过自然的协作对话，将想法完善为完整的设计和规范。

先了解当前项目背景和权威边界，然后一次提出一个问题，以逐步明确想法。了解要构建的内容后，呈现能够稳定工作的最小设计产物，并取得所需批准。

将成功定义为用户可用的结果，包括交付内容和有意义的失败状态。将实际的业务／授权限制与当前实现限制区分开；尚不支持的操作仍属于未满足的需求。在不扩大范围的前提下，兼顾受支持场景中的可靠性。对于未变更的决策，已有批准仍然有效；仅当设计或授权相关的空缺需要澄清时才提问。

对于符合此技能范围的工作，在呈现所需的设计／规范并按此工作流取得用户批准前，不得调用任何实现技能、编写代码、搭建任何项目脚手架或采取实现行动。

Grilling Mode

模式优先级

Grilling Mode 生效期间，它优先于常规头脑风暴执行流程。暂停 Checklist、The Process、Compact output contract，以及所有文档或设计转换要求，直到用户退出访谈；保留禁止实现的硬性门槛。

进入审问模式的信号

• 直接触发： 用户要求审问某个想法、计划或设计，或明确要求进行压力测试。直接触发短语包括 grill me、grill this plan、审问我、盘问我 和 拷问我。立即进入此模式。
• 间接触发： 用户要求挑战假设、找出漏洞、进行红队分析，或就某个初步想法、计划或设计表示“别顺着我”。只询问：Grill or normal brainstorming? 仅在用户确认后进入此模式。
• 不属于审问： 单纯或字面提及相关短语，或审查 PR、差异或当前代码。正常解释字面短语；将实现审查转到 requesting-code-review。

开场卡片

用户进入此模式后，用用户所用语言只发送一次，然后开始访谈：

◆ Grilling Session
Target: <idea / plan / design>
Question path: value -> boundaries -> failure modes -> acceptance
Pace: deep (default) | fast (user-requested)

节奏

• 深入： 当问题会阻碍进展或取决于上一条回答时，每轮只问一个决策问题。等待回答前，说明建议答案和最相关的权衡。
• 快速： 仅当用户明确要求快速或批量访谈时（例如 fast、batch、快问 或 一次问几个），才可提出最多三个相互独立的决策问题。为每个问题给出建议和权衡，然后等待用户回答。对于依赖前序回答的后续问题，恢复深入节奏。

1. 提问前，先检查代码库和当前权威文档以查明事实。不要询问用户那些可以在本地找到答案的事实。
2. 决策权属于用户。不要将建议、暂定答案或共同理解检查点视为最终批准。
3. 除一次性的开场卡片外，每轮只围绕观察、建议和所选节奏的问题展开。访谈期间不要进行完整的设计流程，不要编写文档、制定计划或实施。
4. 用户表示停止、暂缓或问题已足够时，结束访谈。以结构化的 Challenge Result 进行确认。该摘要不代表已获得完成工作的授权。

Challenge Result
- Survived assumptions
- Rejected assumptions
- New evidence needed
- Design changes required
- Residual risks
- Return state: interview | design | approaches | writing-plans

5. 如果用户在访谈后要求继续，则返回常规的头脑风暴设计关卡。设计或规范仍须获得所需批准，之后才能规划或实施。

转交其他流程／文档必要性关卡

不要将此工作流强加于复杂度低的任务。微小的措辞修改、单一负责人的错误修复、简单的配置／状态问题、本地工具函数变更或机械式多文件变更，都可以通过简洁的意图说明、基线检查、TDD／调试和验证来完成，无需新增文档。编写任何规范、计划、ADR 或基线文档之前，先运行文档必要性关卡：

1. 是否已有规范／计划／ADR／基线文档涵盖此次变更范围？ -> 更新现有的责任文档，不要新建同级文档。
2. 此范围是否具有持久性／不可逆性（架构、公共 API、责任方、依赖方向、迁移、兼容路径退役）、涉及跨会话／跨人员交接、需要审批或必须具备权威依据？ -> 是：为该范围编写最精简的文档（见 Documentation）。 -> 否：不编写文档；将简短草稿保留在当前会话中。
3. 在编辑时和收尾时重新检查；如果不确定性或影响扩大，则升级为最精简的稳定规范。

流程优先级

1. 流程分流的情况应先退出此工作流（systematic-debugging、requesting-code-review、目标意图明确时的 goal-framing、快速路径微型任务）。
2. Grilling Mode 需要明确的挑战意图。常规讨论、评估或澄清理解需求都不属于审问。
3. 其他情况均按常规头脑风暴流程进行，并根据证据加深分析：契约、责任方、持久化、迁移、安全、消费者数量或影响范围。应在发现证据后再升级，而不是仅因初始请求听起来宏大就升级。
4. 文件数量本身并不能表明是否需要设计：机械式多文件变更仍可走快速路径，而单文件契约变更仍可能需要完整设计。

角色与权限约定

由 Agent 自行决定的事项

直接处理以下事项，无需询问用户：

• 仓库调查策略及证据收集顺序
• 已接受的负责方内部的文件和函数组织方式
• 测试命令及适度的验证方式
• 在政策允许的情况下，选择直接执行还是使用子 Agent
• 不改变产品行为、契约、权限或持久边界的可逆实现结构

由用户决定的事项

仅在以下情况下询问用户：

• 产品行为或偏好
• 不可逆、破坏性、外部、公开、生产或敏感影响
• 只有用户才能做出的明确产品／契约承诺
• 仓库、工具和权威文档中均无法获取的必要信息

每个用户问题都必须通过以下检验：

如果用户选择另一个答案，哪项设计边界、行为、负责方、验收标准或风险决策会发生变化？

如果没有任何变化，就不要提问。若问题通过此检验，请附上推荐选项及理由，让用户在明确的选项中做出决定，而不是自行调查。此分类用于明确哪些决策由用户负责；它不会取消此工作流已定义的审批环节。

检查清单

你 MUST 为以下每项创建任务，并按顺序完成：

1. 了解项目背景 — 检查文件、文档、近期提交、权威文档，并被动读取相关的活动 CONTEXT.md 内容，但不要加载活动建模内容
2. 选择路径和范围 — 判断是否为实际设计或诊断；选择相应流程，或先拆分
3. 提出澄清问题 — 每次一个，了解目的／约束／成功标准
4. 起草工作材料 — TaskIntentDraft、BaselineReadSetHint、BaselineUsageDraft、ImpactStatementDraft
5. 添加新界面时运行存在性检查 — 仅当方案新增负责方、技能、工件、适配器、回退方案、工作流步骤或基准指标时执行
6. 提出 2-3 种方案 — 说明权衡并给出推荐方案
7. 展示设计 — 按复杂程度安排各部分，并在需要时取得用户批准
8. 编写规格工件 — 仅在通过文档必要性门槛且现有负责方规格／计划未覆盖该界面时执行；若已有文档覆盖，则更新该文档，而非另建同级文档
9. 规格自审 — 检查占位符、矛盾、歧义、范围和边界
10. 由用户审阅书面规格 — 继续之前请用户审阅
11. 转入实现阶段 — 调用 writing-plans 技能（终止状态）

终止状态是调用 writing-plans。 不要调用任何其他实现技能。

流程

理解想法：

• 首先检查当前项目状态（文件、文档、近期提交）
• 在提出深入问题前，阅读相关权威文档
• 在问题、选项、场景和规格中使用现有的规范术语。若术语逐渐明晰或出现冲突，请组合使用 establishing-project-context；不要只在规格中记录最终处理方式。
• 如果请求是对已批准计划进行诊断／根因分析／后续跟进 → 转入正确的工作流
• 如果请求涉及多个相互独立的子系统 → 先标记并拆分
• 一次提出一个澄清问题，优先采用选择题
• 探索过程中区分事实、假设和未知事项

工作材料： 保留四份草稿：TaskIntentDraft（结果、目标、成功证据、停止条件、非目标、范围、风险）、BaselineReadSetHint（候选文档、权威性缺口）、BaselineUsageDraft（必需引用、可选提供的上下文引用、计划前已确认的引用、已引用内容、缺失引用、建议性决策）和 ImpactStatementDraft（受影响层、负责方、不变量、兼容性、非目标）。范围变化时更新这些草稿。 紧凑输出约定： Aegis Visibility、TaskIntentDraft、BaselineReadSetHint、 BaselineUsageDraft、Requirement Ready Check、ImpactStatementDraft、 Existence Check、Product Risk Lens、Architecture Integrity Lens、 Prior-Art & Reuse Lens、Baseline Role Alignment、Plan-Time Complexity Check、Options 和 Decision Needed。在扩展为完整设计结构之前，先使用这种紧凑格式。

本工作流中的 Aegis Visibility 用于说明为什么设计／规范澄清要先于实现，以及这种克制能降低哪些偏离、过度构建、责任归属错误或验收缺失风险。保持自然并贴合具体任务；不要将其变成固定的技能调用记录。

当设计方向取决于特定基线文档或当前权威参考资料时，使用精简的 BaselineUsageDraft：

BaselineUsageDraft:
- Required baseline refs:
- Delivered context refs:
- Acknowledged before plan refs:
- Cited in design refs:
- Missing refs:
- Decision: continue | needs-baseline-readback | needs-verification | pause-for-user | blocked

Delivered context refs 只是可选的、由宿主投射的记录信息。它不能作为权威证明，证明宿主注入了上下文载荷或模型在内部使用了该载荷。该产物旨在让基线／上下文关注偏移在提出或批准设计之前变得可见。

当需求尚未确认且完整时，在推荐设计之前使用精简的 Requirement Ready Check：

Requirement Ready Check:
- Requirement source refs:
- Goals and scope refs:
- User / scenario refs:
- Requirement item refs:
- Acceptance / verification criteria refs:
- Open blocker questions:
- Decision: ready | needs-source | needs-goal-alignment | needs-scenario | needs-acceptance-criteria | needs-clarification | needs-user-decision | blocked

在项目权威来源确认之前，将任务意图、对话、源文档和 Agent 推断都视为候选需求来源。如果判定结果不是 ready，就将设计保持在提案／规范澄清层面；不要把缺口转化为实现任务。

Existence Check： 在推荐会新增责任方、技能、产物、宿主适配器、回退方案、兼容路径、工作流步骤或基准指标的方法之前，检查它是否确有必要。以 docs/current/AEGIS_MINIMALITY_REFERENCE.md 为参考。对于复用现有责任方和产物的常规功能设计，不要强行执行此检查。

Existence Check:
- Proposed new surface:
- Existing owner / reuse candidate:
- Why existing surface is insufficient:
- Creation proof:
- Entropy / retirement impact:
- Decision: reuse-existing | add-with-proof | defer | reject | needs-first-principles-review

如果判定结果是 reuse-existing，就推荐复用路径，而不是新增接口。如果判定结果是 add-with-proof，则在设计／规范中保留证明、验证信号以及任何退役触发条件。

Product Risk Lens： 对于含糊的产品、功能、UI、工作流或架构选择，添加精简的审查视角，而非角色扮演：

Product Risk Lens:
- Value:
- Non-goals:
- Trade-offs:
- Decision needed:

这是审查视角，不是角色扮演输出。它不会覆盖基线证据、已批准需求或当前权威文档；它只会让产品风险和决策要点在实现之前变得可见。

Plan-Time Complexity Check： 在为中／高工作量任务选择实现方向之前，检查可能涉及的责任方文件及其当前结构。这是用于施加设计约束的建议性检查，不是门槛，也不具备完成情况判定权。对于微小的低风险修改，不要强行执行此检查。

使用 using-aegis/references/complexity-governance.md 查阅共享产物类别、压力信号解读和超预算处理方式。

Complexity Budget:
- Artifact class:
- Target files / artifacts:
- Current pressure:
- Projected post-change pressure:
- Budget result: within-budget | at-risk | over-budget
- Planned governance:

Plan-Time Complexity Check:
- Better file boundary:
- Recommendation: edit-in-place | extract helper | add owner file | split task | defer refactor

探索方案： 提出 2-3 个方案，说明取舍并给出推荐。明确范围边界：包含什么、延后什么、哪些内容属于其他地方。

在选择方案之前，对任何拟议的新接口执行 Existence Check。如果通过存在性检查后，候选方向仍然引入新的责任方、重复责任方、回退方案、适配器、仅用于兼容的载体、先删除的问题、未经验证的假设或“长期稳定”的主张，则升级至 first-principles-review 及其 Decision Hygiene Review。不要将这两项检查变成通用的设计仪式；决策范围明确后，返回本工作流。

当核心决策涉及内部退役与兼容保留之间的取舍，或持久状态的确认时，组合使用 anti-entropy-governance。它会对删除目标分类、选择 delete-first | compat-exception | confirmation-first，并将破坏性操作的决策权保留在设计技能之外。 当主要风险并非整体策略，而是架构一致性问题时，应使用范围更窄的 Architecture Integrity Lens：例如规范所有者不明确、职责重叠、调用方回退、承载实际逻辑的过时路径，或可能通过更高层级的所有者／契约／事实来源简化架构。推荐方案前，此视角应先给出不变量、规范所有者／契约、职责重叠、更高层级的简化方案、弃用条件／证伪依据以及结论。

Prior-Art & Reuse Lens： 当候选方案会引入新的机制、协议、产物形态或非平凡的交互模式时，应先核实已有的外部实践，再考虑自行设计。此视角由行为触发：当项目中该方向较新、内部复用检查后仍有多个可行方案，或该领域超出当前仓库证据范围时，研究先例。对于已符合知名框架模式的常规工作，不要走研究流程，也不要因网页／搜索工具不可用而阻碍方案选择。

Prior-Art & Reuse Lens:
- Searched precedents: <bounded sources; index-first summary; cite anchor per claim>
- Adopt verbatim: <proven pattern + source>
- Adapt with reason: <tailored part -> project constraint / non-negotiable it maps to>
- Reject with reason: <project fact that makes the pattern inapplicable>
- Degraded: <no web/search tooling -> external basis unknown; internal-only evidence stated>

搜索结果是候选证据，而不是提示词内容：应先概述索引，再引用锚点，而不是粘贴原始页面。没有可引用锚点的“行业标准”说法应保持为 unknown。每项采用／拒绝决策都必须依据具名的项目约束或事实，而非个人喜好。此视角只为方案推荐提供参考；它仅具建议性质，不授予任何完成审批权。

基线角色对齐： 当问题可能同时涉及“应该构建什么”和“应该放在哪里”时，应将需求事实与架构事实分开：

Baseline Role Alignment:
- Product / Requirement Baseline:
- Architecture / Runtime Boundary Baseline:
- Result: aligned | Design Defect | Implementation Drift | missing-authority | needs-clarification
- scope: requirements | architecture | both
- Next action:

当相关需求、设计或基线有误时，使用 Design Defect。当工作偏离了正确且未更改的基线时，使用 Implementation Drift。Architecture Defect 和 Architecture Drift 仍作为架构范围内 Design Defect 和 Implementation Drift 的兼容别名。这是一种审查视角，不是运行时门槛或完成审批权。

呈现设计： 根据复杂度调整各节篇幅。只涵盖重要方面：架构、组件、数据流、错误处理、测试、兼容性边界。当行为、契约、架构或面向用户的流程需要决策时，应在实现前获得设计批准。

ADR 信号： 当设计／规格涉及持久性架构方面（所有者、公共契约、产物形态、依赖方向、事实来源、宿主兼容性、运行时就绪边界、回退、适配器或弃用时间表）时，应标记 ADR 信号、来源引用、实际备选方案，以及预期的基线同步问题，以便后续完成。不要将尚未执行的构想记录为已接受的架构记忆。

面向隔离进行设计： 每个单元都应有一个明确的用途、定义清晰的接口，并且可独立测试。是否无需阅读内部实现就能理解它？能否在不破坏使用方的情况下更改其内部实现？

现有代码库： 遵循现有模式。只有在有助于当前目标时，才纳入有针对性的改进。如果设计涉及契约、兼容性、回退或所有者重复，应直接指出。

条件式详细指导

对于面向用户的界面或交互设计，请组合使用 ui-ux-governance，并将有范围限定的体验规则纳入现有验收标准。此技能保留设计审批权和交接责任。

条件式设计探查、场景配置和工作区／规格文档的详细内容对应下方的明确标题。

仅阅读 expanded-design-guidance.md 中与证据匹配的部分：

• 仅当现有证据不足，且有限范围的探查可能改变设计方向时，阅读 ## Design Probe；
• 仅当工作已归类为其命名的场景类别之一，且针对配置的状态／风险覆盖确有帮助时，阅读 ## Software Scenario Profiles；
• 仅当文档必要性关卡选择了规格或工作区产物时，阅读 ## Documentation And Workspace Bootstrap；
• 仅对书面的设计规格阅读 ## Spec Self-Review；以及
• 仅在初始化对应的确切文件时，阅读具名的基线模板部分。

不要为路由选择、首轮澄清、转向其他路由的情况或正在进行的 Grilling Mode 访谈加载此参考。参考资料提供细节；此主技能仍负责路由、设计审批和交接。

设计就绪与设计完成

满足以下条件时，方案选择即为就绪：

• 已知期望结果和主要场景；
• 已明确范围和非目标；
• 当前行为和目标差异有依据；
• 已识别关键不变量和可能的规范所有者；
• 至少有一项可观察的验收标准；
• 没有尚未解决且仍可能改变方案类别的未知事项。

不必消除所有未知事项；只有可能改变决策的未知事项才会阻碍收敛。

满足所有适用条件时，设计即可交接：

• 已明确选定方案和规范所有者；
• 已区分固定行为／契约与由实现决定的选择；
• 已根据证据对备选方案进行实质比较或排除；
• 关键假设已有证据支持或得到明确认可；
• 在适用情况下，已涵盖故障／恢复和对使用方的影响；
• 验收标准可观察，且可供验证使用；
• 对新所有者、回退方案、适配器、兼容性或持久化，均有创建依据以及退役／回滚处理方案；
• 所有由用户决定的事项都已获得用户的实际批准。

设计完成意味着方法已就绪，而非拥有完成授权。只有满足这些条件后才可转入 writing-plans；不要将尚未解决且可能改变决策的未知事项带入计划。

设计之后

审批通过后，在需要时编写经过验证的规格产物。如果文档必要性关卡选择了工作区或规格文档，请阅读 expanded-design-guidance.md 中适用的部分；否则，将已接受的设计保留在当前会话中。选择工作区支持时，其辅助工具仍位于目标项目之外，并以 <aegis-workspace-helper> 调用。

**Aegis 项目工作区：**是否创建工作区和持久化规格，仍取决于文档必要性关卡和项目权限。

对于设计规格，请完成自审，并在规划前征求用户的明确审阅。根据请求进行修改，并再次审阅。若小型规格简报仅用于明确中等任务的验收要求，可进行简要审阅，除非项目权限要求正式关卡。

实现：

• 调用 writing-plans 技能，创建详细的实现计划
• 不要调用任何其他技能。下一步应为 writing-plans。

核心原则

• 一次只问一个问题 - 不要用多个问题让对方应接不暇
• 优先采用多项选择 - 在可行时，多项选择比开放式问题更容易回答
• 严格遵循 YAGNI - 从所有设计中移除不必要的功能
• 探索备选方案 - 确定方案前，始终提出 2-3 种方法
• 逐步验证 - 提出设计，并在继续之前获得批准
• 保持灵活 - 遇到不合理之处时，返回并澄清