Ce:work

Work Execution Command

Execute work efficiently while maintaining quality and finishing features.

Introduction

This command takes a work document (plan, specification, or todo file) or a bare prompt describing the work, and executes it systematically. The focus is on shipping complete features by understanding requirements quickly, following existing patterns, and maintaining quality throughout.

Input Document

#$ARGUMENTS

Execution Workflow

Phase -1: 参数检测与模式初始化

检测所有可选标志并 strip from arguments before passing to Phase 0。

[R] 历史检索标志检测（最先执行，防止污染路径解析）：

• 如果 $ARGUMENTS 包含 [R] 或 [r]：
• 设置 RMODEENABLED = true
• 从参数中移除 [R]
• 否则：RMODEENABLED = false

> 向后兼容（参数别名）：以下旧参数名在传入时自动识别并映射： > - [team] → 等同 [T] > - [team:full] → 等同 [T+] > - [PW] → 等同 [V+] > 传入旧名不会报错，等同传入新名。 > > [T] 现在固定表示 Agent Teams；四层自验证使用 [V]。不要再把 [T] 当作旧自验证别名。

[V] 自验证标志检测（独立执行）：

• 如果 $ARGUMENTS 包含 [V] 或 [v]：
• 设置 VMODEENABLED = true
• 从参数中移除 [V]
• 宣告：「✅ [V] 自验证模式已启用——执行完成后将运行四层验证（Phase 3.5）」
• [V+] 检测（[V+] 自动启用四层验证，无需单独传 [V]）：
• 如果 $ARGUMENTS 包含 [V+] 或 [pw]：
• 检查 Playwright MCP 工具可用性（mcp__playwright__browser_navigate 是否在工具列表中）
• 若可用：设置 VPLUSMODE_ENABLED = true，从参数中移除 [V+]，宣告：「✅ [V+] Playwright MCP 模式已启用——Layer 2 将使用 Playwright MCP（高精度浏览器验证）」
• 若不可用：VPLUSMODE_ENABLED = false，输出：「⚠️ Playwright MCP Server 未配置，[V+] 模式不可用，Layer 2 自动降级为 agent-browser。如需 Playwright MCP，请先安装并配置 Playwright MCP Server。」
• 否则：VPLUSMODE_ENABLED = false（Layer 2 使用 agent-browser，token 低 30-50 倍）
• 否则：VMODEENABLED = false
• 如果 $ARGUMENTS 包含 [V+] 或 [pw]（向后兼容旧 [PW]）：
• 自动升级：设置 VMODEENABLED = true（[V+] 隐含 [V]，无需单独传 [V]）
• 按上方 [V+] 检测逻辑继续执行（检查 Playwright MCP 可用性）
• VPLUSMODE_ENABLED = false（默认）

[C] Codex 标志检测：

• 如果 $ARGUMENTS 包含 [C] 或 [c]：
• 设置 CODEX_ENABLED = true
• 从参数中移除 [C]
• 宣告：「✅ [C] 标志已检测——标记外部 AI（Codex）已参与整体工作流。注：[C] 不透传给内嵌 ce:review（透传无收益，详见 Phase 3）」
• 否则：CODEX_ENABLED = false

[G] Gemini 标志检测：

• 如果 $ARGUMENTS 包含 [G] 或 [g]：
• 设置 GEMINI_ENABLED = true
• 从参数中移除 [G]
• 宣告：「✅ [G] 标志已检测——标记外部 AI（Gemini）已参与整体工作流。注：[G] 不透传给内嵌 ce:review（透传无收益，详见 Phase 3）」
• 否则：GEMINI_ENABLED = false

[T] / [T+] 检测（仅当包含时）： Strip the team token from arguments before passing to Phase 0. Load the team-mode skill for the complete initialization sequence:

• TeamCreate（命名团队）
• .team-contract.md 加载与版本检测
• Spawn verifier teammate（独立 context window，只读，接收 SendMessage 通知并验证）
• [T+] 额外 spawn risk-guard teammate（高风险路径拦截）
• 宣告团队就绪
• Phase 2 每 Unit 完成后：SendMessage("verifier", ...) → 等待 PASS/FAIL → 修复或继续
• 全部 Unit 完成后：SendMessage("verifier", "全量集成验证") → 最终 PASS
• Phase 4 完成后：TeamDelete

---

Phase -1.5: 环境指纹（Environment Fingerprint）

触发条件：VMODEENABLED = true（由 [V] 或 [V+] 激活）。否则跳过本阶段。

