ce:plan-beta

制定技术计划

注意：当前年份是 2026 年。 在计划中注明日期和搜索近期文档时，请以此为准。

ce:brainstorm 定义要构建什么。ce:plan 定义如何构建。ce:work 执行计划。

此工作流会生成一份可长期使用的实施计划。它不会编写代码、运行测试，也不会从执行期间的结果中学习。如果答案取决于修改代码并观察结果，那应属于 ce:work，而不是这里。

交互方式

如果平台提供提问工具，请使用该工具向用户提问。提问时，优先使用平台的阻塞式提问工具（如 Claude Code 中的 AskUserQuestion、Codex 中的 request_user_input、Gemini 中的 ask_user）。否则，请在聊天中列出带编号的选项，并等待用户回复后再继续。

一次只问一个问题。有自然的选项时，优先使用简洁的单选题。

功能描述

<feature_description> #$ARGUMENTS </feature_description>

如果上方的功能描述为空，请询问用户：“你想规划什么？请描述你想到的功能、错误修复或改进。”

在获得明确的规划输入之前，不要继续。

核心原则

1. 以需求为事实依据——如果 ce:brainstorm 生成了需求文档，规划应以此为基础，而不是重新发明行为。
2. 决策，而非代码——记录方案、边界、文件、依赖项、风险和测试场景。不要预先编写实施代码，也不要编排 shell 命令。必要时，可以使用伪代码草图或 DSL 语法来传达高层技术设计，以便评审者验证方向，但必须明确说明它们只是方向性指导，而非实现规范。
3. 先研究，再构建计划结构——在最终确定计划之前，视情况探索代码库、既有经验和外部指南。
4. 产物大小适当——小型工作采用精简计划，大型工作采用更完整的结构。无论详略如何，理念始终一致。
5. 区分规划与执行期间的探索——在此处解决规划阶段的问题。执行阶段才会出现的未知事项应明确留待实施阶段处理。
6. 保持计划可移植——计划应可作为持续更新的文档、评审材料或 issue 正文使用，不要嵌入特定工具的执行者指令。
7. 在必要时适度体现执行方式——如果请求、源文档或仓库上下文明显要求先测试、先进行特征刻画，或采用其他非默认执行方式，应在计划中以简洁提示体现。不要把计划变成逐步执行流程。

计划质量标准

每份计划都应包含：

• 清晰的问题描述和范围边界
• 可追溯到请求或源文档的具体需求
• 拟开展工作的确切文件路径
• 各项包含功能的实施单元对应的明确测试文件路径
• 附带理由的决策，而不只是任务
• 可遵循的现有模式或代码参考
• 具体测试场景和验证结果
• 清晰的依赖关系和顺序

实施者能够有把握地开始工作，而不需要依赖计划来编写代码时，计划才算就绪。

工作流

阶段 0：恢复、来源与范围

0.1 在适当情况下恢复现有计划工作

如果用户提到了现有计划文件，或 docs/plans/ 中存在明显匹配的近期计划：

• 阅读该文件
• 确认是要就地更新，还是创建新计划
• 如果要更新，保留已完成的复选框，并仅修改仍然相关的部分

0.2 查找上游需求文档

在提出规划问题之前，搜索 docs/brainstorms/ 中与 *-requirements.md 匹配的文件。

相关性标准： 如果需求文档满足以下条件，则视为相关：

• 主题在语义上与功能描述相符
• 创建时间在最近 30 天内（可根据判断覆盖此标准，例如文档显然仍然相关或已明显过时）
• 内容似乎涉及相同的用户问题或范围

如果有多个匹配的源文档，请在平台提供阻塞式提问工具时使用该工具询问要使用哪一个（参见“交互方式”）。否则，在聊天中列出编号选项，并等待用户回复后再继续。

0.3 将源文档作为主要输入

如果存在相关需求文档：

1. 仔细阅读
2. 声明该文档将作为规划的源文档
3. 延续保留以下所有内容：
   • 问题框架
   • 需求和成功标准
   • 范围边界
   • 关键决策及其理由
   • 依赖项或假设
   • 尚待解决的问题，并保留其属于阻塞项还是延期处理事项
