ce%3Aplan by everyinc/compound-engineering-plugin
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce:plan注意:当前年份是 2026 年。 在制定方案日期和搜索最新文档时请使用此年份。
ce:brainstorm 定义了要构建什么。ce:plan 定义了如何构建它。ce:work 执行该方案。
此工作流产生一个持久的实施方案。它不实现代码、运行测试或从执行时结果中学习。如果答案取决于修改代码并观察发生的情况,那属于 ce:work 的范畴,而不是这里。
在可用时使用平台的提问工具。当向用户提问时,如果存在平台的阻塞式提问工具(Claude Code 中的 AskUserQuestion,Codex 中的 request_user_input,Gemini 中的 ask_user),请优先使用。否则,在聊天中呈现编号选项,并在继续之前等待用户的回复。
一次只问一个问题。当存在自然选项时,倾向于简洁的单选。
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
<feature_description> #$ARGUMENTS </feature_description>
如果上面的功能描述为空,请询问用户: "您想规划什么?请描述您考虑的功能、错误修复或改进。"
在获得清晰的规划输入之前,请勿继续。
ce:brainstorm 生成了需求文档,规划应基于它进行,而不是重新发明行为。每个方案应包含:
当实施者可以自信地开始工作,而无需方案为他们编写代码时,方案就准备好了。
如果用户引用了现有方案文件,或者在 docs/plans/ 中存在明显最近匹配的方案:
在询问规划问题之前,搜索 docs/brainstorms/ 中匹配 *-requirements.md 的文件。
相关性标准: 需求文档在以下情况下是相关的:
如果多个源文档匹配,请在可用时使用平台的阻塞式提问工具询问使用哪一个(参见交互方式)。否则,在聊天中呈现编号选项,并在继续之前等待用户的回复。
如果存在相关的需求文档:
(参见来源: <源路径>)如果没有相关的需求文档存在,规划可以直接从用户的请求开始进行。
如果没有相关的需求文档存在:
ce:brainstorm规划引导应建立:
保持此引导简短。它的存在是为了保留直接进入的便利性,而不是取代完整的头脑风暴。
如果引导发现了重大的未解决产品问题:
ce:brainstorm如果原始文档包含 Resolve Before Planning 或类似的阻塞性问题:
如果存在真正的产品阻塞项:
ce:brainstorm 来解决它们将工作分类为以下方案深度之一:
如果深度不明确,请提出一个有针对性的问题,然后继续。
准备一个简洁的规划上下文摘要(一两段),作为输入传递给研究代理:
并行运行这些代理:
收集:
docs/solutions/ 的机构经验教训决定方案是否应携带轻量级的执行姿态信号。
寻找诸如以下的信号:
Execution target: external-delegate当信号清晰时,在相关的实现单元中静默地延续它。
仅当姿态会实质性改变顺序或风险,并且无法负责任地推断时,才询问用户。
根据原始文档、用户信号和本地发现,决定外部研究是否增加价值。
解读言外之意。 注意迄今为止对话中的信号:
利用 repo-research-analyst 的技术上下文:
repo-research-analyst 的输出包含结构化的技术与基础设施摘要。使用它来做出更精确的外部研究决策:
在以下情况下始终倾向于进行外部研究:
在以下情况下跳过外部研究:
在继续之前简要宣布决定。例如:
如果步骤 1.2 表明外部研究有用,则并行运行这些代理:
总结:
对于标准或深度方案,或者当用户流程完整性仍不明确时,运行:
使用输出以:
从以下来源构建规划问题列表:
对于每个问题,决定它应该:
仅当答案实质性影响架构、范围、顺序或风险,并且无法负责任地推断时,才询问用户。在可用时使用平台的阻塞式提问工具(参见交互方式)。
不要在此阶段运行测试、构建应用程序或探测运行时行为。目标是制定一个强大的方案,而不是部分执行。
feat: Add user authentication 或 fix: Prevent checkout double-submit)起草清晰、可搜索的标题feat、fix 或 refactordocs/plans/YYYY-MM-DD-NNN-<type>-<descriptive-name>-plan.md
docs/plans/2026-01-15-001-feat-user-authentication-flow-plan.md、2026-02-03-002-fix-checkout-race-condition-plan.md对于标准或深度方案,简要考虑谁受此更改影响——最终用户、开发人员、运维人员、其他团队——以及这应如何影响方案。对于跨领域工作,请在"系统范围影响"部分注明受影响方。
将工作分解为逻辑实施单元。每个单元应代表一个有意义的更改,实施者通常可以将其作为一个原子提交落地。
好的单元是:
避免:
在详细说明实施单元之前,决定概述是否有助于评审者验证预期方法。本节传达解决方案的形态——各部分如何组合在一起——而不规定实现。
何时包含它:
| 涉及的工作... | 最佳概述形式 |
|---|---|
| DSL 或 API 表面设计 | 伪代码语法或契约草图 |
| 多组件集成 | Mermaid 序列图或组件图 |
| 数据管道或转换 | 数据流草图 |
| 状态密集的生命周期 | 状态图 |
| 复杂分支逻辑 | 流程图 |
| 具有非明显形态的单一组件 | 伪代码草图 |
何时跳过它:
选择适合工作的媒介。当图表能更好地传达信息时,不要默认使用伪代码,反之亦然。
用以下内容框定每个草图:"这说明了预期的方法,是用于评审的方向性指导,而非实现规范。实施代理应将其视为上下文,而不是要复制的代码。"
保持草图简洁——足以验证方向,而不是足以复制粘贴到生产环境中。
对于每个单元,包括:
每个承载功能的单元都应在 **文件:** 中包含测试文件路径。
谨慎使用 执行说明。好的用法包括:
执行说明:从请求/响应契约的失败集成测试开始。执行说明:在修改此遗留解析器之前添加特征化覆盖。执行说明:以测试优先的方式实现新的领域行为。执行说明:执行目标:外部委托不要将单元扩展为字面上的 RED/GREEN/REFACTOR 子步骤。
如果某些事情很重要但目前尚不可知,请明确记录在推迟的实施说明下,而不是假装在方案中解决它。
示例:
在所有深度中使用一种规划理念。改变细节的数量,而不是规划与执行之间的边界。
轻量级
标准
深度
对于足够大、高风险或跨领域的工作,添加真正有帮助的部分:
不要将这些作为样板添加。仅当它们提高执行质量或利益相关者一致性时才包括它们。
省略明显不适用的可选部分,特别是对于轻量级方案。
---
title: [方案标题]
type: [feat|fix|refactor]
status: active
date: YYYY-MM-DD
origin: docs/brainstorms/YYYY-MM-DD-<topic>-requirements.md # 当根据需求文档规划时包含
deepened: YYYY-MM-DD # 可选,稍后由 deepen-plan 在方案得到实质性加强时设置
---
# [方案标题]
## 概述
[什么在改变以及为什么]
## 问题框架
[总结用户/业务问题和上下文。存在时引用原始文档。]
## 需求追溯
- R1. [此方案必须满足的需求或成功标准]
- R2. [此方案必须满足的需求或成功标准]
## 范围边界
- [明确的非目标或排除项]
## 上下文与研究
### 相关代码与模式
- [要遵循的现有文件、类、组件或模式]
### 机构经验教训
- [相关的 `docs/solutions/` 见解]
### 外部参考资料
- [相关的外部文档或最佳实践来源,如果使用了]
## 关键技术决策
- [决策]: [理由]
## 开放性问题
### 在规划期间解决
- [问题]: [解决方案]
### 推迟到实施阶段
- [问题或未知项]: [为何有意推迟]
<!-- 可选:仅当工作涉及 DSL 设计、多组件集成、复杂数据流、状态密集的生命周期或其他仅用散文会使方法形态模糊的情况时,才包含此部分。对于模式化良好或直接的工作,请完全省略它。 -->
## 高层技术设计
> *这说明了预期的方法,是用于评审的方向性指导,而非实现规范。实施代理应将其视为上下文,而不是要复制的代码。*
[伪代码语法、mermaid 图表、数据流草图或状态图——选择最适合传达此工作解决方案形态的媒介。]
## 实施单元
- [ ] **单元 1: [名称]**
**目标:** [此单元实现什么]
**需求:** [R1, R2]
**依赖项:** [无 / 单元 1 / 外部先决条件]
**文件:**
- 创建: `path/to/new_file`
- 修改: `path/to/existing_file`
- 测试: `path/to/test_file`
**方法:**
- [关键设计或顺序决策]
**执行说明:** [可选的测试优先、特征化优先、外部委托或其他执行姿态信号]
**技术设计:** *(可选——当单元的方法非显而易见时使用伪代码或图表。方向性指导,而非实现规范。)*
**要遵循的模式:**
- [现有文件、类或模式]
**测试场景:**
- [具有预期行为的具体场景]
- [边缘情况或失败路径]
**验证:**
- [当此单元完成时应保持的结果]
## 系统范围影响
- **交互图:** [可能受影响的回调、中间件、观察者或入口点]
- **错误传播:** [故障应如何在各层之间传播]
- **状态生命周期风险:** [部分写入、缓存、重复或清理问题]
- **API 表面一致性:** [可能需要相同更改的其他接口]
- **集成覆盖:** [单元测试单独无法证明的跨层场景]
## 风险与依赖项
- [有意义的风险、依赖项或顺序问题]
## 文档 / 运维说明
- [文档、上线、监控或支持影响,当相关时]
## 来源与参考资料
- **原始文档:** [docs/brainstorms/YYYY-MM-DD-<topic>-requirements.md](path)
- 相关代码: [路径或符号]
- 相关 PRs/问题: #[编号]
- 外部文档: [url]
对于较大的深度方案,仅在有用时使用以下部分扩展核心模板:
## 考虑的替代方法
- [方法]: [为何被拒绝或未被选择]
## 成功指标
- [我们将如何知道这解决了预期问题]
## 依赖项 / 先决条件
- [技术、组织或上线依赖项]
## 风险分析与缓解
- [风险]: [缓解措施]
## 分阶段交付
### 阶段 1
- [首先落地什么以及为什么]
### 阶段 2
- [接下来是什么以及为什么]
## 文档计划
- [要更新的文档或操作手册]
## 运维 / 上线说明
- [监控、迁移、功能标志或上线考虑事项]
- [ ] 语法进行勾选以跟踪进度RED/GREEN/REFACTOR 指令在最终确定之前,检查:
ce:brainstorm 中定义的产品行为执行说明 延续了它如果方案源自需求文档,请重新阅读该文档并验证:
ce:brainstorm必需:在呈现任何选项之前将方案文件写入磁盘。
使用 Write 工具将完整方案保存到:
docs/plans/YYYY-MM-DD-NNN-<type>-<descriptive-name>-plan.md
确认:
方案已写入 docs/plans/[文件名]
流水线模式: 如果从自动化工作流(如 LFG、SLFG 或任何 disable-model-invocation 上下文)调用,跳过交互式问题。自动做出所需的选择并继续写入方案。
写入方案文件后,在可用时使用平台的阻塞式提问工具呈现选项(参见交互方式)。否则,在聊天中呈现编号选项,并在继续之前等待用户的回复。
问题: "方案已准备就绪,位于 docs/plans/YYYY-MM-DD-NNN-<type>-<name>-plan.md。您接下来想做什么?"
选项:
/deepen-plan - 当方案需要更多信心时,通过针对性研究对薄弱部分进行压力测试document-review 技能 - 通过结构化文档评审改进方案/ce:work - 在当前环境中开始实施此方案/ce:work - 当当前平台支持时,在单独的代理会话中开始实施根据选择:
在编辑器中打开方案 → 使用当前平台的文件打开或编辑器机制(例如,macOS 上的 open,Linux 上的 xdg-open,或 IDE 的文件打开 API)打开 docs/plans/<plan_filename>.md
/deepen-plan → 使用方案路径调用 /deepen-plan
document-review 技能 → 使用方案路径加载 document-review 技能
分享到 Proof → 上传方案:
CONTENT=$(cat docs/plans/<plan_filename>.md)
TITLE="方案: <来自 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')
如果成功,显示 在 Proof 中查看与协作: <PROOF_URL>,然后返回到选项
/ce:work → 使用方案路径调用 /ce:work/ce:work → 如果当前平台支持启动单独的代理会话,则在那里使用方案路径启动 /ce:work。否则,简要解释限制,并提议在当前会话中运行 /ce:work。如果启用了 ultrathink,或者平台的推理/努力级别设置为最大或额外高,则仅在方案是标准或深度、高风险,或者在决策、顺序、系统范围影响、风险或验证方面仍显示出有意义的信心差距时,自动运行 /deepen-plan。
当用户选择"创建问题"时,从 AGENTS.md 或(如果需要兼容性)CLAUDE.md 检测他们的项目跟踪器:
查找 project_tracker: github 或 project_tracker: linear
如果是 GitHub:
gh issue create --title "<type>: <title>" --body-file <plan_path>
如果是 Linear:
linear issue create --title "<title>" --description "$(cat <plan_path>)"
如果未配置跟踪器:
AGENTS.md问题创建后:
/ce:work切勿编写代码!进行研究、做出决策并编写方案。
每周安装次数
71
仓库
GitHub 星标数
11.0K
首次出现
13 天前
安装在
codex71
amp70
gemini-cli70
kimi-cli70
cursor70
opencode70
Note: The current year is 2026. Use this when dating plans and searching for recent documentation.
ce:brainstorm defines WHAT to build. ce:plan defines HOW to build it. ce:work executes the plan.
This workflow produces a durable implementation plan. It does not implement code, run tests, or learn from execution-time results. If the answer depends on changing code and seeing what happens, that belongs in ce:work, not here.
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.
<feature_description> #$ARGUMENTS </feature_description>
If the feature description above is empty, ask the user: "What would you like to plan? Please describe the feature, bug fix, or improvement you have in mind."
Do not proceed until you have a clear planning input.
ce:brainstorm produced a requirements document, planning should build from it rather than re-inventing behavior.Every plan should contain:
A plan is ready when an implementer can start confidently without needing the plan to write the code for them.
If the user references an existing plan file or there is an obvious recent matching plan in docs/plans/:
Before asking planning questions, search docs/brainstorms/ for files matching *-requirements.md.
Relevance criteria: A requirements document is relevant if:
If multiple source documents match, ask which one to use 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.
If a relevant requirements document exists:
(see origin: <source-path>)If no relevant requirements document exists, planning may proceed from the user's request directly.
If no relevant requirements document exists:
ce:brainstorm firstThe planning bootstrap should establish:
Keep this bootstrap brief. It exists to preserve direct-entry convenience, not to replace a full brainstorm.
If the bootstrap uncovers major unresolved product questions:
ce:brainstorm againIf the origin document contains Resolve Before Planning or similar blocking questions:
If true product blockers remain:
ce:brainstorm to resolve themClassify the work into one of these plan depths:
If depth is unclear, ask one targeted question and then continue.
Prepare a concise planning context summary (a paragraph or two) to pass as input to the research agents:
Run these agents in parallel:
Collect:
docs/solutions/Decide whether the plan should carry a lightweight execution posture signal.
Look for signals such as:
Execution target: external-delegate to implementation units that are pure code writingWhen the signal is clear, carry it forward silently in the relevant implementation units.
Ask the user only if the posture would materially change sequencing or risk and cannot be responsibly inferred.
Based on the origin document, user signals, and local findings, decide whether external research adds value.
Read between the lines. Pay attention to signals from the conversation so far:
Leverage repo-research-analyst's technology context:
The repo-research-analyst output includes a structured Technology & Infrastructure summary. Use it to make sharper external research decisions:
Always lean toward external research when:
Skip external research when:
Announce the decision briefly before continuing. Examples:
If Step 1.2 indicates external research is useful, run these agents in parallel:
Summarize:
For Standard or Deep plans, or when user flow completeness is still unclear, run:
Use the output to:
Build a planning question list from:
For each question, decide whether it should be:
Ask the user only when the answer materially affects architecture, scope, sequencing, or risk and cannot be responsibly inferred. Use the platform's blocking question tool when available (see Interaction Method).
Do not run tests, build the app, or probe runtime behavior in this phase. The goal is a strong plan, not partial execution.
feat: Add user authentication or fix: Prevent checkout double-submitfeat, fix, or refactordocs/plans/YYYY-MM-DD-NNN-<type>-<descriptive-name>-plan.md
docs/plans/ if it does not exist2026-01-15-001-feat-user-authentication-flow-plan.md, For Standard or Deep plans, briefly consider who is affected by this change — end users, developers, operations, other teams — and how that should shape the plan. For cross-cutting work, note affected parties in the System-Wide Impact section.
Break the work into logical implementation units. Each unit should represent one meaningful change that an implementer could typically land as an atomic commit.
Good units are:
Avoid:
Before detailing implementation units, decide whether an overview would help a reviewer validate the intended approach. This section communicates the shape of the solution — how pieces fit together — without dictating implementation.
When to include it:
| Work involves... | Best overview form |
|---|---|
| DSL or API surface design | Pseudo-code grammar or contract sketch |
| Multi-component integration | Mermaid sequence or component diagram |
| Data pipeline or transformation | Data flow sketch |
| State-heavy lifecycle | State diagram |
| Complex branching logic | Flowchart |
| Single-component with non-obvious shape | Pseudo-code sketch |
When to skip it:
Choose the medium that fits the work. Do not default to pseudo-code when a diagram communicates better, and vice versa.
Frame every sketch with: "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."
Keep sketches concise — enough to validate direction, not enough to copy-paste into production.
For each unit, include:
Every feature-bearing unit should include the test file path in **Files:**.
Use Execution note sparingly. Good uses include:
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-delegateDo not expand units into literal RED/GREEN/REFACTOR substeps.
If something is important but not knowable yet, record it explicitly under deferred implementation notes rather than pretending to resolve it in the plan.
Examples:
Use one planning philosophy across all depths. Change the amount of detail, not the boundary between planning and execution.
Lightweight
Standard
Deep
For sufficiently large, risky, or cross-cutting work, add the sections that genuinely help:
Do not add these as boilerplate. Include them only when they improve execution quality or stakeholder alignment.
Omit clearly inapplicable optional sections, especially for Lightweight plans.
---
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 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]
<!-- Optional: Include this section only when the work involves DSL design, multi-component
integration, complex data flow, state-heavy lifecycle, or other cases where prose alone
would leave the approach shape ambiguous. Omit it entirely for well-patterned or
straightforward work. -->
## 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]
For larger Deep plans, extend the core template only when useful with sections such as:
## 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]
- [ ] syntax for progress trackingRED/GREEN/REFACTOR instructionsBefore finalizing, check:
ce:brainstormExecution noteIf the plan originated from a requirements document, re-read that document and verify:
ce:brainstormREQUIRED: Write the plan file to disk before presenting any options.
Use the Write tool to save the complete plan to:
docs/plans/YYYY-MM-DD-NNN-<type>-<descriptive-name>-plan.md
Confirm:
Plan written to docs/plans/[filename]
Pipeline mode: If invoked from an automated workflow such as LFG, SLFG, or any disable-model-invocation context, skip interactive questions. Make the needed choices automatically and proceed to writing the plan.
After writing the plan file, present the options 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 ready at docs/plans/YYYY-MM-DD-NNN-<type>-<name>-plan.md. What would you like to do next?"
Options:
/deepen-plan - Stress-test weak sections with targeted research when the plan needs more confidencedocument-review skill - Improve the plan through structured document review/ce:work - Begin implementing this plan in the current environment/ce:work in another session - Begin implementing in a separate agent session when the current platform supports itBased on selection:
Open plan in editor → Open docs/plans/<plan_filename>.md using the current platform's file-open or editor mechanism (e.g., open on macOS, xdg-open on Linux, or the IDE's file-open API)
/deepen-plan → Call /deepen-plan with the plan path
document-review skill → Load the document-review skill with the plan path
Share to Proof → Upload the plan:
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')
Display View & collaborate in Proof: <PROOF_URL> if successful, then return to the options
/ce:work → Call /ce:work with the plan path/ce:work in another session → If the current platform supports launching a separate agent session, start /ce:work with the plan path there. Otherwise, explain the limitation briefly and offer to run /ce:work in the current session instead.If running with ultrathink enabled, or the platform's reasoning/effort level is set to max or extra-high, automatically run /deepen-plan only when the plan is Standard or Deep, high-risk, or still shows meaningful confidence gaps in decisions, sequencing, system-wide impact, risks, or verification.
When the user selects "Create Issue", detect their project tracker from AGENTS.md or, if needed for compatibility, CLAUDE.md:
Look for project_tracker: github or project_tracker: linear
If GitHub:
gh issue create --title "<type>: <title>" --body-file <plan_path>
If Linear:
linear issue create --title "<title>" --description "$(cat <plan_path>)"
If no tracker is configured:
AGENTS.md for future runsAfter issue creation:
/ce:workNEVER CODE! Research, decide, and write the plan.
Weekly Installs
71
Repository
GitHub Stars
11.0K
First Seen
13 days ago
Installed on
codex71
amp70
gemini-cli70
kimi-cli70
cursor70
opencode70
站立会议模板:敏捷开发每日站会指南与工具(含远程团队异步模板)
10,500 周安装
2026-02-03-002-fix-checkout-race-condition-plan.md