目标：在进入执行流程前，自动确定两个命令：

• START_COMMAND：应用启动命令，确保 Layer 2/4 验证时可以启动应用
• TEST_COMMAND：项目测试命令，确保 Layer 0/2 可以自动跑测试

两个命令独立推导、独立存储，对非开发者用户完全零记忆负担。

---

决策树（按优先级顺序执行，找到即停止）

Level 1：读取 CLAUDE.md 显式覆盖（最高优先级）

搜索当前项目的 CLAUDE.md，寻找 ce-work 启动命令标记：

• 若找到：
• 读取 source 字段：
• source: user-provided：用户明确指定的覆盖，无条件使用。设置 START_COMMAND = ，宣告 ✅ 已读取 CLAUDE.md 用户覆盖命令，跳转 Level 4
• source: auto-detected（或字段不存在）：需跨会话漂移校验。重新执行 Level 2 推导（新鲜读取 package.json）：
• 若 Level 2 推导结果 = 已存储命令 → 无漂移，设置 START_COMMAND = ，跳转 Level 4
• 若 Level 2 推导结果 ≠ 已存储命令（或 Level 2 无法推导）→ 宣告 ⚠️ 检测到启动命令可能已过期，清除旧记录，继续 Level 2（会触发重写 CLAUDE.md）
• 若未找到：继续 Level 2

Level 2：从 package.json 动态推导（每次新鲜读取，禁止依赖缓存）

读取当前目录下的 package.json（若不存在则跳过此 Level）：

先检测包管理器（影响命令前缀）：

• packageManager 字段含 yarn → 使用 yarn 前缀（yarn dev）
• packageManager 字段含 pnpm → 使用 pnpm run 前缀
• 目录下存在 pnpm-lock.yaml → 使用 pnpm run 前缀
• 目录下存在 yarn.lock（且无 pnpm-lock.yaml）→ 使用 yarn 前缀
• 其他：使用 npm run 前缀（默认）

按以下优先级顺序匹配 scripts（PKG_RUN = 上方检测到的前缀）：

| 优先级 | 匹配条件 | 推导结果 | |--------|---------|---------| | 1 | scripts 中有 key 精确匹配 start-like 名称（electron/start:electron/dev:electron/serve:electron），或脚本值包含 electron ./electron-forge start | | | 2 | scripts.dev 或 scripts.serve 存在，且 devDependencies 或 dependencies 中含 electron | dev / serve | | 3 | scripts.start 存在，且 devDependencies 或 dependencies 中含 electron | start | | 4 | main 字段存在，且 devDependencies 或 dependencies 含 electron，且无上述 scripts | npx electron . | | 5 | devDependencies 或 dependencies 含 electron-forge，或 config 含 electron-forge | start（electron-forge 默认） | | 6 | scripts.dev 存在（普通 Web 项目） | dev | | 7 | scripts.start 存在（普通 Web 项目） | start |

• 若推导成功：
• 设置 START_COMMAND =
• 宣告：✅ 自动检测到启动命令：\\（来源：package.json scripts，包管理器：）
• 跳转至「Level 3b：写入 CLAUDE.md」
• 若 package.json 不存在或无法推导：继续 Level 3（询问用户）

Level 3：询问用户一次（业务友好语言）

用 AskUserQuestion 以业务语言提问（不展示技术错误信息）：

> 我需要知道怎么启动这个应用，才能帮你自动验证效果。 > > 请选择或输入： > 1. 告诉我启动命令（如 npm run dev、yarn start、electron .） > 2. 不知道，帮我从项目文件中判断

• 用户选 2（不知道）：重新执行 Level 2 推导；若仍无法推导，以业务语言询问项目类型（Web/Electron/其他），再尝试推导；若依然失败，请用户检查后重试
• 用户输入命令后：
• 语义校验：
• 若命令形如 （npm/yarn/pnpm/bun run xxx）：检查 package.json 中 scripts.xxx 是否存在，若不存在则提示用户确认（⚠️ 未在 package.json 中找到 script ""，是否仍使用此命令？）
• 若命令包含 --> 或换行符：以业务语言提示"命令格式有误，请检查后重输"，重新提问（此为格式安全防护，防止破坏 CLAUDE.md 注释结构）
• 其他裸命令：接受，不做额外校验
• 校验通过后：设置 START_COMMAND = ，设置 SOURCE = user-provided
• 继续「Level 3b：写入 CLAUDE.md」

Level 3b：写入 CLAUDE.md 持久化（Level 2 推导成功 或 Level 3 用户回答后执行）