4. 将源文档作为规划和研究的主要输入
5. 在计划中使用 (see origin: <source-path>) 引用重要的延续决策
6. 不得悄然遗漏源文档中的内容——如果源文档讨论过某项内容，计划就必须至少简要涉及。完成前，逐节检查源文档，确认没有遗漏任何内容。

如果不存在相关需求文档，则可直接根据用户请求继续规划。

0.4 无需求文档时的备用方案

如果不存在相关需求文档：

• 评估该请求是否已经足够明确，可以直接进行技术规划
• 如果主要存在产品定位、用户行为或范围定义方面的歧义，建议先使用 ce:brainstorm
• 如果用户仍想在此处继续，则进行简短的规划准备，而不是拒绝

规划准备应明确：

• 问题框架
• 预期行为
• 范围边界和显而易见的非目标
• 成功标准
• 阻塞性问题或假设

此准备应简明扼要。其目的是保留直接开始的便利性，而非取代完整的头脑风暴。

如果准备过程中发现重大的未决产品问题：

• 再次建议使用 ce:brainstorm
• 如果用户仍想继续，则要求明确列出假设后再继续

0.5 规划前对未决问题进行分类

如果源文档包含 Resolve Before Planning 或类似的阻塞性问题：

• 继续之前，逐一审查
• 仅当问题确实属于技术、架构或研究问题时，才将其重新归类为规划阶段负责处理的工作
• 如果问题会改变产品行为、范围或成功标准，则将其保留为阻塞项

如果仍存在真正的产品阻塞项：

• 明确指出这些问题
• 在平台提供阻塞式提问工具时，使用该工具（参见“交互方式”）询问用户是否要：
  1. 恢复 ce:brainstorm 来解决这些问题
  2. 将其转为明确的假设或决策，然后继续
• 真正的阻塞项尚未解决时，不得继续规划

0.6 评估计划深度

将工作归入以下某种计划深度：

• 轻量级 - 规模小、边界明确、歧义少
• 标准 - 常规功能或范围明确的重构，需要记录一些技术决策
• 深入 - 涉及多个方面、具有战略意义、高风险或实现过程高度不明确的工作

如果无法判断深度，提出一个有针对性的问题，然后继续。

阶段 1：收集上下文

1.1 本地研究（始终运行）

准备一段简洁的规划上下文摘要（1 到 2 段），作为研究 Agent 的输入：

• 如果存在源文档，概述该文档中的问题框架、需求和关键决策
• 否则直接使用功能描述

并行运行以下 Agent：

• Task compound-engineering:research:repo-research-analyst（范围：技术、架构、模式。{planning context summary}）
• Task compound-engineering:research:learnings-researcher（planning context summary）

收集以下信息：

• 技术栈及版本（用于第 1.2 节，以便更准确地决定外部研究方向）
• 应遵循的架构模式和惯例
• 实现模式、相关文件、模块和测试
• 对规划有实质影响的 AGENTS.md 指引；仅当存在 CLAUDE.md 时，才将其用作兼容性回退
• 来自 docs/solutions/ 的内部经验

1.1b 检测执行方式信号

判断计划是否应包含轻量级执行方式信号。

留意以下信号：

• 用户明确要求 TDD、测试优先或特征化优先的工作方式
• 源文档要求测试优先实现，或要求对旧代码进行探索性加固
• 本地研究发现目标区域属于旧代码、测试薄弱或历来脆弱，表明在更改行为前应先补充特征化测试
• 用户要求外部委派、提到“use codex”或“delegate mode”，或提及节省 token——对纯代码编写的实现单元添加 Execution target: external-delegate

如果信号明确，在相关实现单元中静默沿用该方式。

只有当执行方式会实质性改变执行顺序或风险，且无法负责任地推断时，才询问用户。

1.2 判断是否需要外部调研

根据来源文档、用户信号和本地发现，判断外部调研是否有价值。

