Back to Details

deepen-plan-beta

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Deepen Plan

深化计划

Introduction

简介

Note: The current year is 2026. Use this when searching for recent documentation and best practices.
ce:plan-beta
does the first planning pass. 
deepen-plan-beta
is a second-pass confidence check.
Use this skill when the plan already exists and the question is not "Is this document clear?" but rather "Is this plan grounded enough for the complexity and risk involved?"
This skill does not turn plans into implementation scripts. It identifies weak sections, runs targeted research only for those sections, and strengthens the plan in place.
document-review
and 
deepen-plan-beta
are different:
  • Use the 
    document-review
    skill when the document needs clarity, simplification, completeness, or scope control
  • Use 
    deepen-plan-beta
    when the document is structurally sound but still needs stronger rationale, sequencing, risk treatment, or system-wide thinking
注意：当前年份为2026年。 搜索最新文档和最佳实践时请以此为准。
ce:plan-beta
负责首次规划环节，
deepen-plan-beta
是用于提升可信度的二次检查环节。
当计划已存在，且核心问题并非「这份文档是否清晰？」而是「该计划是否足够适配所涉及的复杂度和风险？」时，使用此技能。
本技能不会将计划转换为实施脚本。它会识别薄弱环节，仅针对这些环节开展针对性研究，并原地强化计划。
document-review
和 
deepen-plan-beta
的区别：
  • 当文档需要提升清晰度、简化内容、补充完整性或控制范围时，使用 
    document-review
    技能
  • 当文档结构合理，但仍需强化理论依据、排序逻辑、风险处理或系统级思考时，使用 
    deepen-plan-beta

Interaction Method

交互方式

Use the platform's question tool when available. When asking the user a question, prefer the platform's blocking question tool if one exists (
AskUserQuestion
in Claude Code, 
request_user_input
in Codex, 
ask_user
in Gemini). Otherwise, present numbered options in chat and wait for the user's reply before proceeding.
Ask one question at a time. Prefer a concise single-select choice when natural options exist.
请在可用时使用平台的提问工具。向用户提问时，若平台存在阻塞式提问工具（如Claude Code中的
AskUserQuestion
、Codex中的
request_user_input
、Gemini中的
ask_user
），请优先使用。否则，在聊天中列出带编号的选项，等待用户回复后再继续。
一次只提一个问题。若存在自然选项，优先采用简洁的单选形式。

Plan File

计划文件

<plan_path> #$ARGUMENTS </plan_path>
If the plan path above is empty:
  1. Check 
    docs/plans/
    for recent files
  2. Ask the user which plan to deepen using the platform's blocking question tool when available (see Interaction Method). Otherwise, present numbered options in chat and wait for the user's reply before proceeding
Do not proceed until you have a valid plan file path.
<plan_path> #$ARGUMENTS </plan_path>
若上述计划路径为空：
  1. 检查
    docs/plans/
    目录下的最新文件
  2. 若平台支持阻塞式提问工具，请使用该工具询问用户要深化哪份计划（参见交互方式）。否则，在聊天中列出带编号的选项，等待用户回复后再继续
在获取有效计划文件路径前，请勿继续操作。

Core Principles

核心原则

  1. Stress-test, do not inflate - Deepening should increase justified confidence, not make the plan longer for its own sake.
  2. Selective depth only - Focus on the weakest 2-5 sections rather than enriching everything.
  3. Preserve the planning boundary - No implementation code, no git command choreography, no exact test command recipes.
  4. Use artifact-contained evidence - Work from the written plan, its 
    Context & Research
    , 
    Sources & References
    , and its origin document when present.
  5. Respect product boundaries - Do not invent new product requirements. If deepening reveals a product-level gap, surface it as an open question or route back to 
    ce:brainstorm
    .
  6. Prioritize risk and cross-cutting impact - The more dangerous or interconnected the work, the more valuable another planning pass becomes.
  1. 压力测试，而非冗余扩充 - 深化应提升合理可信度，而非单纯增加计划篇幅
  2. 仅选择性深化 - 聚焦最薄弱的2-5个环节，而非全面扩充所有内容
  3. 保留规划边界 - 不添加实施代码、Git命令编排或精确的测试命令方案
  4. 使用已有证据 - 基于书面计划、其
    Context & Research
    、
    Sources & References
    部分以及原始文档（若存在）开展工作
  5. 尊重产品边界 - 不得凭空提出新的产品需求。若深化过程中发现产品层面的缺口，将其列为未解决问题，或建议使用
    ce:brainstorm
    技能
  6. 优先处理风险和跨系统影响 - 工作的危险性或关联性越强，二次规划的价值越高