在项目 CLAUDE.md 中追加启动命令记录（若已有 `

宣告：`✅ 启动命令已记录到 CLAUDE.md，后续会话自动复用，无需再次配置`

**Level 4：验证命令可用性（格式 + 安全校验，不实际启动）**

检查 START_COMMAND：
- 若命令为空 → 以业务语言提示，重进 Level 3
- 若命令包含 `-->` 或换行符 → 以业务语言提示"命令格式有误，请检查"，重进 Level 3（**安全防护：避免破坏 CLAUDE.md HTML 注释结构**）
- 若命令形如 ` `：验证 package.json 中该 script 是否存在（警告但不阻断）
- 若通过：START_COMMAND 推导完成，继续 TEST_COMMAND 推导（见下方「TEST_COMMAND 推导」章节）

---

#### 主动漂移检测（防止 AI 修改 package.json 后启动命令失效）

**触发时机**：本次会话执行过程中，若任何步骤写入或修改了 `package.json`（任意字段，包括 `scripts`、`dependencies`、`devDependencies`、`main`、`config`、`packageManager`）：

1. **重新执行 Level 2 推导**（从磁盘新鲜读取修改后的 package.json）
2. **对比结果**：
   - 若推导结果 = 当前 START_COMMAND → 无漂移，静默继续
   - 若推导结果 ≠ 当前 START_COMMAND（或 CLAUDE.md 中的覆盖值）：
     - 宣告：`⚠️ 检测到 package.json scripts 已更新，启动命令可能已变更`
     - 展示：`旧命令： → 新推导：`
     - 用 `AskUserQuestion` 询问：
       > package.json 的启动脚本有更新。是否同步更新启动命令？
       > 1. 是，使用新命令 ``（推荐）
       > 2. 保持旧命令 `` 不变
     - 用户选 1：更新 START_COMMAND，同步更新 CLAUDE.md 标记行
     - 用户选 2：保持 START_COMMAND 不变，CLAUDE.md 保持旧覆盖值

---

#### TEST_COMMAND 推导（与 START_COMMAND 并行，同一 Phase -1.5 内执行）

**目标**：自动确定项目的测试命令（TEST_COMMAND），供 Layer 0 和 Layer 2 使用。

**决策树（按优先级顺序执行，找到即停止）**

**Level 1：读取 CLAUDE.md 显式覆盖**

搜索当前项目的 CLAUDE.md，寻找 ce-work 测试命令标记：

- 若找到：
  - `source: user-provided` → 无条件使用，设置 `TEST_COMMAND = `，**跳转 Level 4**
  - `source: auto-detected` → 重新执行 Level 2 推导并比对：
    - 一致 → 使用，**跳转 Level 4**
    - 不一致 → 清除旧记录，**继续 Level 2**
- 若未找到：继续 Level 2

**Level 2：从项目配置文件动态推导（每次新鲜读取）**

按以下优先级顺序匹配（PKG_RUN = START_COMMAND 推导中已检测的包管理器前缀；若 START_COMMAND 推导跳过了 package.json 阶段导致 PKG_RUN 未定义，则对 package.json 相关条目重新执行包管理器检测）：

| 优先级 | 匹配条件 | 推导结果 |
|--------|---------|---------|
| 1 | `package.json` scripts.test 存在，且**不是** `"echo \"Error: no test specified\" && exit 1"`（npm 默认空命令） | ` test` |
| 2 | `Makefile` 有 `test:` target 或 `Justfile` 有 `test:` recipe | `make test` / `just test` |
| 3 | `pyproject.toml` 有 `[tool.pytest]`，或 `pytest.ini` 存在，或 `setup.cfg` 有 `[tool:pytest]` | `pytest` |
| 4 | `Cargo.toml` 存在 | `cargo test` |
| 5 | `go.mod` 存在 | `go test ./...` |
| 6 | 无法推导 | 继续 Level 3 |

- 若推导成功：设置 `TEST_COMMAND = `，宣告 `✅ 自动检测到测试命令：\`\``，**跳转 Level 3b**

**Level 3：询问用户（与 START_COMMAND 合并为一次交互）**

若 START_COMMAND 也需要询问，合并为一次 AskUserQuestion：

> 检测到以下命令配置：
> - 启动命令：``
> - 测试命令：``
>
> 1. 都对
> 2. 修改测试命令
> 3. 修改启动命令
> 4. 都需要修改

若仅 TEST_COMMAND 需要询问：