读懂言外之意。 留意迄今对话中的信号：

• 用户熟悉程度 — 用户是否指出了具体文件或模式？他们很可能熟悉代码库。
• 用户意图 — 用户想要快速推进，还是深入彻底？探索，还是执行？
• 主题风险 — 无论用户信号如何，安全、支付和外部 API 都需要格外谨慎。
• 不确定性程度 — 方案是否明确，还是仍未确定？

利用 repo-research-analyst 的技术背景信息：

repo-research-analyst 的输出包含结构化的 Technology & Infrastructure（技术与基础设施）摘要。利用这些信息，做出更准确的外部调研决策：

• 如果检测到了具体框架及其版本（例如 Rails 7.2、Next.js 14、Go 1.22），将这些确切标识传递给 framework-docs-researcher，以便其获取对应版本的文档
• 如果功能涉及扫描发现已在代码库中成熟应用的技术层（例如，规划新增后台任务时已有 Sidekiq 任务），倾向于跳过外部调研——本地模式可能已经足够
• 如果功能涉及扫描发现代码库中缺失或薄弱的技术层（例如，规划新增 gRPC 服务时没有现有 proto 文件），倾向于开展外部调研——没有可供遵循的本地模式
• 如果扫描检测到了部署基础设施（Docker、K8s、serverless），在传递给下游 Agent 的规划上下文中注明，以便它们考虑部署约束
• 如果扫描检测到了 monorepo，并限定到某个具体服务，则将该服务的技术背景信息传递给下游调研 Agent，而不是所有服务的汇总信息。如果扫描展示了工作区映射但未限定范围，则在继续调研前根据功能描述确定相关服务

在以下情况下，始终倾向于开展外部调研：

• 主题风险较高：安全、支付、隐私、外部 API、迁移、合规
• 代码库缺少相关的本地模式
• 用户正在探索不熟悉的领域
• 技术扫描发现代码库中缺少或薄弱的相关技术层

在以下情况下，跳过外部调研：

• 代码库已展现出成熟的本地模式
• 用户已了解预期方案
• 额外的外部背景信息几乎没有实际价值
• 技术扫描发现相关技术层已十分成熟，且有现成示例可供遵循

继续之前，简要说明这一决策。例如：

• “你的代码库已有成熟的处理模式。我将跳过外部调研，继续进行。”
• “这涉及支付处理，因此我会先调研当前最佳实践。”

1.3 外部调研（按需）

如果第 1.2 步表明外部调研有用，则并行运行以下 Agent：

• Task compound-engineering:research:best-practices-researcher(planning context summary)
• Task compound-engineering:research:framework-docs-researcher(planning context summary)

1.4 汇总调研结果

总结：

• 相关代码库模式及文件路径
• 相关的内部经验
• 收集到的外部参考资料和最佳实践（如有）
• 相关议题、PR 或先前案例
• 可能对计划产生实质影响的任何约束

1.5 流程与边缘情况分析（按需）

对于 Standard 或 Deep 计划，或用户流程的完整性仍不明确时，运行：

• Task compound-engineering:workflow:spec-flow-analyzer(planning context summary, research findings)

利用输出：

• 找出遗漏的边缘情况、状态转换或交接缺口
• 完善需求追踪或验证策略
• 仅添加能实质改善计划的流程细节

第 2 阶段：解决规划问题

根据以下内容列出规划问题：

• 源文档中暂缓处理的问题
• 在代码库或外部调研中发现的空缺
• 制定实用计划所需的技术决策

针对每个问题，判断应当：

• 在规划期间解决——可根据代码库上下文、文档或用户选择确定答案
• 推迟到实施阶段——答案取决于代码更改、运行时行为或执行期间的发现

只有当答案会实质性影响架构、范围、顺序或风险，且无法合理推断时，才询问用户。若平台提供阻塞式提问工具，请使用该工具（参见“交互方式”）。

本阶段不要运行测试、构建应用或探测运行时行为。目标是制定完善的计划，而不是开始部分实施。

第 3 阶段：规划结构