Workflow

工作流程

Phase 0: Load the Plan and Decide Whether Deepening Is Warranted

阶段0：加载计划并判断是否需要深化

0.1 Read the Plan and Supporting Inputs

0.1 阅读计划及支持性输入内容

Read the plan file completely.
If the plan frontmatter includes an 
origin:
path:
  • Read the origin document too
  • Use it to check whether the plan still reflects the product intent, scope boundaries, and success criteria
完整阅读计划文件。
若计划前置元数据包含
origin:
路径：
  • 同时阅读原始文档
  • 用它检查计划是否仍符合产品意图、范围边界和成功标准

0.2 Classify Plan Depth and Topic Risk

0.2 分类计划深度和主题风险

Determine the plan depth from the document:
  • Lightweight - small, bounded, low ambiguity, usually 2-4 implementation units
  • Standard - moderate complexity, some technical decisions, usually 3-6 units
  • Deep - cross-cutting, high-risk, or strategically important work, usually 4-8 units or phased delivery
Also build a risk profile. Treat these as high-risk signals:
  • Authentication, authorization, or security-sensitive behavior
  • Payments, billing, or financial flows
  • Data migrations, backfills, or persistent data changes
  • External APIs or third-party integrations
  • Privacy, compliance, or user data handling
  • Cross-interface parity or multi-surface behavior
  • Significant rollout, monitoring, or operational concerns
根据文档确定计划深度：
  • 轻量型 - 规模小、边界清晰、歧义少，通常包含2-4个实施单元
  • 标准型 - 复杂度中等，涉及部分技术决策，通常包含3-6个实施单元
  • 深度型 - 跨系统、高风险或具有战略重要性的工作，通常包含4-8个实施单元或分阶段交付
同时构建风险档案。以下情况视为高风险信号：
  • 身份验证、授权或安全敏感行为
  • 支付、计费或财务流程
  • 数据迁移、回填或持久化数据变更
  • 外部API或第三方集成
  • 隐私、合规或用户数据处理
  • 跨界面一致性或多端行为
  • 重大发布、监控或运维相关问题

0.3 Decide Whether to Deepen

0.3 判断是否需要深化

Use this default:
  • Lightweight plans usually do not need deepening unless they are high-risk or the user explicitly requests it
  • Standard plans often benefit when one or more important sections still look thin
  • Deep or high-risk plans often benefit from a targeted second pass
If the plan already appears sufficiently grounded:
  • Say so briefly
  • Recommend moving to 
    /ce:work
    or the 
    document-review
    skill
  • If the user explicitly asked to deepen anyway, continue with a light pass and deepen at most 1-2 sections
遵循以下默认规则：
  • 轻量型计划通常无需深化，除非属于高风险主题或用户明确要求
  • 标准型计划若存在一个或多个内容单薄的重要环节，通常能从深化中获益
  • 深度型或高风险计划通常能从针对性的二次规划中获益
若计划已足够扎实：
  • 简要告知用户
  • 建议转向
    /ce:work
    或
    document-review
    技能
  • 若用户仍明确要求深化，则进行轻度处理，最多深化1-2个环节

Phase 1: Parse the Current 
ce:plan-beta
Structure

阶段1：解析当前
ce:plan-beta
结构

Map the plan into the current template. Look for these sections, or their nearest equivalents:
  • Overview
  • Problem Frame
  • Requirements Trace
  • Scope Boundaries
  • Context & Research
  • Key Technical Decisions
  • Open Questions
  • Implementation Units
  • System-Wide Impact
  • Risks & Dependencies
  • Documentation / Operational Notes
  • Sources & References
  • Optional deep-plan sections such as 
    Alternative Approaches Considered
    , 
    Success Metrics
    , 
    Phased Delivery
    , 
    Risk Analysis & Mitigation
    , and 
    Operational / Rollout Notes
If the plan was written manually or uses different headings:
  • Map sections by intent rather than exact heading names
  • If a section is structurally present but titled differently, treat it as the equivalent section
  • If the plan truly lacks a section, decide whether that absence is intentional for the plan depth or a confidence gap worth scoring
