重要前提
安装AI Skills的关键前提是:必须科学上网,且开启TUN模式,这一点至关重要,直接决定安装能否顺利完成,在此郑重提醒三遍:科学上网,科学上网,科学上网。查看完整安装教程 →
deepen-plan by everyinc/compound-engineering-plugin
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill deepen-plan注意:当前年份是 2026 年。 在搜索最新文档和最佳实践时请使用此信息。
ce:plan 执行第一轮规划。deepen-plan 是第二轮信心检查。
当计划已存在,且问题不是"这份文档是否清晰?"而是"这个计划对于所涉及的复杂性和风险是否足够扎实?"时,请使用此技能。
此技能不会将计划转化为实现脚本。它会识别薄弱环节,仅针对这些环节进行定向研究,并在原处强化计划。
document-review 和 deepen-plan 是不同的:
document-review 技能deepen-plan优先使用平台的提问工具。当需要向用户提问时,如果平台有阻塞式提问工具(Claude Code 中的 AskUserQuestion,Codex 中的 ,Gemini 中的 ),则优先使用。否则,在聊天中呈现编号选项,并在继续之前等待用户的回复。
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
request_user_inputask_user一次只问一个问题。当存在自然的选项时,优先使用简洁的单选形式。
<plan_path> #$ARGUMENTS </plan_path>
如果上面的计划路径为空:
docs/plans/ 目录下的最近文件在获得有效的计划文件路径之前,请勿继续。
背景与研究、来源与参考 以及存在的原始文档开展工作。ce:brainstorm。完整阅读计划文件。
如果计划的前置元数据包含 origin: 路径:
根据文档确定计划深度:
同时构建风险概况。将以下情况视为高风险信号:
使用以下默认规则:
如果计划看起来已经足够扎实:
/ce:work 或 document-review 技能ce:plan 结构将计划映射到当前模板中。查找以下部分或其最接近的等价部分:
概述问题框架需求追溯范围边界背景与研究关键技术决策开放性问题高层技术设计(可选概述 - 伪代码、DSL 语法、mermaid 图或数据流)实现单元(可能包含每个单元的 技术设计 子部分)系统级影响风险与依赖文档 / 运维说明来源与参考已考虑的替代方案、成功指标、分阶段交付、风险分析与缓解 和 运维 / 发布说明如果计划是手动编写的或使用了不同的标题:
同时收集:
deepened: 日期(如果存在)使用清单优先、风险加权的评分方式。
对于每个部分,计算:
标准级 或 深度级 计划中的 关键技术决策、实现单元、系统级影响、风险与依赖 或 开放性问题,加 1将某个部分视为候选部分的条件是:
仅选择得分最高的 2-5 个部分。如果用户明确要求深化一个轻量级计划,则上限为 1-2 个部分,除非主题是高风险。
示例:
关键技术决策 部分,有 1 个清单触发项和关键部分加成,得分为 2 分,是候选部分风险与依赖 部分,在高风险迁移计划中有 1 个清单触发项,也成为候选部分,因为风险加成适用如果计划已有 deepened: 日期:
使用以下触发项。
需求追溯
背景与研究 / 来源与参考
关键技术决策
开放性问题
高层技术设计(当存在时)
高层技术设计(当缺失时)(仅限标准级或深度级计划)
实现单元
系统级影响
风险与依赖 / 文档 / 运维说明
使用计划自身的 背景与研究 和 来源与参考 作为证据。如果这些部分引用了某个模式、学习成果或风险,但从未影响决策、实现单元或验证,则将其视为信心差距。
对于每个选定的部分,选择最小有用的智能体集合。不要运行每个智能体。每个部分最多使用 1-3 个智能体,通常总共不超过 8 个智能体。
在 Task 调用中使用完全限定的智能体名称。
需求追溯 / 开放性问题分类
compound-engineering:workflow:spec-flow-analyzer 用于缺失的用户流程、边缘情况和交接差距compound-engineering:research:repo-research-analyst(范围:architecture, patterns)用于基于仓库的模式、惯例和实现现实检查背景与研究 / 来源与参考差距
compound-engineering:research:learnings-researcher 用于机构知识和过去已解决的问题compound-engineering:research:framework-docs-researcher 用于官方框架或库的行为compound-engineering:research:best-practices-researcher 用于当前的外部模式和行业指导compound-engineering:research:git-history-analyzer关键技术决策
compound-engineering:review:architecture-strategist 用于设计完整性、边界和架构权衡compound-engineering:research:framework-docs-researcher 或 compound-engineering:research:best-practices-researcher高层技术设计
compound-engineering:review:architecture-strategist 用于验证技术设计是否准确代表了预期方法并识别差距compound-engineering:research:repo-research-analyst(范围:architecture, patterns)用于将技术设计建立在现有仓库模式和惯例的基础上compound-engineering:research:best-practices-researcher实现单元 / 验证
compound-engineering:research:repo-research-analyst(范围:patterns)用于具体的文件目标、要遵循的模式和仓库特定的排序线索compound-engineering:review:pattern-recognition-specialist 用于一致性、重复风险和与现有模式的对齐compound-engineering:workflow:spec-flow-analyzer系统级影响
compound-engineering:review:architecture-strategist 用于跨边界效应、接口表面和架构连锁影响compound-engineering:review:performance-oracle 用于可扩展性、延迟、吞吐量和资源风险分析compound-engineering:review:security-sentinel 用于身份验证、验证、攻击表面和安全边界审查compound-engineering:review:data-integrity-guardian 用于迁移、持久状态安全、一致性和数据生命周期风险风险与依赖 / 运维说明
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 用于容量、延迟和扩展问题对于每个选定的部分,传递:
Scope: architecture, patterns.),当智能体支持范围调用时指示智能体返回:
使用最轻量的可行模式:
证明基于工件模式合理性的信号:
如果基于工件的模式没有明确理由,则保持在直接模式。
使用第 3.3 步中选择的执行模式并行启动选定的智能体。如果当前平台不支持并行调度,则改为顺序运行它们。
优先使用本地仓库和机构证据。仅当差距无法从仓库背景或已引用的来源中负责任地弥补时,才使用外部研究。
如果选定的部分可以通过更仔细地阅读原始文档来改进,请在调度外部智能体之前进行。
让每个选定的智能体将其发现直接返回给父智能体。
保持返回内容集中:
如果直接模式的智能体开始产生庞大或重复的输出,请停止并将剩余的研究切换到基于工件的模式,而不是让父上下文膨胀。
在 .context/compound-engineering/deepen-plan/ 下使用每次运行的暂存目录,例如 .context/compound-engineering/deepen-plan/<run-id>/ 或 .context/compound-engineering/deepen-plan/<plan-filename-stem>/。
暂存目录仅用于当前的深化轮次。
对于每个选定的智能体:
除非明确需要机器可读的结构,否则优先使用紧凑的 markdown 工件。每个工件应包含:
工件规则:
在合成之前:
如果智能体输出冲突:
仅强化选定的部分。保持计划的连贯性并保留其整体结构。
如果使用了基于工件的模式:
允许的更改:
规划期间已解决 和 推迟到实现 之间重新分类开放性问题deepened: YYYY-MM-DD不要:
研究见解 子部分如果研究揭示了应改变行为或范围的产品层面模糊性:
开放性问题 下ce:brainstorm写入前:
默认情况下,就地更新计划文件。
如果用户明确要求单独的文件,请在 .md 前追加 -deepened,例如:
docs/plans/2026-03-15-001-feat-example-plan-deepened.md如果使用了基于工件的模式且用户未要求检查暂存文件:
如果进行了实质性更改,请使用平台的阻塞式提问工具(参见交互方式)呈现后续步骤。否则,在聊天中呈现编号选项,并在继续之前等待用户的回复。
问题: "计划已在 [plan_path] 深化。接下来您想做什么?"
选项:
document-review 技能 - 通过结构化文档审查改进更新后的计划ce:work 技能 - 开始实施计划根据选择:
document-review 技能 -> 加载带有计划路径的 document-review 技能ce:work 技能 -> 使用计划路径调用 ce:work 技能如果不需要进行实质性更改:
document-review 技能或 /ce:work 作为下一步切勿编写代码!进行研究、提出质疑并强化计划。
每周安装量
64
仓库
GitHub 星标数
11.0K
首次出现
13 天前
安全审计
安装于
codex64
cursor64
opencode63
gemini-cli63
amp63
cline63
Note: The current year is 2026. Use this when searching for recent documentation and best practices.
ce:plan does the first planning pass. deepen-plan 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 are different:
document-review skill when the document needs clarity, simplification, completeness, or scope controldeepen-plan when the document is structurally sound but still needs stronger rationale, sequencing, risk treatment, or system-wide thinkingUse 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.
<plan_path> #$ARGUMENTS </plan_path>
If the plan path above is empty:
docs/plans/ for recent filesDo not proceed until you have a valid plan file path.
Context & Research, Sources & References, and its origin document when present.ce:brainstorm.Read the plan file completely.
If the plan frontmatter includes an origin: path:
Determine the plan depth from the document:
Also build a risk profile. Treat these as high-risk signals:
Use this default:
If the plan already appears sufficiently grounded:
/ce:work or the document-review skillce:plan StructureMap the plan into the current template. Look for these sections, or their nearest equivalents:
OverviewProblem FrameRequirements TraceScope BoundariesContext & ResearchKey Technical DecisionsOpen QuestionsHigh-Level Technical Design (optional overview — pseudo-code, DSL grammar, mermaid diagram, or data flow)Implementation Units (may include per-unit Technical design subsections)If the plan was written manually or uses different headings:
Also collect:
deepened: date if presentUse a checklist-first, risk-weighted scoring pass.
For each section, compute:
Key Technical Decisions, Implementation Units, System-Wide Impact, Risks & Dependencies, or Open Questions in Standard or Deep plansTreat a section as a candidate if:
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:
Key Technical Decisions section with 1 checklist trigger and the critical-section bonus scores 2 points and is a candidateRisks & Dependencies section with 1 checklist trigger in a high-risk migration plan also becomes a candidate because the risk bonus appliesIf the plan already has a deepened: date:
Use these triggers.
Requirements Trace
Context & Research / Sources & References
Key Technical Decisions
Open Questions
High-Level Technical Design (when present)
High-Level Technical Design (when absent) (Standard or Deep plans only)
Implementation Units
System-Wide Impact
Risks & Dependencies / Documentation / Operational Notes
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.
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.
Requirements Trace / Open Questions classification
compound-engineering:workflow:spec-flow-analyzer for missing user flows, edge cases, and handoff gapscompound-engineering:research:repo-research-analyst (Scope: architecture, patterns) for repo-grounded patterns, conventions, and implementation reality checksContext & Research / Sources & References gaps
compound-engineering:research:learnings-researcher for institutional knowledge and past solved problemscompound-engineering:research:framework-docs-researcher for official framework or library behaviorcompound-engineering:research:best-practices-researcher for current external patterns and industry guidancecompound-engineering:research:git-history-analyzer only when historical rationale or prior art is materially missingKey Technical Decisions
compound-engineering:review:architecture-strategist for design integrity, boundaries, and architectural tradeoffscompound-engineering:research:framework-docs-researcher or compound-engineering:research:best-practices-researcher when the decision needs external grounding beyond repo evidenceHigh-Level Technical Design
compound-engineering:review:architecture-strategist for validating that the technical design accurately represents the intended approach and identifying gapscompound-engineering:research:repo-research-analyst (Scope: architecture, patterns) for grounding the technical design in existing repo patterns and conventionscompound-engineering:research:best-practices-researcher when the technical design involves a DSL, API surface, or pattern that benefits from external validationImplementation Units / Verification
compound-engineering:research:repo-research-analyst (Scope: patterns) for concrete file targets, patterns to follow, and repo-specific sequencing cluescompound-engineering:review:pattern-recognition-specialist for consistency, duplication risks, and alignment with existing patternscompound-engineering:workflow:spec-flow-analyzer when sequencing depends on user flow or handoff completenessSystem-Wide Impact
compound-engineering:review:architecture-strategist for cross-boundary effects, interface surfaces, and architectural knock-on impactcompound-engineering:review:performance-oracle for scalability, latency, throughput, and resource-risk analysiscompound-engineering:review:security-sentinel for auth, validation, exploit surfaces, and security boundary reviewcompound-engineering:review:data-integrity-guardian for migrations, persistent state safety, consistency, and data lifecycle risksRisks & Dependencies / Operational Notes
compound-engineering:review:security-sentinel for security, auth, privacy, and exploit riskcompound-engineering:review:data-integrity-guardian for persistent data safety, constraints, and transaction boundariescompound-engineering:review:data-migration-expert for migration realism, backfills, and production data transformation riskcompound-engineering:review:deployment-verification-agent for rollout checklists, rollback planning, and launch verificationcompound-engineering:review:performance-oracle for capacity, latency, and scaling concernsFor each selected section, pass:
Scope: architecture, patterns.) when the agent supports scoped invocationInstruct the agent to return:
Use the lightest mode that will work:
Signals that justify artifact-backed mode:
If artifact-backed mode is not clearly warranted, stay in direct mode.
Launch the selected agents in parallel using the execution mode chosen in Step 3.3. If the current platform does not support parallel dispatch, run them sequentially instead.
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.
Have each selected agent return its findings directly to the parent.
Keep the return payload focused:
If a direct-mode agent starts producing bulky or repetitive output, stop and switch the remaining research to artifact-backed mode instead of letting the parent context bloat.
Use a per-run scratch directory under .context/compound-engineering/deepen-plan/, for example .context/compound-engineering/deepen-plan/<run-id>/ or .context/compound-engineering/deepen-plan/<plan-filename-stem>/.
Use the scratch directory only for the current deepening pass.
For each selected agent:
Prefer a compact markdown artifact unless machine-readable structure is clearly useful. Each artifact should contain:
Artifact rules:
Before synthesis:
If agent outputs conflict:
Strengthen only the selected sections. Keep the plan coherent and preserve its overall structure.
If artifact-backed mode was used:
Allowed changes:
Resolved During Planning and Deferred to Implementation when evidence supports the changedeepened: YYYY-MM-DD in frontmatter when the plan was substantively improvedDo not :
Research Insights subsections everywhereIf research reveals a product-level ambiguity that should change behavior or scope:
Open Questionsce:brainstorm if the gap is truly product-definingBefore writing:
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.mdIf artifact-backed mode was used and the user did not ask to inspect the scratch files:
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:
document-review skill - Improve the updated plan through structured document reviewce:work skill - Begin implementing the planBased on selection:
document-review skill -> Load the document-review skill with the plan pathce:work skill -> Call the ce:work skill with the plan pathIf no substantive changes were warranted:
document-review skill or /ce:work as the next step insteadNEVER CODE! Research, challenge, and strengthen the plan.
Weekly Installs
64
Repository
GitHub Stars
11.0K
First Seen
13 days ago
Security Audits
Gen Agent Trust HubWarnSocketWarnSnykFail
Installed on
codex64
cursor64
opencode63
gemini-cli63
amp63
cline63
站立会议模板:敏捷开发每日站会指南与工具(含远程团队异步模板)
10,500 周安装
System-Wide ImpactRisks & DependenciesDocumentation / Operational NotesSources & ReferencesAlternative Approaches Considered, Success Metrics, Phased Delivery, Risk Analysis & Mitigation, and Operational / Rollout Notes