3.1 标题和文件命名

• 使用符合惯例的格式拟定清晰、便于搜索的标题，例如 feat: Add user authentication 或 fix: Prevent checkout double-submit
• 确定计划类型：feat、fix 或 refactor
• 按照代码库约定构建文件名：docs/plans/YYYY-MM-DD-NNN-<type>-<descriptive-name>-beta-plan.md
  • 如果 docs/plans/ 不存在，则创建该目录
  • 检查现有文件中今天日期对应的文件，以确定下一个序号（补零为 3 位，从 001 开始）
  • 描述性名称应简洁（3–5 个单词），并采用 kebab-case 格式
  • 在 -plan 前添加 -beta，以区别于稳定版生成的计划
  • 示例：2026-01-15-001-feat-user-authentication-flow-beta-plan.md、2026-02-03-002-fix-checkout-race-condition-beta-plan.md
  • 避免：缺少序号、使用“new-feature”这类模糊名称、包含无效字符（冒号、空格）

3.2 相关方与影响考量

对于标准或深入计划，简要考虑此变更会影响哪些人——最终用户、开发者、运维人员、其他团队——以及这应如何影响计划。对于涉及多个领域的工作，请在“全系统影响”部分注明受影响方。

3.3 将工作拆分为实施单元

将工作拆分为逻辑清晰的实施单元。每个单元都应代表一项有意义的变更，实施者通常可以将其作为一个原子提交落地。

优秀的单元应当：

• 聚焦于一个组件、一种行为或一个集成边界
• 通常只涉及一小组相关文件
• 按依赖关系排序
• 足够具体，无需预先编写代码即可执行
• 使用复选框语法，以便跟踪进度

避免：

• 2–5 分钟即可完成的微小步骤
• 涉及多个不相关事项的单元
• 过于模糊、仍需实施者自行拟定计划的单元

3.4 高层技术设计（可选）

在详细说明实现单元之前，先判断概述是否有助于审阅者验证预期方案。本节传达解决方案的整体形态——各部分如何协同——但不规定具体实现。

适合纳入的情况：

工作涉及……	最佳概述形式
DSL 或 API 表面设计	伪代码语法或契约草图
多组件集成	Mermaid 时序图或组件图
数据流水线或转换	数据流草图
状态繁多的生命周期	状态图
复杂的分支逻辑	流程图
形态不明显的单组件	伪代码草图

适合省略的情况：

• 模式成熟的工作，用文字和文件路径即可完整说明
• 简单的 CRUD 或遵循既有约定的变更
• 方案显而易见的轻量计划

选择适合这项工作的形式。不要在图表表达更清晰时默认使用伪代码，反之亦然。