Also collect:
  • Frontmatter, including existing 
    deepened:
    date if present
  • Number of implementation units
  • Which files and test files are named
  • Which learnings, patterns, or external references are cited
  • Which sections appear omitted because they were unnecessary versus omitted because they are missing
将计划映射到当前模板。查找以下部分或其等效内容：
  • Overview
  • Problem Frame
  • Requirements Trace
  • Scope Boundaries
  • Context & Research
  • Key Technical Decisions
  • Open Questions
  • Implementation Units
  • System-Wide Impact
  • Risks & Dependencies
  • Documentation / Operational Notes
  • Sources & References
  • 可选的深度计划部分，如
    Alternative Approaches Considered
    、
    Success Metrics
    、
    Phased Delivery
    、
    Risk Analysis & Mitigation
    和
    Operational / Rollout Notes
若计划为手动编写或使用不同标题：
  • 根据意图而非精确标题名称映射环节
  • 若环节结构存在但标题不同，视为等效环节
  • 若计划确实缺少某环节，判断该缺失是因计划深度无需此环节，还是属于需填补的可信度缺口
同时收集：
  • 前置元数据，包括已有的
    deepened:
    日期（若存在）
  • 实施单元数量
  • 提及的文件和测试文件名称
  • 引用的经验、模式或外部参考资料
  • 区分因无需而省略的环节和因缺失而省略的环节

Phase 2: Score Confidence Gaps

阶段2：评估可信度缺口

Use a checklist-first, risk-weighted scoring pass.
For each section, compute:
  • Trigger count - number of checklist problems that apply
  • Risk bonus - add 1 if the topic is high-risk and this section is materially relevant to that risk
  • Critical-section bonus - add 1 for 
    Key Technical Decisions
    , 
    Implementation Units
    , 
    System-Wide Impact
    , 
    Risks & Dependencies
    , or 
    Open Questions
    in 
    Standard
    or 
    Deep
    plans
Treat a section as a candidate if:
  • it hits 2+ total points, or
  • it hits 1+ point in a high-risk domain and the section is materially important
Choose only the top 2-5 sections by score. If the user explicitly asked to deepen a lightweight plan, cap at 1-2 sections unless the topic is high-risk.
Example:
  • A 
    Key Technical Decisions
    section with 1 checklist trigger and the critical-section bonus scores 2 points and is a candidate
  • A 
    Risks & Dependencies
    section with 1 checklist trigger in a high-risk migration plan also becomes a candidate because the risk bonus applies
If the plan already has a 
deepened:
date:
  • Prefer sections that have not yet been substantially strengthened, if their scores are comparable
  • Revisit an already-deepened section only when it still scores clearly higher than alternatives or the user explicitly asks for another pass on it
采用 checklist优先、风险加权的评估方式。
对每个环节计算：
  • 触发次数 - 符合的checklist问题数量
  • 风险加分 - 若主题为高风险且该环节与风险直接相关，加1分
  • 关键环节加分 - 对于标准或深度计划中的
    Key Technical Decisions
    、
    Implementation Units
    、
    System-Wide Impact
    、
    Risks & Dependencies
    或
    Open Questions
    环节，加1分
若满足以下条件，该环节视为候选：
  • 总得分≥2分，或
  • 在高风险领域得分≥1分且该环节至关重要
仅选择得分最高的2-5个环节。若用户明确要求深化轻量型计划，最多选择1-2个环节，除非主题为高风险。
示例：
  • 一个
    Key Technical Decisions
    环节有1个checklist触发项，加上关键环节加分，总得分2分，成为候选
  • 高风险迁移计划中的
    Risks & Dependencies
    环节有1个checklist触发项，加上风险加分，也成为候选
若计划已包含
deepened:
日期：
  • 若得分相近，优先选择尚未大幅强化的环节
  • 仅当已深化环节的得分明显高于其他环节，或用户明确要求再次深化时，才重新审视该环节

2.1 Section Checklists

2.1 环节检查清单

Use these triggers.
Requirements Trace
  • Requirements are vague or disconnected from implementation units
  • Success criteria are missing or not reflected downstream
  • Units do not clearly advance the traced requirements
  • Origin requirements are not clearly carried forward