> 我需要知道怎么跑测试，才能帮你自动验证。
> 请输入测试命令（如 `npm test`、`pytest`、`cargo test`），或输入"无"表示项目无测试。

- 用户输入"无" → TEST_COMMAND 设为空，Layer 0/2 的测试路由标记 skip
- 用户输入命令 → 语义校验（与 START_COMMAND 一致：防 `-->` 注入 + script 存在性检查）
- 校验通过 → 设置 `TEST_COMMAND = `，SOURCE = `user-provided`

**Level 3b：写入 CLAUDE.md 持久化**

在项目 CLAUDE.md 中追加（若已有 `

Level 4：验证命令可用性

• 若命令为空 → TEST_COMMAND 未设置，Layer 0/2 测试路由标记 skip
• 若命令包含 --> 或换行符 → 提示格式有误，重进 Level 3
• 若命令形如 → 验证 package.json 中 script 是否存在（警告但不阻断）
• 若通过 → 宣告：

`` ✅ 环境指纹就绪： 启动命令 = 测试命令 = ``

Monorepo 处理：

• 根 package.json 有 scripts.test → 用根命令（通常是 turbo test / nx test 编排）
• 根无 test，当前 Unit 只改了 packages/foo/ → cd packages/foo && test
• 根无 test，改了多个子包 → AskUserQuestion 列出涉及的子包让用户选择

主动漂移检测（TEST_COMMAND）：

与 START_COMMAND 共用触发条件（package.json / Cargo.toml / pyproject.toml 被修改时）：

1. 重新执行 Level 2 推导
2. 若推导结果 ≠ 当前 TEST_COMMAND → 询问用户是否更新
3. 用户确认后同步更新 CLAUDE.md 标记行

---

Phase 0: Input Triage

Determine how to proceed based on what was provided in ``.

Plan document (input is a file path to an existing plan, specification, or todo file) → skip to Phase 1.

Bare prompt (input is a description of work, not a file path):

1. Scan the work area

• Identify files likely to change based on the prompt
• Find existing test files for those areas (search for test/spec files that import, reference, or share names with the implementation files)
• Note local patterns and conventions in the affected areas

1. Assess complexity and route

| Complexity | Signals | Action | |-----------|---------|--------| | Trivial | 1-2 files, no behavioral change (typo, config, rename) | Proceed to Phase 1 step 2 directly. Skip step 3 (Intent Gate) and step 4 ([R]). Apply Test Discovery if the change touches behavior-bearing code | | Small / Medium | Clear scope, under ~10 files | Build a task list from discovery. Proceed to Phase 1 step 2 | | Large | Cross-cutting, architectural decisions, 10+ files, touches auth/payments/migrations | Inform the user this would benefit from /ce:brainstorm or /ce:plan to surface edge cases and scope boundaries. Honor their choice. If proceeding, continue to step 3 (Intent Gate) |

1. Intent Gate（仅限 Large 复杂度 + bare prompt）

触发条件：复杂度评估为 Large 且输入为 bare prompt（非文件路径）。跳过条件：复杂度为 Trivial/Small/Medium，或输入为文件路径。

路由问题（使用 AskUserQuestion tool）: > 这个任务规模较大，建议先规划。你想： > 1. 先转 /ce:plan 创建结构化计划（推荐） > 2. 继续直接执行，我来补充关键信息 > 3. 取消

• 用户选 1（转计划）→ 调用 /ce:plan，结束当前执行
• 用户选 3（取消）→ 停止执行
• 用户选 2（继续执行）→ 进入关键信息补充

关键信息补充（仅当用户选择「继续执行」时）：

从以下 3 个维度中，针对 prompt 中尚未明确的部分提问：

目标（如 prompt 已清楚则跳过）: > 这次改动最终要达成什么可验证的结果？

边界（如 prompt 已指定范围则跳过）: > 哪些模块/文件在改动范围内？有什么明确不改的？

验收（如 prompt 已包含验收标准则跳过）: > 怎么判断做完了？用什么标准验收？

将用户补充的答案整合到任务列表构建中（forbidden_surfaces、acceptance criteria 等），然后继续步骤 4。

1. [R] 历史检索（bare prompt 场景，仅当 RMODEENABLED = true 时）

触发条件：输入为 bare prompt（非文件路径）且 RMODEENABLED = true（由 Phase -1 设置）。Trivial 任务跳过（见步骤 2）。

`` Task compound-engineering:research:learnings-researcher(prompt_content) ``

去重规则（当前 skill 内有效，跨 skill 不生效）： 同一 session 内相同关键词（lowercase + trim + token sort）不重复搜索。 子代理派发时各子代理 in-memory 状态独立，跨子代理去重不生效（同一搜索词可能被多个子代理重复触发）。 跨 skill 去重不生效（如先运行 ce:brainstorm [R]，再运行 ce:work [R]，相同关键词仍会重新检索）。

检索结果注入执行上下文，不修改 plan 文档格式。在每个 Implementation Unit 执行前， 如有相关历史经验，以注释形式提示：「📚 历史参考：[文档名] — [核心洞察]」。无匹配时写 No relevant learnings found，不阻断主流程。

[R]+[T] 组合行为：

• [R] 历史检索在 Phase 0 执行，结果注入 Phase 2 实现上下文
• Layer 3 验收审查可引用历史经验作为补充佐证（如"历史上类似场景通过了 X 检查"）
• 但 Layer 3 的验收标准以当前计划的验收场景为准，历史经验不改变 pass/fail 判断

---

Phase 1: Quick Start

1. Read Plan and Clarify (skip if arriving from Phase 0 with a bare prompt)

• Read the work document completely
• Treat the plan as a decision artifact, not an execution script
• If the plan includes sections such as Implementation Units, Work Breakdown, Requirements Trace, Files, Test Scenarios, or Verification, use those as the primary source material for execution
• Check for Execution note on each implementation unit — these carry the plan's execution posture signal for that unit (for example, test-first or characterization-first). Note them when creating tasks.
• Check for a Deferred to Implementation or Implementation-Time Unknowns section — these are questions the planner intentionally left for you to resolve during execution. Note them before starting so they inform your approach rather than surprising you mid-task
• Check for a Scope Boundaries section — these are explicit non-goals. Refer back to them if implementation starts pulling you toward adjacent work
• Review any references or links provided in the plan
• If the user explicitly asks for TDD, test-first, or characterization-first execution in this session, honor that request even if the plan has no Execution note
• If anything is unclear or ambiguous, ask clarifying questions now
• Get user approval to proceed
• Do not skip this - better to ask questions now than build the wrong thing

1. Setup Environment

First, check the current branch:

```bash currentbranch=$(git branch --show-current) defaultbranch=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')