每个草图都应注明：*"这仅用于说明预期方案，为审阅提供方向性指导，并非实现规范。实施 Agent 应将其视为背景信息，而不是要照搬的代码。"`

草图应简洁——足以验证方向，但不应详细到可以直接复制粘贴到生产环境。

3.5 定义每个实现单元

每个单元都应包含：

• 目标 - 此单元要实现什么
• 要求 - 此单元推进哪些要求或成功标准
• 依赖项 - 必须先具备什么
• 文件 - 要创建、修改或测试的确切文件路径
• 方案 - 关键决策、数据流、组件边界或集成说明
• 执行说明 - 可选，仅在该单元适合采用非默认执行方式时添加，例如测试优先、特征刻画优先或委派给外部执行方
• 技术设计 - 可选，当单元方案不明显且仅靠文字说明会产生歧义时，可提供伪代码或图表。明确说明这只是方向性指导，而非实现规范
• 遵循的模式 - 要参照的现有代码或约定
• 测试场景 - 要覆盖的具体行为、边界情况和失败路径
• 验证 - 实施者如何通过结果而非 shell 命令脚本来判断单元已完成

每个包含功能的单元都应在 **Files:** 中列出测试文件路径。

谨慎使用 Execution note。适用示例：

• Execution note: Start with a failing integration test for the request/response contract.
• Execution note: Add characterization coverage before modifying this legacy parser.
• Execution note: Implement new domain behavior test-first.
• Execution note: Execution target: external-delegate

不要将单元扩展成字面上的 RED/GREEN/REFACTOR 子步骤。

3.6 区分规划阶段和实施阶段的未知事项

如果某件重要事项目前无法确定，应将其明确记录在延后处理的实施说明中，而不是假装已在计划中解决。

示例：

• 确切的方法或辅助函数名称
• 查看实际代码后才能确定的最终 SQL 或查询细节
• 取决于实际测试失败情况的运行时行为
• 开始实施后可能发现不再需要的重构

阶段 4：编写计划

无论计划的详细程度如何，都采用同一种规划理念。调整细节的多少，而不是改变规划与执行之间的界限。

4.1 计划深度指南

轻量级

• 保持计划精简
• 通常包含 2-4 个实施单元
• 省略价值不大的可选部分

标准

• 使用完整的核心模板，省略对当前工作没有价值的可选部分（包括高层技术设计）
• 通常包含 3-6 个实施单元
• 在相关时包含风险、待定问题和系统级影响

深度

• 使用完整的核心模板，并酌情添加可选分析部分
• 通常包含 4-8 个实施单元
• 在有助于提升清晰度时，将单元分组到不同阶段
• 在适当时纳入已考虑的替代方案、文档影响和更深入的风险处理

4.1b 深度计划的可选扩展

对于规模较大、风险较高或涉及多个方面的工作，可添加确实有帮助的部分：

• 已考虑的替代方案
• 成功指标
• 依赖项／前置条件
• 风险分析与缓解措施
• 分阶段交付
• 文档计划
• 运维／发布说明
• 仅当对当前设计有实质影响时，才添加未来考虑事项

不要将这些内容作为固定模板照搬。只有在能提升执行质量或利益相关方共识时才纳入。

4.2 核心计划模板

省略明显不适用的可选部分，尤其是轻量级计划中的可选部分。

---
title: [Plan Title]
type: [feat|fix|refactor]
status: active
date: YYYY-MM-DD
origin: docs/brainstorms/YYYY-MM-DD-<topic>-requirements.md  # include when planning from a requirements doc
deepened: YYYY-MM-DD  # optional, set later by deepen-plan-beta when the plan is substantively strengthened
---

# [Plan Title]

## Overview

[What is changing and why]

## Problem Frame

[Summarize the user/business problem and context. Reference the origin doc when present.]

## Requirements Trace

- R1. [Requirement or success criterion this plan must satisfy]
- R2. [Requirement or success criterion this plan must satisfy]

## Scope Boundaries

- [Explicit non-goal or exclusion]

## Context & Research

### Relevant Code and Patterns

- [Existing file, class, component, or pattern to follow]

### Institutional Learnings

- [Relevant `docs/solutions/` insight]

### External References

- [Relevant external docs or best-practice source, if used]

## Key Technical Decisions

- [Decision]: [Rationale]

## Open Questions

### Resolved During Planning

- [Question]: [Resolution]

### Deferred to Implementation

- [Question or unknown]: [Why it is intentionally deferred]


## High-Level Technical Design

> *This illustrates the intended approach and is directional guidance for review, not implementation specification. The implementing agent should treat it as context, not code to reproduce.*

[Pseudo-code grammar, mermaid diagram, data flow sketch, or state diagram — choose the medium that best communicates the solution shape for this work.]

## Implementation Units

- [ ] **Unit 1: [Name]**

**Goal:** [What this unit accomplishes]

**Requirements:** [R1, R2]

**Dependencies:** [None / Unit 1 / external prerequisite]

**Files:**
- Create: `path/to/new_file`
- Modify: `path/to/existing_file`
- Test: `path/to/test_file`

**Approach:**
- [Key design or sequencing decision]

**Execution note:** [Optional test-first, characterization-first, external-delegate, or other execution posture signal]

**Technical design:** *(optional -- pseudo-code or diagram when the unit's approach is non-obvious. Directional guidance, not implementation specification.)*

**Patterns to follow:**
- [Existing file, class, or pattern]

**Test scenarios:**
- [Specific scenario with expected behavior]
- [Edge case or failure path]

**Verification:**
- [Outcome that should hold when this unit is complete]

## System-Wide Impact

- **Interaction graph:** [What callbacks, middleware, observers, or entry points may be affected]
- **Error propagation:** [How failures should travel across layers]
- **State lifecycle risks:** [Partial-write, cache, duplicate, or cleanup concerns]
- **API surface parity:** [Other interfaces that may require the same change]
- **Integration coverage:** [Cross-layer scenarios unit tests alone will not prove]

## Risks & Dependencies

- [Meaningful risk, dependency, or sequencing concern]

## Documentation / Operational Notes

- [Docs, rollout, monitoring, or support impacts when relevant]

## Sources & References

- **Origin document:** [docs/brainstorms/YYYY-MM-DD-<topic>-requirements.md](path)
- Related code: [path or symbol]
- Related PRs/issues: #[number]
- External docs: [url]

对于较大的深度计划，仅在有用时才通过以下部分扩展核心模板：

## Alternative Approaches Considered

- [Approach]: [Why rejected or not chosen]

## Success Metrics

- [How we will know this solved the intended problem]

## Dependencies / Prerequisites

- [Technical, organizational, or rollout dependency]

## Risk Analysis & Mitigation

- [Risk]: [Mitigation]

## Phased Delivery

### Phase 1
- [What lands first and why]

### Phase 2
- [What follows and why]

## Documentation Plan

- [Docs or runbooks to update]

## Operational / Rollout Notes

- [Monitoring, migration, feature flag, or rollout considerations]

4.3 规划规则

• 优先使用路径加类／组件／模式引用，而不是脆弱的行号
• 使用 - [ ] 语法编写可检查的实施单元，以便跟踪进度
• 不要包含实施代码——不要写导入语句、确切的方法签名或特定于框架的语法
• 如果伪代码草图和 DSL 语法能传达设计方向，可以在高层技术设计部分和各单元的技术设计字段中使用。应明确说明它们是方向性指导，而非实施规范
• 如果 Mermaid 图能清晰说明仅靠文字难以表达的关系或流程，则建议使用——例如，数据模型变更使用 ER 图、多服务交互使用时序图、生命周期转换使用状态图、复杂分支逻辑使用流程图
• 不要包含 git 命令、提交消息或精确的测试命令步骤
• 不要将实施单元细化为微小的 RED/GREEN/REFACTOR 操作步骤
• 不要为了让计划看起来完整，就假装执行时的问题已经解决

阶段 5：最终审查、写入文件并交接

5.1 写入前审查

定稿前，请检查：

• 计划没有臆造本应在 ce:brainstorm 中定义的产品行为
• 如果没有源文档，有界限的规划引导已建立足够的产品清晰度，能够负责任地制定计划
• 每项重大决策都有源文档或研究作为依据
• 每个实施单元都具体明确、依赖顺序合理，并已做好实施准备
• 如果明确要求或强烈暗示先编写测试或先进行特征描述，相关单元应通过轻量级的 Execution note 延续这一要求
• 测试场景具体明确，但不应细化到测试代码
• 明确说明延期事项，不要将其伪装成已确定的内容
• 如果包含“高层技术设计”部分，须根据工作内容选择合适的表达形式，采用非规定性表述，且不包含实现代码（不包含导入语句、确切签名或特定框架语法）
• 如果存在单元级技术设计字段，内容应简洁且提供方向，而非可直接复制粘贴使用

如果计划源自需求文档，请重新阅读该文档并确认：

• 所选方案仍符合产品意图
• 保留了范围边界和成功标准
• 阻塞性问题已得到解决、明确假设，或退回至 ce:brainstorm
• 计划涵盖了源文档的每个部分——逐节检查，确认没有内容被悄然遗漏

5.2 编写计划文件

必须：在提出任何选项之前，将计划文件写入磁盘。

使用 Write 工具，将完整计划保存到：

docs/plans/YYYY-MM-DD-NNN-<type>-<descriptive-name>-beta-plan.md

确认：

Plan written to docs/plans/[filename]

流水线模式： 如果由 LFG、SLFG 等自动化工作流，或任何 disable-model-invocation 上下文调用，则跳过交互式提问。自动做出所需选择，并继续编写计划。

5.3 生成后的选项

写入计划文件后，如果平台提供阻塞式提问工具，请使用该工具展示选项（参见“交互方式”）。否则，在聊天中列出编号选项，并等待用户回复后再继续。

问题：“计划已就绪，位于 docs/plans/YYYY-MM-DD-NNN-<type>-<name>-beta-plan.md。接下来你想做什么？”

选项：

1. 在编辑器中打开计划 - 打开计划文件以供审阅
2. 运行 /deepen-plan-beta - 当计划需要更多把握时，通过针对性研究对薄弱部分进行压力测试
3. 运行 document-review 技能 - 通过结构化文档审阅改进计划
4. 分享到 Proof - 上传计划，以便协作审阅和分享
5. 启动 /ce:work - 在当前环境中开始实施此计划
6. 在另一个会话中启动 /ce:work - 如果当前平台支持，在单独的 Agent 会话中开始实施
7. 创建 Issue - 在已配置的跟踪系统中创建 Issue

根据选择执行：

• 在编辑器中打开计划 → 使用当前平台的文件打开或编辑器机制打开 docs/plans/<plan_filename>.md（例如，在 macOS 上使用 open，在 Linux 上使用 xdg-open，或使用 IDE 的文件打开 API）
• /deepen-plan-beta → 使用计划路径调用 /deepen-plan-beta
• document-review 技能 → 使用计划路径加载 document-review 技能
• 分享到 Proof → 上传计划：

  CONTENT=$(cat docs/plans/<plan_filename>.md)
  TITLE="Plan: <plan title from frontmatter>"
  RESPONSE=$(curl -s -X POST https://www.proofeditor.ai/share/markdown \
    -H "Content-Type: application/json" \
    -d "$(jq -n --arg title "$TITLE" --arg markdown "$CONTENT" --arg by "ai:compound" '{title: $title, markdown: $markdown, by: $by}')")
  PROOF_URL=$(echo "$RESPONSE" | jq -r '.tokenUrl')
  

  如果成功，显示 View & collaborate in Proof: <PROOF_URL>，然后返回选项
• /ce:work → 使用计划路径调用 /ce:work
• 在另一个会话中启动 /ce:work → 如果当前平台支持启动单独的 Agent 会话，则在其中使用计划路径启动 /ce:work。否则，简要说明此限制，并提出改为在当前会话中运行 /ce:work。
• 创建 Issue → 按照下文“创建 Issue”部分操作
• 其他 → 接受自由文本形式的修改请求，并返回选项

如果启用了 ultrathink，或者平台的推理/工作量级别设为 max 或 extra-high，则仅当计划属于 Standard 或 Deep、风险较高，或在决策、排序、系统级影响、风险或验证方面仍存在明显的信心缺口时，才自动运行 /deepen-plan-beta。

创建 Issue

当用户选择“创建 Issue”时，从 AGENTS.md 中检测其项目跟踪系统；如需兼容性支持，则从 CLAUDE.md 中检测：

1. 查找 project_tracker: github 或 project_tracker: linear

2. 如果是 GitHub：

   gh issue create --title "<type>: <title>" --body-file <plan_path>
   

3. 如果是 Linear：

   linear issue create --title "<title>" --description "$(cat <plan_path>)"
   

4. 如果未配置跟踪系统：

   • 如果平台提供阻塞式提问工具，请使用该工具询问用户使用哪种跟踪系统（参见“交互方式”）
   • 建议将跟踪系统添加到 AGENTS.md，以便后续运行使用

创建 Issue 后：

• 显示 Issue URL
• 询问是否继续执行 /ce:work

绝不编写代码！进行研究、做出决策并撰写计划。