Context & Research / Sources & References
  • Relevant repo patterns are named but never used in decisions or implementation units
  • Cited learnings or references do not materially shape the plan
  • High-risk work lacks appropriate external or internal grounding
  • Research is generic instead of tied to this repo or this plan
Key Technical Decisions
  • A decision is stated without rationale
  • Rationale does not explain tradeoffs or rejected alternatives
  • The decision does not connect back to scope, requirements, or origin context
  • An obvious design fork exists but the plan never addresses why one path won
Open Questions
  • Product blockers are hidden as assumptions
  • Planning-owned questions are incorrectly deferred to implementation
  • Resolved questions have no clear basis in repo context, research, or origin decisions
  • Deferred items are too vague to be useful later
Implementation Units
  • Dependency order is unclear or likely wrong
  • File paths or test file paths are missing where they should be explicit
  • Units are too large, too vague, or broken into micro-steps
  • Approach notes are thin or do not name the pattern to follow
  • Test scenarios or verification outcomes are vague
System-Wide Impact
  • Affected interfaces, callbacks, middleware, entry points, or parity surfaces are missing
  • Failure propagation is underexplored
  • State lifecycle, caching, or data integrity risks are absent where relevant
  • Integration coverage is weak for cross-layer work
Risks & Dependencies / Documentation / Operational Notes
  • Risks are listed without mitigation
  • Rollout, monitoring, migration, or support implications are missing when warranted
  • External dependency assumptions are weak or unstated
  • Security, privacy, performance, or data risks are absent where they obviously apply
Use the plan's own 
Context & Research
and 
Sources & References
as evidence. If those sections cite a pattern, learning, or risk that never affects decisions, implementation units, or verification, treat that as a confidence gap.
使用以下触发条件。
Requirements Trace
  • 需求模糊或与实施单元脱节
  • 缺少成功标准，或成功标准未在后续内容中体现
  • 实施单元未明确推进已追踪的需求
  • 原始需求未清晰延续
Context & Research / Sources & References
  • 提及了相关仓库模式，但未在决策或实施单元中使用
  • 引用的经验或参考资料未对计划产生实质性影响
  • 高风险工作缺乏适当的内部或外部依据
  • 研究内容泛泛而谈，未结合本仓库或本计划
Key Technical Decisions
  • 仅陈述决策，未说明依据
  • 依据未解释权衡或被否决的替代方案
  • 决策未与范围、需求或原始上下文关联
  • 存在明显的设计分支，但计划未说明为何选择当前路径
Open Questions
  • 产品阻塞项被隐藏为假设
  • 属于规划阶段的问题被错误地推迟到实施阶段
  • 已解决的问题未基于仓库上下文、研究或原始决策提供明确依据
  • 推迟的项目过于模糊，对后续工作无实际价值
Implementation Units
  • 依赖顺序不清晰或可能错误
  • 应明确的文件路径或测试文件路径缺失
  • 实施单元过大、过于模糊或被拆分为微步骤
  • 方法说明单薄，未提及需遵循的模式
  • 测试场景或验证结果模糊
System-Wide Impact
  • 缺失受影响的接口、回调、中间件、入口点或一致性关联面
  • 未充分探讨故障传播
  • 相关场景下未提及状态生命周期、缓存或数据完整性风险
  • 跨层工作的集成覆盖不足
Risks & Dependencies / Documentation / Operational Notes
  • 仅列出风险，未给出缓解措施
  • 必要时缺失发布、监控、迁移或支持相关影响说明
  • 外部依赖假设薄弱或未明确说明
  • 明显存在的安全、隐私、性能或数据风险未被提及
使用计划自身的
Context & Research
和
Sources & References
作为证据。若这些环节引用的模式、经验或风险未对决策、实施单元或验证产生影响，则视为可信度缺口。

Phase 3: Select Targeted Research Agents

阶段3：选择针对性研究Agent

For each selected section, choose the smallest useful agent set. Do not run every agent. Use at most 1-3 agents per section and usually no more than 8 agents total.
Use fully-qualified agent names inside Task calls.
为每个选中的环节选择最小的有效Agent集合。不要运行所有Agent。每个环节最多使用1-3个Agent，总Agent数量通常不超过8个。
在任务调用中使用完整的Agent名称。

3.1 Deterministic Section-to-Agent Mapping

3.1 环节到Agent的确定性映射

