wave-agent-sdk 1.0.8 → 1.0.10

package/builtin/plugins/sdd/scripts/spec-count.js

@@ -1,77 +0,0 @@
-#!/usr/bin/env node
-// Generic, self-contained spec validator. Counts user stories and acceptance
-// scenarios under the project's specs directory and warns on missing sections.
-// Detects the specs dir: prefers docs/specs/, else specs/, else exits gracefully.
-// No dependency on any project's VitePress/docs-site modules.
-import fs from "node:fs";
-import path from "node:path";
-
-function detectSpecsDir() {
-  for (const dir of ["docs/specs", "specs"]) {
-    const resolved = path.resolve(process.cwd(), dir);
-    if (fs.existsSync(resolved)) return resolved;
-  }
-  return null;
-}
-
-function walk(dir, out = []) {
-  for (const entry of fs.readdirSync(dir, { withFileTypes: true })) {
-    const fullPath = path.join(dir, entry.name);
-    if (entry.isDirectory()) walk(fullPath, out);
-    else if (entry.isFile() && entry.name.endsWith(".md")) out.push(fullPath);
-  }
-  return out;
-}
-
-function countUserStories(content) {
-  const m = content.match(/^### 用户故事[：:]/gm);
-  return m ? m.length : 0;
-}
-
-function countAcceptanceScenarios(content) {
-  const m = content.match(/^\d+\.\s+\*\*假设\*\*/gm);
-  return m ? m.length : 0;
-}
-
-const specsDir = detectSpecsDir();
-if (!specsDir) {
-  console.log("未找到规格目录（docs/specs/ 或 specs/），跳过校验。");
-  process.exit(0);
-}
-
-const files = walk(specsDir).sort();
-const totals = { specs: 0, us: 0, ac: 0 };
-const warnings = [];
-
-// index.md is conventionally a directory listing page, not a spec — skip it.
-const specFiles = files.filter(
-  (fp) => path.basename(fp).toLowerCase() !== "index.md",
-);
-
-for (const fp of specFiles) {
-  const content = fs.readFileSync(fp, "utf-8");
-  const usCount = countUserStories(content);
-  const acCount = countAcceptanceScenarios(content);
-  const rel = path.relative(process.cwd(), fp);
-  totals.specs++;
-  totals.us += usCount;
-  totals.ac += acCount;
-  if (!content.match(/^## 用户场景与测试/m))
-    warnings.push(`${rel}: 缺少 "## 用户场景与测试" 章节`);
-  if (usCount === 0)
-    warnings.push(`${rel}: 未找到用户故事（期望 \`### 用户故事：\`）`);
-  if (acCount === 0)
-    warnings.push(
-      `${rel}: 未找到验收场景（期望 \`N. **假设** … **当** … **则** …\`）`,
-    );
-  console.log(`${rel}  用户故事: ${usCount}  验收场景: ${acCount}`);
-}
-
-console.log("---");
-console.log(
-  `规格: ${totals.specs}  用户故事: ${totals.us}  验收场景: ${totals.ac}`,
-);
-if (warnings.length) {
-  for (const w of warnings) console.warn(`⚠ ${w}`);
-  console.warn(`⚠ ${warnings.length} 条模板警告——见上方。`);
-}

package/builtin/plugins/sdd/skills/specify/SKILL.md

@@ -1,47 +0,0 @@
----
-name: specify
-description: 根据自然语言描述创建或更新功能规格说明，生成包含用户故事与验收场景的规格文件。
-user-invocable: false
----
-
-## 用户输入
-
-```text
-$ARGUMENTS
-```
-
-## 流程
-
-本技能由 AI 在会话中自动触发（不占用手动斜杠命令）。触发时机：用户提出新的需求、修改需求或涉及功能边界时，若对应规格尚未创建或已过期，则主动创建或更新规格说明。$ARGUMENTS 通常为空——需求描述直接来自对话上下文，不要让用户重复。
-
-根据对话中的功能描述，执行以下步骤：
-
-1. **确定规格文件路径**：
-   - **确定规格根目录**：优先复用项目中已有的规格目录——若 `docs/specs/` 存在则用之，否则若 `specs/` 存在则用之，否则默认 `specs/`（并在完成报告中说明所选目录，便于用户纠正）。
-   - **选择分组**：若规格目录下已有分组子目录，沿用其既有分组约定；否则默认扁平结构（直接放在规格根目录下）。
-   - 根据功能描述生成 2-4 个词的 slug（小写、连字符、保留缩写词），与组内已有文件名不冲突
-   - 规格文件路径：`<规格根目录>/<分组>/<slug>.md`（无分组时为 `<规格根目录>/<slug>.md`）
-
-2. **加载模板** `${WAVE_SKILL_DIR}/templates/spec-template.md`，了解必需章节。
-
-3. **编写规格说明**：
-   - 解析用户描述，提取关键概念：角色、操作、数据、约束
-   - 对于不明确的部分，根据上下文和行业标准做出合理推断
-   - 仅在关键决策处标记 `[待澄清：具体问题]`（最多 3 处）
-   - 填写 frontmatter（`name` 为功能中文名、`description` 为一句话简述、`order` 为控制组内排序的数字）
-   - 填写「用户场景与测试」章节，包含按优先级排序的用户故事（P1、P2、P3...），每个故事以「作为…，我希望…，以便…」描述，附 `**为什么是这个优先级**` 与 `**独立测试**`（不适用的可省略）
-   - 为每个用户故事编写可测试的验收场景（**假设** … **当** … **则** …）
-   - 写入规格文件，替换所有占位符
-
-4. **如果存在 `[待澄清]` 标记**（最多 3 处）：
-   - 将每个标记作为问题展示，附带建议答案
-   - 等待用户回复后更新规格文件
-
-5. 报告完成，输出规格文件路径。
-
-## 指南
-
-- 关注用户**需要什麼**和**为什么**，而非如何实现
-- 不包含实现细节（不涉及技术栈、API、代码结构）
-- 每个验收场景必须可测试、无歧义
-- 删除不适用的可选章节（不要留 "N/A"）

package/builtin/plugins/sdd/skills/specify/templates/spec-template.md

@@ -1,47 +0,0 @@
----
-name: "[功能名称]"
-description: "[一句话简短描述]"
-order: [数字，控制组内排序]
----
-
-# 功能规格说明：[功能名称]
-
-**创建日期**：[日期]
-
-## 用户场景与测试 *（必填）*
-
-### 用户故事：[简要标题]（优先级：P1）
-
-作为[角色]，我希望[操作]，以便[价值/目的]。
-
-**为什么是这个优先级**：[解释其价值以及为何具有此优先级]
-
-**独立测试**：[描述如何独立测试——例如，"可以通过 [具体操作] 进行完整测试，并交付 [具体价值]"]
-
-**验收场景**：
-
-1. **假设** [初始状态]，**当** [操作]，**则** [预期结果]
-2. **假设** [初始状态]，**当** [操作]，**则** [预期结果]
-
----
-
-### 用户故事：[简要标题]（优先级：P2）
-
-作为[角色]，我希望[操作]，以便[价值/目的]。
-
-**为什么是这个优先级**：[解释其价值以及为何具有此优先级]
-
-**独立测试**：[描述如何独立测试]
-
-**验收场景**：
-
-1. **假设** [初始状态]，**当** [操作]，**则** [预期结果]
-
----
-
-[根据需要添加更多用户故事，每个都分配优先级]
-
-### 边界情况
-
-- **[问题？]** [答案/处理方式]
-- **[问题？]** [答案/处理方式]

package/builtin/skills/loop/SKILL.md

@@ -1,79 +0,0 @@
----
-name: loop
-description: Run a prompt or slash command on a recurring interval (e.g. /loop 5m /foo, defaults to 10m)
-allowed-tools: CronCreate, Skill
-user-invocable: true
----
-
-# /loop — schedule a recurring prompt
-
-Parse the input below into `[interval] <prompt…>` and schedule it with CronCreate.
-
-## Usage
-
-```
-/loop [interval] <prompt>
-
-Run a prompt or slash command on a recurring interval.
-
-Intervals: Ns, Nm, Nh, Nd (e.g. 5m, 30m, 2h, 1d). Minimum granularity is 1 minute.
-If no interval is specified, defaults to 10m.
-
-Examples:
-  /loop 5m /babysit-prs
-  /loop 30m check the deploy
-  /loop 1h /standup 1
-  /loop check the deploy          (defaults to 10m)
-  /loop check the deploy every 20m
-```
-
-## Parsing (in priority order)
-
-1. **Leading token**: if the first whitespace-delimited token matches `^\d+[smhd]$` (e.g. `5m`, `2h`), that's the interval; the rest is the prompt.
-2. **Trailing "every" clause**: otherwise, if the input ends with `every <N><unit>` or `every <N> <unit-word>` (e.g. `every 20m`, `every 5 minutes`, `every 2 hours`), extract that as the interval and strip it from the prompt. Only match when what follows "every" is a time expression — `check every PR` has no interval.
-3. **Default**: otherwise, interval is `10m` and the entire input is the prompt.
-
-If the resulting prompt is empty, show usage `/loop [interval] <prompt>` and stop — do not call CronCreate.
-
-Examples:
-- `5m /babysit-prs` → interval `5m`, prompt `/babysit-prs` (rule 1)
-- `check the deploy every 20m` → interval `20m`, prompt `check the deploy` (rule 2)
-- `run tests every 5 minutes` → interval `5m`, prompt `run tests` (rule 2)
-- `check the deploy` → interval `10m`, prompt `check the deploy` (rule 3)
-- `check every PR` → interval `10m`, prompt `check every PR` (rule 3 — "every" not followed by time)
-- `5m` → empty prompt → show usage
-
-## Interval → cron
-
-Supported suffixes: `s` (seconds, rounded up to nearest minute, min 1), `m` (minutes), `h` (hours), `d` (days). Convert:
-
-| Interval pattern      | Cron expression     | Notes                                    |
-|-----------------------|---------------------|------------------------------------------|
-| `Nm` where N ≤ 59   | `*/N * * * *`     | every N minutes                          |
-| `Nm` where N ≥ 60   | `0 */H * * *`     | round to hours (H = N/60, must divide 24)|
-| `Nh` where N ≤ 23   | `0 */N * * *`     | every N hours                            |
-| `Nd`                | `0 0 */N * *`     | every N days at midnight local           |
-| `Ns`                | treat as `ceil(N/60)m` | cron minimum granularity is 1 minute  |
-
-**If the interval doesn't cleanly divide its unit** (e.g. `7m` → `*/7 * * * *` gives uneven gaps at :56→:00; `90m` → 1.5h which cron can't express), pick the nearest clean interval and tell the user what you rounded to before scheduling.
-
-## Avoid the :00 and :30 minute marks
-
-When the user's request is approximate, pick a minute that is NOT 0 or 30:
-- "every morning around 9" → `57 8 * * *` or `3 9 * * *` (not `0 9 * * *`)
-- "hourly" → `7 * * * *` (not `0 * * * *`)
-
-Only use minute 0 or 30 when the user names that exact time and clearly means it ("at 9:00 sharp", "at half past").
-
-## Action
-
-1. Call CronCreate with:
-   - `cron`: the expression from the table above
-   - `prompt`: the parsed prompt from above, verbatim (slash commands are passed through unchanged)
-   - `recurring`: `true`
-2. Briefly confirm: what's scheduled, the cron expression, the human-readable cadence, that recurring tasks auto-expire after 7 days, and that they can cancel sooner with CronDelete (include the job ID).
-3. **Then immediately execute the parsed prompt now** — don't wait for the first cron fire. If it's a slash command, run it directly; otherwise act on it directly.
-
-## Input
-
-$ARGUMENTS

package/builtin/skills/settings/ENV.md

@@ -1,78 +0,0 @@
-# Wave Environment Variables Configuration
-
-Environment variables allow you to customize Wave's behavior, configure AI models, and provide context to hooks and tools. This document provides detailed guidance on how to configure environment variables in `settings.json`.
-
-## The `env` Field
-
-Environment variables are configured in the `env` field of `settings.json`. It is a simple key-value pair of strings.
-
-```json
-{
-  "env": {
-    "WAVE_MODEL": "gemini-3-flash",
-    "MY_CUSTOM_VAR": "some-value"
-  }
-}
-```
-
-## Supported `WAVE_*` Environment Variables
-
-Wave uses several environment variables to control its core functionality. Variables marked **OS env only** are read from the OS environment (or constructor / stdio `initialize` params) and are **NOT** read from settings.json `env` — set them in your shell, not in the `env` field.
-
-| Variable | Description | Default |
-| :--- | :--- | :--- |
-| `WAVE_API_KEY` | API key for the AI gateway. | - |
-| `WAVE_BASE_URL` | Base URL for the AI gateway. | - |
-| `WAVE_SERVER_URL` | Server URL for SSO authentication. **OS env only** — set via OS env or `options.serverUrl`; not read from settings.json `env` (avoids a startup 401 race). | `https://codechat.codewave.163.com` |
-| `WAVE_CUSTOM_HEADERS` | Custom HTTP headers for the AI gateway. Newline-separated `Key: Value` pairs (e.g., `"X-Foo: bar\nAuthorization: Bearer xxx"`). | - |
-| `WAVE_MODEL` | The primary AI model to use for the agent. | `gemini-3-flash` |
-| `WAVE_FAST_MODEL` | The fast AI model to use for quick tasks. | `gemini-2.5-flash` |
-| `WAVE_VISION_MODEL` | Vision-capable model used by the built-in `vision` subagent for image recognition. When set, the built-in `vision` subagent is registered (its frontmatter `model: visionModel` resolves to this value); when unset, the subagent is not loaded. Useful when the main model is fast but non-vision (e.g. DeepSeek). | - (not registered) |
-| `WAVE_MAX_INPUT_TOKENS` | Maximum number of input tokens allowed. | `200000` |
-| `WAVE_MAX_OUTPUT_TOKENS` | Maximum number of output tokens allowed. | `32000` |
-| `WAVE_DISABLE_AUTO_MEMORY` | Set to `1` or `true` to disable the auto-memory feature. | `false` |
-| `WAVE_AUTO_MEMORY_FREQUENCY` | Auto memory update frequency. `1` = every turn, `2` = every 2 turns, etc. | `1` |
-| `WAVE_TASK_LIST_ID` | Explicitly set the task list ID for the session. | (Session ID) |
-| `WAVE_PLUGIN_GIT_TIMEOUT_MS` | Timeout in milliseconds for git operations when installing plugins. **OS env only** (infrastructure). | `300000` |
-
-## Configuration Scopes
-
-Environment variables can be set in different scopes. Wave merges scopes from lowest to highest priority and stores the result in the agent's **per-session environment snapshot**. The snapshot takes priority over OS environment variables but is **NOT written to `process.env`** — this keeps multiple sessions in one `wave --stdio` process from polluting each other.
-
-Precedence (highest to lowest):
-
-1.  **Local Scope**: `.wave/settings.local.json` (Local overrides, ignored by git)
-2.  **Project Scope**: `.wave/settings.json` (Project-specific settings, shared via git)
-3.  **User Scope**: `~/.wave/settings.json` (Global settings for all projects)
-4.  **System Environment**: Variables set in your shell (e.g., `export WAVE_API_KEY=...`). Used as a fallback when a key is absent from the settings snapshot.
-
-> Settings `env` shadows (does not mutate) OS env: a key set in both settings.json `env` and the OS environment resolves to the settings value for that session, while the OS value remains untouched and visible to unrelated processes.
-
-## Custom Environment Variables
-
-You can also define custom environment variables in the `env` field. These variables are stored in the session's environment snapshot and will be available to:
-
-- **Hooks**: Any shell command executed as a hook will have these variables in its environment (merged on top of OS env).
-- **Tools**: Tools like `Bash` will have access to these variables (merged on top of OS env).
-
-In `wave --stdio` mode one process hosts multiple sessions; each session keeps its own snapshot, so sessions with different `env` do not pollute each other (no "last session wins").
-
-Example:
-```json
-{
-  "env": {
-    "PROJECT_NAME": "my-awesome-project",
-    "DEPLOY_TARGET": "staging"
-  }
-}
-```
-
-## Live Reload
-
-Environment variables configured in `settings.json` support **live reload**. When you modify the `env` field in any `settings.json` file (user, project, or local scope), the changes take effect immediately without requiring a Wave session restart — the session's environment snapshot is refreshed and subsequent resolve calls / subprocess spawns use the new values.
-
-## Best Practices
-
-- **Use Local Overrides for Secrets**: Never commit sensitive information like `WAVE_API_KEY` to `settings.json`. Use `settings.local.json` instead.
-- **Standard Naming**: Use uppercase and underscores for environment variable names (e.g., `MY_VARIABLE`).
-- **Avoid Overriding System Variables**: Be careful not to override standard system variables like `PATH` or `HOME` unless you have a specific reason to do so.

package/builtin/skills/settings/HOOKS.md

@@ -1,227 +0,0 @@
-# Wave Hooks Configuration
-
-Hooks allow you to automate tasks when certain events occur in Wave. This document provides detailed guidance on how to configure hooks in `settings.json`.
-
-## Hook Events
-
-Wave supports the following hook events:
-
-- `PreToolUse`: Triggered before a tool is executed.
-- `PostToolUse`: Triggered after a tool has finished executing.
-- `UserPromptSubmit`: Triggered when a user submits a prompt.
-- `PermissionRequest`: Triggered when Wave requests permission to use a tool.
-- `Stop`: Triggered when Wave finishes its response cycle (no more tool calls).
-- `SubagentStop`: Triggered when a subagent finishes its response cycle.
-- `WorktreeCreate`: Triggered when a new worktree is created.
-- `WorktreeRemove`: Triggered before a worktree is removed (e.g., via ExitWorktree with `action: "remove"`). Non-blocking. Fires **before** the worktree directory is deleted so hooks can still read files inside it. The hook receives `worktree_path` in the JSON input. Useful for cleanup tasks (e.g., `docker compose -p $(basename "$worktree_path") down`).
-- `CwdChanged`: Triggered when the working directory changes (e.g., entering/exiting a worktree). Non-blocking.
-- `SessionStart`: Triggered during session initialization. Hooks can inject `additionalContext` and `initialUserMessage` via stdout.
-- `SessionEnd`: Triggered during agent destruction (fire-and-forget, non-blocking). Useful for cleanup, resource teardown, and analytics.
-- `PreCompact`: Triggered before conversation compaction. Hook stdout is captured as additional instructions and merged into the compaction prompt.
-- `PostCompact`: Triggered after conversation compaction completes. Receives the compact summary text.
-
-## Hook Configuration Structure
-
-Hooks are configured in the `hooks` field of `settings.json`. Each event can have multiple hook configurations.
-
-```json
-{
-  "hooks": {
-    "PreToolUse": [
-      {
-        "matcher": "Write",
-        "hooks": [
-          {
-            "command": "pnpm lint",
-            "description": "Run lint before writing files"
-          }
-        ]
-      }
-    ],
-    "PermissionRequest": [
-      {
-        "matcher": "Bash",
-        "hooks": [
-          {
-            "command": "echo \"Permission requested for Bash tool\" >> hooks.log",
-            "description": "Log permission requests for Bash"
-          }
-        ]
-      }
-    ]
-  }
-}
-```
-
-## Hook Configuration Fields
-
-- `matcher`: (Optional) A pattern to match against the tool name (e.g., "Write", "Read*", "/^Edit/"). Only applicable for `PreToolUse`, `PostToolUse`, and `PermissionRequest`.
-- `hooks`: An array of hook commands to execute.
-  - `command`: The shell command to execute.
-  - `description`: A brief description of the hook's purpose.
-  - `async`: (Optional) Whether the hook should run in the background without blocking (default: `false`).
-  - `timeout`: (Optional) Maximum execution time in seconds (default: `600`).
-
-## Hook Input JSON
-
-Wave provides detailed context to hook processes via `stdin` as a JSON object. This allows hooks to make informed decisions based on the current state.
-
-### Common Fields
-- `session_id`: The current session ID.
-- `transcript_path`: Path to the session transcript file (JSON).
-- `cwd`: The current working directory.
-- `hook_event_name`: The name of the triggering event.
-
-### Event-Specific Fields
-- `tool_name`: (PreToolUse, PostToolUse, PermissionRequest) The name of the tool.
-- `tool_input`: (PreToolUse, PostToolUse, PermissionRequest) The input parameters passed to the tool.
-- `tool_response`: (PostToolUse) The result of the tool execution.
-- `user_prompt`: (UserPromptSubmit) The text submitted by the user.
-- `subagent_type`: (If executed by a subagent) The type of the subagent.
-- `name`: (WorktreeCreate) The name of the new worktree.
-- `worktree_path`: (WorktreeRemove) The absolute path of the worktree about to be removed. Derive the worktree name with `basename "$worktree_path"`.
-- `old_cwd`: (CwdChanged) The previous working directory.
-- `new_cwd`: (CwdChanged) The new working directory.
-- `compact_instructions`: (PreCompact) Custom instructions for the compaction, if any.
-- `compact_summary`: (PostCompact) The AI-generated compaction summary text.
-- `source`: (SessionStart) The session start source: `"startup"`, `"resume"`, or `"compact"`.
-- `agent_type`: (SessionStart) The agent type identifier.
-- `end_source`: (SessionEnd) The session end source: `"exit"`, `"stop"`, or `"compact"`.
-
-## Hook Exit Codes
-
-Hooks can communicate status and control Wave's behavior using exit codes:
-
-- **Exit 0**: Success. Wave continues its normal execution.
-- **Exit 2**: Blocking Error. Wave blocks the current operation and provides feedback based on the event:
-    - `UserPromptSubmit`: Blocks prompt processing and shows `stderr` as a user error.
-    - `PreToolUse`: Blocks tool execution and provides `stderr` to the agent as feedback.
-    - `PostToolUse`: Appends `stderr` to the tool result as feedback for the agent.
-    - `Stop`: Blocks the stop operation and provides `stderr` to the agent.
-    - `WorktreeCreate` / `WorktreeRemove` / `CwdChanged` / `PreCompact` / `PostCompact`: Shows `stderr` in an error block, but does not block the operation.
-    - `SessionStart` / `SessionEnd`: Shows `stderr` in an error block, but does not block startup or shutdown.
-- **Other Exits (e.g., Exit 1)**: Non-blocking error. Wave continues execution but shows `stderr` as a warning to the user.
-
-## SessionStart Hooks
-
-`SessionStart` hooks fire during session initialization. They can inject context and messages into the session via stdout.
-
-### Stdout Processing
-
-Hook stdout is processed as follows:
-- If stdout is valid JSON with `hookSpecificOutput.additionalContext` (Claude Code format), that value is injected as additional context.
-- If stdout is valid JSON with `initialUserMessage` at the top level, that value is injected as the initial user message.
-- If stdout is not JSON, the entire output is appended as additional context.
-
-Example hook output:
-```json
-{"hookSpecificOutput": {"hookEventName": "SessionStart", "additionalContext": "User prefers concise responses"}, "initialUserMessage": "Here is my current task..."}
-```
-
-### Example Configuration
-```json
-{
-  "hooks": {
-    "SessionStart": [
-      {
-        "hooks": [
-          {
-            "command": "echo '{\"hookSpecificOutput\": {\"hookEventName\": \"SessionStart\", \"additionalContext\": \"Project uses pnpm and TypeScript\"}}'",
-            "description": "Inject project context at session start"
-          }
-        ]
-      }
-    ]
-  }
-}
-```
-
-## SessionEnd Hooks
-
-`SessionEnd` hooks fire during agent destruction (fire-and-forget, non-blocking). They are useful for cleanup tasks, resource teardown, and analytics.
-
-### Input
-SessionEnd hooks receive `end_source` in the JSON input indicating how the session ended:
-- `"exit"`: User exited the session
-- `"stop"`: Session was explicitly stopped
-- `"compact"`: Session was compacted
-
-### Example Configuration
-```json
-{
-  "hooks": {
-    "SessionEnd": [
-      {
-        "hooks": [
-          {
-            "command": "echo '{\"session_id\": \"$WAVE_SESSION_ID\"}' >> /tmp/session-analytics.log",
-            "description": "Log session end for analytics",
-            "async": true
-          }
-        ]
-      }
-    ]
-  }
-}
-```
-
-## WorktreeRemove Hooks
-
-`WorktreeRemove` hooks fire **before** the worktree directory is deleted, so they can still read files inside it. They are non-blocking (Notification type): the hook never replaces `git worktree remove` itself. Useful for cleaning up external resources that were provisioned for the worktree (databases, containers, etc.).
-
-### Input
-WorktreeRemove hooks receive `worktree_path` in the JSON input (alongside the common fields `session_id`, `transcript_path`, `cwd`, `hook_event_name`). The worktree name can be derived via `basename "$worktree_path"`.
-
-### Example Configuration
-```json
-{
-  "hooks": {
-    "WorktreeRemove": [
-      {
-        "hooks": [
-          {
-            "command": "worktree_path=$(jq -r '.worktree_path') && docker compose -p \"$(basename \"$worktree_path\")\" down || true",
-            "description": "Tear down the worktree's docker compose project before removal"
-          }
-        ]
-      }
-    ]
-  }
-}
-```
-
-## Live Reload
-
-Hook configurations support **live reload**. When you modify hooks in `settings.json`, the changes take effect immediately without restarting Wave.
-
-## Plugin Hooks
-
-When hooks are registered via a **plugin**, Wave automatically:
-
-1. Substitutes `${WAVE_PLUGIN_ROOT}` with the plugin's directory path in the command string
-2. Injects `WAVE_PLUGIN_ROOT` as an environment variable into the hook process
-
-```json
-{
-  "hooks": {
-    "WorktreeCreate": [
-      {
-        "hooks": [
-          {
-            "command": "${WAVE_PLUGIN_ROOT}/scripts/setup-worktree.sh"
-          }
-        ]
-      }
-    ]
-  }
-}
-```
-
-The shell also receives `WAVE_PLUGIN_ROOT` as an env var, so `$WAVE_PLUGIN_ROOT` works in the hook script itself.
-
-## Best Practices
-
-- **Keep hooks fast**: Long-running hooks can slow down your workflow unless they are `async`.
-- **Use descriptive names**: Help yourself and others understand what each hook does.
-- **Test your hooks**: Run the commands manually first to ensure they work as expected.
-- **Use local overrides**: For machine-specific hooks, use `.wave/settings.local.json`.