# Ce:work

> 3: [T][T+][V][V+][R] 执行计划（Agent Teams+四层验证）

- **Type:** Skill
- **Install:** `agentstack add skill-jerrylalala-compound-engineering-ce-work`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [Jerrylalala](https://agentstack.voostack.com/s/jerrylalala)
- **Installs:** 0
- **Category:** [Communication](https://agentstack.voostack.com/c/communication)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [Jerrylalala](https://github.com/Jerrylalala)
- **Source:** https://github.com/Jerrylalala/compound-engineering/tree/main/plugins/compound-engineering/skills/ce-work

## Install

```sh
agentstack add skill-jerrylalala-compound-engineering-ce-work
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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]`：
  - 设置 R_MODE_ENABLED = true
  - 从参数中移除 `[R]`
- 否则：R_MODE_ENABLED = false

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

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

**触发条件**：V_MODE_ENABLED = 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

2. **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) |

3. **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。

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

   触发条件：输入为 bare prompt（非文件路径）且 R_MODE_ENABLED = 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

2. **Setup Environment**

   First, check the current branch:

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

   # Fallback if remote HEAD isn't set
   if [ -z "$default_branch" ]; then
     default_branch=$(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

3. **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](https://github.com/Jerrylalala)
- **Source:** [Jerrylalala/compound-engineering](https://github.com/Jerrylalala/compound-engineering)
- **License:** MIT

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** yes
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** yes
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-jerrylalala-compound-engineering-ce-work
- Seller: https://agentstack.voostack.com/s/jerrylalala
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.