Requirements Trace / Open Questions classification
  • compound-engineering:workflow:spec-flow-analyzer
    for missing user flows, edge cases, and handoff gaps
  • compound-engineering:research:repo-research-analyst
    for repo-grounded patterns, conventions, and implementation reality checks
Context & Research / Sources & References gaps
  • compound-engineering:research:learnings-researcher
    for institutional knowledge and past solved problems
  • compound-engineering:research:framework-docs-researcher
    for official framework or library behavior
  • compound-engineering:research:best-practices-researcher
    for current external patterns and industry guidance
  • Add 
    compound-engineering:research:git-history-analyzer
    only when historical rationale or prior art is materially missing
Key Technical Decisions
  • compound-engineering:review:architecture-strategist
    for design integrity, boundaries, and architectural tradeoffs
  • Add 
    compound-engineering:research:framework-docs-researcher
    or 
    compound-engineering:research:best-practices-researcher
    when the decision needs external grounding beyond repo evidence
Implementation Units / Verification
  • compound-engineering:research:repo-research-analyst
    for concrete file targets, patterns to follow, and repo-specific sequencing clues
  • compound-engineering:review:pattern-recognition-specialist
    for consistency, duplication risks, and alignment with existing patterns
  • Add 
    compound-engineering:workflow:spec-flow-analyzer
    when sequencing depends on user flow or handoff completeness
System-Wide Impact
  • compound-engineering:review:architecture-strategist
    for cross-boundary effects, interface surfaces, and architectural knock-on impact
  • Add the specific specialist that matches the risk: 
    • compound-engineering:review:performance-oracle
      for scalability, latency, throughput, and resource-risk analysis
    • compound-engineering:review:security-sentinel
      for auth, validation, exploit surfaces, and security boundary review
    • compound-engineering:review:data-integrity-guardian
      for migrations, persistent state safety, consistency, and data lifecycle risks
Risks & Dependencies / Operational Notes
  • Use the specialist that matches the actual risk: 
    • compound-engineering:review:security-sentinel
      for security, auth, privacy, and exploit risk
    • compound-engineering:review:data-integrity-guardian
      for persistent data safety, constraints, and transaction boundaries
    • compound-engineering:review:data-migration-expert
      for migration realism, backfills, and production data transformation risk
    • compound-engineering:review:deployment-verification-agent
      for rollout checklists, rollback planning, and launch verification
    • compound-engineering:review:performance-oracle
      for capacity, latency, and scaling concerns
Requirements Trace / Open Questions分类
  • compound-engineering:workflow:spec-flow-analyzer
    - 用于查找缺失的用户流程、边缘情况和交接缺口
  • compound-engineering:research:repo-research-analyst
    - 用于基于仓库的模式、规范和实施现实检查
Context & Research / Sources & References缺口
  • compound-engineering:research:learnings-researcher
    - 用于查找机构知识和已解决的历史问题
  • compound-engineering:research:framework-docs-researcher
    - 用于查找官方框架或库的行为说明
  • compound-engineering:research:best-practices-researcher
    - 用于查找当前的外部模式和行业指南
  • 仅当历史依据或先例严重缺失时，添加
    compound-engineering:research:git-history-analyzer
Key Technical Decisions
  • compound-engineering:review:architecture-strategist
    - 用于设计完整性、边界和架构权衡
  • 当决策需要超出仓库证据的外部依据时，添加
    compound-engineering:research:framework-docs-researcher
    或
    compound-engineering:research:best-practices-researcher
Implementation Units / Verification
  • compound-engineering:research:repo-research-analyst
    - 用于查找具体的文件目标、需遵循的模式和仓库特定的排序线索
  • compound-engineering:review:pattern-recognition-specialist
    - 用于检查一致性、重复风险和与现有模式的对齐情况
  • 当排序依赖于用户流程或交接完整性时，添加
    compound-engineering:workflow:spec-flow-analyzer
System-Wide Impact
  • compound-engineering:review:architecture-strategist
    - 用于跨边界影响、接口面和架构连锁反应分析
  • 根据风险类型添加对应专家： 
    • compound-engineering:review:performance-oracle
      - 用于可扩展性、延迟、吞吐量和资源风险分析
    • compound-engineering:review:security-sentinel
      - 用于身份验证、验证、攻击面和安全边界审查
    • compound-engineering:review:data-integrity-guardian
      - 用于迁移、持久化状态安全、一致性和数据生命周期风险分析