# Fallback if remote HEAD isn't set if [ -z "$defaultbranch" ]; then defaultbranch=$(git rev-parse --verify origin/main >/dev/null 2>&1 && echo "main" || echo "master") fi ```

If already on a feature branch (not the default branch):

First, check whether the branch name is meaningful — a name like feat/crowd-sniff or fix/email-validation tells future readers what the work is about. Auto-generated worktree names (e.g., worktree-jolly-beaming-raven) or other opaque names do not.

If the branch name is meaningless or auto-generated, suggest renaming it before continuing: ``bash git branch -m ` Derive the new name from the plan title or work description (e.g., feat/crowd-sniff`). Present the rename as a recommended option alongside continuing as-is.

Then ask: "Continue working on [current_branch], or create a new branch?"

• If continuing (with or without rename), proceed to step 3
• If creating new, follow Option A or B below

If on the default branch, choose how to proceed:

Option A: Create a new branch ``bash git pull origin [default_branch] git checkout -b feature-branch-name ` Use a meaningful name based on the work (e.g., feat/user-authentication, fix/email-validation`).

Option B: Use a worktree (recommended for parallel development) ``bash skill: git-worktree # The skill will create a new branch from the default branch in an isolated worktree ``

Option C: Continue on the default branch

• Requires explicit user confirmation
• Only proceed after user explicitly says "yes, commit to [default_branch]"
• Never commit directly to the default branch without explicit permission

Recommendation: Use worktree if:

• You want to work on multiple features simultaneously
• You want to keep the default branch clean while experimenting
• You plan to switch between branches frequently

1. Create Todo List (skip if Phase 0 already built one, or if Phase 0 routed as Trivial)

• Use your available task tracking tool (e.g., TodoWrite, task lists) to break the plan into actionable tasks
• Derive tasks from the plan's implementation units, dependencies, files, test targets, and verification criteria
• Carry each unit's Execution note into the task when present
• For each unit, read the Patterns to follow field before implementing — these point to specific files or conventions to mirror
• Use each unit's Verification field as the primary "done" signal for that task
• Do not expect the plan to contain implementation code, micro-step TDD instructions, or exact shell commands
• Include dependencies between tasks
• Prioritize based on what need

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Jerrylalala
• Source: Jerrylalala/compound-engineering
• License: MIT

Install and usage instructions live in the source repository linked above.