Risks & Dependencies / Operational Notes
  • 根据实际风险选择对应专家： 
    • compound-engineering:review:security-sentinel
      - 用于安全、身份验证、隐私和攻击风险
    • compound-engineering:review:data-integrity-guardian
      - 用于持久化数据安全、约束和事务边界
    • compound-engineering:review:data-migration-expert
      - 用于迁移可行性、回填和生产数据转换风险
    • compound-engineering:review:deployment-verification-agent
      - 用于发布检查清单、回滚规划和上线验证
    • compound-engineering:review:performance-oracle
      - 用于容量、延迟和扩展相关问题

3.2 Agent Prompt Shape

3.2 Agent提示语格式

For each selected section, pass:
  • A short plan summary
  • The exact section text
  • Why the section was selected, including which checklist triggers fired
  • The plan depth and risk profile
  • A specific question to answer
Instruct the agent to return:
  • findings that change planning quality
  • stronger rationale, sequencing, verification, risk treatment, or references
  • no implementation code
  • no shell commands
为每个选中的环节提供：
  • 简短的计划摘要
  • 该环节的准确文本
  • 选中该环节的原因，包括触发的checklist条件
  • 计划深度和风险档案
  • 具体的待回答问题
指示Agent返回：
  • 能提升规划质量的发现
  • 更充分的依据、排序逻辑、验证方式、风险处理措施或参考资料
  • 不得包含实施代码
  • 不得包含Shell命令

Phase 4: Run Targeted Research and Review

阶段4：运行针对性研究和审查

Launch the selected agents in parallel.
Prefer local repo and institutional evidence first. Use external research only when the gap cannot be closed responsibly from repo context or already-cited sources.
If a selected section can be improved by reading the origin document more carefully, do that before dispatching external agents.
If agent outputs conflict:
  • Prefer repo-grounded and origin-grounded evidence over generic advice
  • Prefer official framework documentation over secondary best-practice summaries when the conflict is about library behavior
  • If a real tradeoff remains, record it explicitly in the plan rather than pretending the conflict does not exist
并行启动选中的Agent。
优先使用本地仓库和机构内部证据。仅当无法通过仓库上下文或已引用资源填补缺口时，才使用外部研究。
若选中环节可通过更仔细阅读原始文档得到优化，在调度外部Agent前先完成此项工作。
若Agent输出存在冲突：
  • 优先采用基于仓库和原始文档的证据，而非通用建议
  • 当涉及库行为的冲突时，优先采用官方框架文档，而非二次最佳实践总结
  • 若仍存在实际权衡，在计划中明确记录，而非假装冲突不存在

Phase 5: Synthesize and Rewrite the Plan

阶段5：合成并重写计划

Strengthen only the selected sections. Keep the plan coherent and preserve its overall structure.
Allowed changes:
  • Clarify or strengthen decision rationale
  • Tighten requirements trace or origin fidelity
  • Reorder or split implementation units when sequencing is weak
  • Add missing pattern references, file/test paths, or verification outcomes
  • Expand system-wide impact, risks, or rollout treatment where justified
  • Reclassify open questions between 
    Resolved During Planning
    and 
    Deferred to Implementation
    when evidence supports the change
  • Add an optional deep-plan section only when it materially improves execution quality
  • Add or update 
    deepened: YYYY-MM-DD
    in frontmatter when the plan was substantively improved
Do not:
  • Add fenced implementation code blocks unless the plan itself is about code shape as a design artifact
  • Add git commands, commit choreography, or exact test command recipes
  • Add generic 
    Research Insights
    subsections everywhere
  • Rewrite the entire plan from scratch
  • Invent new product requirements, scope changes, or success criteria without surfacing them explicitly
If research reveals a product-level ambiguity that should change behavior or scope:
  • Do not silently decide it here
  • Record it under 
    Open Questions
  • Recommend 
    ce:brainstorm
    if the gap is truly product-defining
仅强化选中的环节。保持计划的连贯性，保留其整体结构。
允许的修改：
  • 明确或强化决策依据
  • 收紧需求追踪或原始文档的一致性
  • 当排序逻辑薄弱时，重新排序或拆分实施单元
  • 添加缺失的模式引用、文件/测试路径或验证结果
  • 在合理情况下扩展系统级影响、风险或发布处理内容
  • 当证据支持时，重新分类未解决问题为「规划阶段解决」或「推迟到实施阶段」
  • 仅当能实质性提升执行质量时，添加可选的深度计划环节
  • 当计划得到实质性改进时，在前置元数据中添加或更新
    deepened: YYYY-MM-DD
禁止的操作：
  • 除非计划本身以代码形态作为设计工件，否则不得添加带围栏的实施代码块
  • 不得添加Git命令、提交编排或精确的测试命令方案
  • 不得在所有地方泛泛添加
    Research Insights
    子环节
  • 不得从头重写整个计划
  • 不得凭空提出新的产品需求、范围变更或成功标准，除非明确列出
若研究发现产品层面的歧义，可能改变行为或范围：
  • 不得在此处擅自决定
  • 将其记录在
    Open Questions
    下
  • 若缺口确实属于产品定义范畴，建议使用
    ce:brainstorm
    技能

Phase 6: Final Checks and Write the File

阶段6：最终检查并写入文件

Before writing:
  • Confirm the plan is stronger in specific ways, not merely longer
  • Confirm the planning boundary is intact
  • Confirm the selected sections were actually the weakest ones
  • Confirm origin decisions were preserved when an origin document exists
  • Confirm the final plan still feels right-sized for its depth
Update the plan file in place by default.
If the user explicitly requests a separate file, append 
-deepened
before 
.md
, for example:
  • docs/plans/2026-03-15-001-feat-example-plan-deepened.md
写入前：
  • 确认计划在特定方面得到强化，而非单纯变长
  • 确认规划边界未被突破
  • 确认选中的环节确实是最薄弱的环节
  • 若存在原始文档，确认原始决策未被改变
  • 确认最终计划的规模与其深度匹配
默认原地更新计划文件。
若用户明确要求生成单独文件，在
.md
前追加
-deepened
，例如：
  • docs/plans/2026-03-15-001-feat-example-plan-deepened.md

Post-Enhancement Options

深化后选项

If substantive changes were made, present next steps using the platform's blocking question tool when available (see Interaction Method). Otherwise, present numbered options in chat and wait for the user's reply before proceeding.
Question: "Plan deepened at 
[plan_path]
. What would you like to do next?"
Options:
  1. View diff - Show what changed
  2. Run 
    document-review
    skill     - Improve the updated plan through structured document review
  3. Start 
    ce:work
    skill     - Begin implementing the plan
  4. Deepen specific sections further - Run another targeted deepening pass on named sections
Based on selection:
  • View diff -> Show the important additions and changed sections
  • document-review
    skill     -> Load the 
    document-review
    skill with the plan path
  • Start 
    ce:work
    skill     -> Call the 
    ce:work
    skill with the plan path
  • Deepen specific sections further -> Ask which sections still feel weak and run another targeted pass only for those sections
If no substantive changes were warranted:
  • Say that the plan already appears sufficiently grounded
  • Offer the 
    document-review
    skill or 
    /ce:work
    as the next step instead
NEVER CODE! Research, challenge, and strengthen the plan.
若计划发生实质性变更，若平台支持阻塞式提问工具，请使用该工具提供下一步选项（参见交互方式）。否则，在聊天中列出带编号的选项，等待用户回复后再继续。
问题： "已在
[plan_path]
路径下完成计划深化。接下来您想进行什么操作？"
选项：
  1. 查看差异 - 显示变更内容
  2. 运行
    document-review
    技能     - 通过结构化文档审查优化更新后的计划
  3. 启动
    ce:work
    技能     - 开始实施计划
  4. 进一步深化特定环节 - 对指定环节再次进行针对性深化
根据选择执行：
  • 查看差异 -> 显示重要的新增和变更环节
  • document-review
    技能     -> 加载
    document-review
    技能并传入计划路径
  • 启动
    ce:work
    技能     -> 调用
    ce:work
    技能并传入计划路径
  • 进一步深化特定环节 -> 询问用户哪些环节仍需强化，仅对这些环节再次进行针对性深化
若无需进行实质性变更：
  • 告知用户计划已足够扎实
  • 建议使用
    document-review
    技能或
    /ce:work
    作为下一步操作
绝对禁止编写代码！仅进行研究、质疑和强化计划。