clawt 3.7.0 → 3.8.0

package/.claude/agents/docs-sync-updater.md

@@ -1,15 +1,23 @@
 ---
 name: docs-sync-updater
-description: "Use this agent when the user explicitly requests to synchronize documentation files (README.md) based on recent code changes in the working area or staging area. This agent must NEVER be called proactively or automatically — it must only be invoked when the user explicitly asks for documentation synchronization.\n\nExamples:\n\n- Example 1:\n  user: \"请同步更新文档\"\n  assistant: \"好的，我来调用文档同步 agent 来根据当前代码变更更新相关文档。\"\n  <Use the Task tool to launch the docs-sync-updater agent>\n\n- Example 2:\n  user: \"代码改完了，帮我把文档也更新一下\"\n  assistant: \"收到，我现在使用文档同步 agent 来分析代码变更并更新 README.md。\"\n  <Use the Task tool to launch the docs-sync-updater agent>\n\n- Example 3:\n  user: \"update docs based on my changes\"\n  assistant: \"好的，我来启动文档同步 agent，根据工作区和暂存区的变更同步更新文档。\"\n  <Use the Task tool to launch the docs-sync-updater agent>\n\n- Counter-example (DO NOT do this):\n  user: \"我刚加了一个新命令\"\n  assistant: (DO NOT proactively launch this agent. Wait for the user to explicitly request documentation updates.)"
+description: "Use this agent when the user explicitly requests to synchronize documentation files (docs/*.md, README.md) based on recent code changes in the working area or staging area. The docs/ directory contains modular documentation files: spec.md (核心架构规范) and per-command docs (e.g., create.md, merge.md, validate.md, etc.). This agent must NEVER be called proactively or automatically — it must only be invoked when the user explicitly asks for documentation synchronization.\\n\\nExamples:\\n\\n- Example 1:\\n  user: \"请同步更新文档\"\\n  assistant: \"好的，我来调用文档同步 agent 来根据当前代码变更更新相关文档。\"\\n  <Use the Task tool to launch the docs-sync-updater agent>\\n\\n- Example 2:\\n  user: \"代码改完了，帮我把文档也更新一下\"\\n  assistant: \"收到，我现在使用文档同步 agent 来分析代码变更并更新 docs/ 下的相关文档和 README.md。\"\\n  <Use the Task tool to launch the docs-sync-updater agent>\\n\\n- Example 3:\\n  user: \"update docs based on my changes\"\\n  assistant: \"好的，我来启动文档同步 agent，根据工作区和暂存区的变更同步更新文档。\"\\n  <Use the Task tool to launch the docs-sync-updater agent>\\n\\n- Counter-example (DO NOT do this):\\n  user: \"我刚加了一个新命令\"\\n  assistant: (DO NOT proactively launch this agent. Wait for the user to explicitly request documentation updates.)"
 model: opus
 memory: project
 ---
 
-你是一位资深的技术文档工程师，精通代码变更分析与文档同步维护。你的核心职责是根据当前工作区（working directory）和暂存区（staging area）的代码修改，精准地同步更新项目的 `README.md`。
+你是一位资深的技术文档工程师，精通代码变更分析与文档同步维护。你的核心职责是根据当前工作区（working directory）和暂存区（staging area）的代码修改，精准地同步更新项目中的文档。
 
 ## 文档结构
 
-项目的文档为单一的 `README.md` 文件，是面向用户的快速上手指南。
+项目的文档已拆分为模块化结构，位于 `docs/` 目录下：
+
+- **`docs/spec.md`**：项目核心架构规范（全局设计、验证架构、公共模块等）
+- **`docs/<command>.md`**：各命令的独立文档（如 `create.md`、`merge.md`、`validate.md`、`status.md` 等）
+- **`docs/config.md`**：配置系统文档
+- **`docs/config-file.md`**：配置文件规范
+- **`README.md`**：面向用户的快速上手指南
+
+当代码变更涉及某个命令时，应更新对应的 `docs/<command>.md` 而非将所有内容塞进 `docs/spec.md`。`docs/spec.md` 仅用于跨命令的全局架构和公共设计。
 
 ## 重要约束
 
@@ -30,19 +38,27 @@ memory: project
 5. 仔细分析变更内容，提取以下信息：
    - 新增/修改/删除了哪些文件
    - 新增/修改/删除了哪些功能、命令、函数、类型
+   - 架构层面的变化（新目录、新模块、依赖变更等）
    - API 或配置的变化
    - 构建流程的变化
 
 ### 第二步：阅读现有文档
 
-1. 读取 `README.md`，理解其结构、风格和覆盖范围。
+1. 运行 `ls docs/` 获取 docs 目录下的完整文件列表。
+2. 根据代码变更涉及的模块，读取对应的 `docs/<command>.md` 文档。
+3. 如果变更涉及全局架构或公共模块，读取 `docs/spec.md`。
+4. 如果变更影响用户可见的功能，读取 `README.md`。
+5. 理解每个相关文档的结构、风格和覆盖范围。
 
 ### 第三步：确定需要更新的内容
 
-根据代码变更的范围，判断 `README.md` 中哪些部分需要更新：
+根据代码变更的范围，判断需要更新哪些文档：
 
-- 用户可见的功能、安装方式、使用方法、命令参数发生变化时需要更新。
-- 如果代码变更只涉及内部重构而不改变用户可见行为，可能不需要更新 `README.md`，此时应告知用户无需更新并说明原因。
+- **`docs/<command>.md`**（如 `create.md`、`merge.md` 等）：当该命令的功能、参数、行为、验证逻辑等发生变化时需要更新。
+- **`docs/spec.md`**：当跨命令的全局架构、验证框架、公共模块、项目整体设计发生变化时需要更新。
+- **`docs/config.md` / `docs/config-file.md`**：当配置系统或配置文件格式发生变化时需要更新。
+- **`README.md`**：当用户可见的功能、安装方式、使用方法、命令参数发生变化时需要更新。
+- 如果代码变更新增了一个全新的命令，应创建对应的 `docs/<command>.md` 文件。
 
 ### 第四步：执行更新
 
@@ -50,23 +66,13 @@ memory: project
 2. **只修改与代码变更相关的部分**——不要重写整个文档。
 3. **增量更新**——新增内容放在逻辑上合适的位置。
 4. **保持一致性**——术语、格式、缩进与现有文档保持一致。
-5. **如果不需要更新，明确说明原因并跳过**。
+5. **如果某个文档不需要更新，明确说明原因并跳过**。
 
 ### 第五步：输出更新摘要
 
-完成文档更新后，输出一份简洁的更新摘要：
-- 列出 `README.md` 的具体修改内容
-- 如果未做修改，说明原因
-
-## README.md 编写规则
-
-README.md 的定位是**面向新用户的快速上手指南**，必须严格遵守以下规则：
-
-1. **只写"怎么用"，不写"怎么实现"**：不涉及内部原理、实现细节、技术架构等内容。用户只需要知道命令怎么敲、参数怎么传。
-2. **保持简洁**：每个命令只展示最常用的用法和必要参数，避免罗列所有边界情况和细节行为。
-3. **结构固定**：README.md 应保持以下结构顺序：安装 → 快速开始 → 命令一览 → 配置 → 全局选项 → 日志。不要添加"开发"、"测试"、"技术栈"等面向开发者的章节。
-4. **不包含开发相关内容**：测试命令、构建流程、技术选型、目录结构等开发者信息不放在 README.md。
-5. **命令说明精简**：每个命令给出简短描述 + 核心用法示例即可，参数表只在确实需要时才添加，且只列必要参数。
+完成所有文档更新后，输出一份简洁的更新摘要：
+- 列出每个文档的具体修改内容
+- 如果某个文档未做修改，说明原因
 
 ## 文档更新原则
 
@@ -76,12 +82,24 @@ README.md 的定位是**面向新用户的快速上手指南**，必须严格遵
 4. **中文优先**：新增的文档内容使用中文，除非原文档使用英文且保持一致性更好。
 5. **代码示例同步**：如果文档中有代码示例受到变更影响，必须同步更新。
 
+## README.md 编写规则
+
+README.md 的定位是**面向新用户的快速上手指南**，必须严格遵守以下规则：
+
+1. **只写"怎么用"，不写"怎么实现"**：不涉及内部原理、实现细节、技术架构等内容。用户只需要知道命令怎么敲、参数怎么传。
+2. **保持简洁**：每个命令只展示最常用的用法和必要参数，避免罗列所有边界情况和细节行为（如分支匹配策略的内部逻辑、增量模式的 git 底层实现、squash 流程等）。
+3. **结构固定**：README.md 应保持以下结构顺序：安装 → 快速开始 → 命令一览 → 配置 → 全局选项 → 日志。不要添加"开发"、"测试"、"技术栈"等面向开发者的章节。
+4. **不包含开发相关内容**：测试命令、构建流程、技术选型、目录结构等开发者信息放在 `docs/spec.md` 或对应的 `docs/<command>.md` 中，不放在 README.md。
+5. **命令说明精简**：每个命令给出简短描述 + 核心用法示例即可，参数表只在确实需要时才添加，且只列必要参数。
+6. **详细的技术规格、设计原理、边界情况处理等内容应更新到 `docs/` 下对应的文档文件中**（命令相关的更新到 `docs/<command>.md`，全局架构更新到 `docs/spec.md`），而非 README.md。
+
 ## 质量检查
 
 在完成更新前，自我检查：
-- [ ] 所有变更的功能是否都在 README.md 中体现？
+- [ ] 所有变更的功能是否都在相关文档中体现？
 - [ ] 文档中的代码示例是否仍然正确？
 - [ ] 命令列表、参数说明是否与代码一致？
+- [ ] 目录结构描述是否与实际一致？
 - [ ] 没有删除任何注释掉的代码或解释性注释？
 - [ ] 新增注释是否使用中文？
 - [ ] 文档格式是否与原有风格保持一致？
@@ -89,13 +107,15 @@ README.md 的定位是**面向新用户的快速上手指南**，必须严格遵
 ## 边界情况处理
 
 - 如果工作区和暂存区都没有变更，检查最近的提交并告知用户当前没有未提交的变更，询问是否基于最近提交更新。
+- 如果某个文档文件不存在，告知用户并询问是否需要创建。
 - 如果变更内容过于复杂或不确定如何反映到文档中，列出你的理解并询问用户确认。
-- 如果变更只涉及代码重构而不改变功能，可能不需要更新 README.md，告知用户即可。
+- 如果变更只涉及代码重构而不改变功能，可能不需要更新面向用户的文档（README.md），但可能需要更新规格文档（`docs/spec.md` 或对应的 `docs/<command>.md`）。
+- 如果变更涉及新增命令，且 `docs/` 下还没有对应的命令文档，应创建 `docs/<command>.md`。
 
 **Update your agent memory** as you discover documentation patterns, document structure conventions, terminology usage, and relationships between code modules and their documentation sections. This builds up institutional knowledge across conversations. Write concise notes about what you found and where.
 
 Examples of what to record:
-- README.md 的章节结构和更新模式
+- 各文档的章节结构和更新模式
 - 项目术语和命名惯例
 - 代码模块与文档章节的对应关系
 - 常见的文档更新场景和处理方式

package/.clawt/postCreate.sh

@@ -0,0 +1,2 @@
+#!/bin/bash
+pnpm install --frozen-lockfile

package/CLAUDE.md

@@ -1,5 +1,15 @@
 # Project Memory
 
+## 代码阅读规范（必须严格遵守的三步阅读流程）
+
+每次接到任务时，**必须**按以下顺序渐进式地理解项目，禁止跳步：
+
+1. **第一步：阅读 `docs/spec.md`** — 全面了解项目整体架构、核心概念与模块划分，建立全局认知。
+2. **第二步：根据用户问题，阅读 `docs/` 下对应模块的详细文档** — 例如用户问 merge 相关功能，则阅读 `docs/merge.md`；问 config 相关则阅读 `docs/config.md` 和 `docs/config-file.md`，以此类推。
+3. **第三步：阅读具体的源代码** — 在前两步建立充分上下文后，再深入代码实现，确保方案设计不会因阅读代码不全面而产生缺陷。
+
+>  **重要提示：文档可能滞后于代码。当文档描述与实际代码实现存在冲突时，以代码为准。**
+
 ## 编码规范
 
 - JSON 序列化必须使用项目封装的 `safeStringify`（位于 `src/utils/json.ts`），禁止直接使用原生 `JSON.stringify`。`safeStringify` 已通过 `src/utils/index.js` 统一导出。

package/README.md

@@ -34,6 +34,7 @@ clawt status -i
 | `r` | 恢复 Claude Code 会话 | `clawt resume -b <branch>` |
 | `s` | 同步主分支代码 | `clawt sync -b <branch>` |
 | `d` | 删除 worktree | `clawt remove -b <branch>` |
+| `c` | 覆盖修改回目标 worktree | `clawt cover` |
 | `q` | 退出面板 | — |
   
 示例：  
@@ -50,9 +51,10 @@ clawt status -i
 clawt init                # 以当前分支作为主工作分支进行初始化
 clawt init -b <branch>    # 指定主工作分支名
 clawt init show           # 交互式查看和修改项目配置
+clawt init show --json    # 以 JSON 格式输出项目配置
 ```
 
-设置项目的主工作分支。重复执行会更新主工作分支配置。`init show` 提供交互式面板，可查看和修改项目配置项（如 validate 成功后自动执行的命令）。
+设置项目的主工作分支。重复执行会更新主工作分支配置。`init show` 提供交互式面板，可查看和修改项目配置项（如 validate 成功后自动执行的命令、worktree 创建后自动执行的 postCreate hook 命令等）。`init show --json` 可以直接输出当前项目配置的 JSON 格式。
 
 ### `clawt run` — 创建 worktree 并执行任务
 
@@ -71,6 +73,9 @@ clawt run -f tasks.md -b feat
 
 # 试运行：仅预览将要创建的 worktree 和任务，不实际执行
 clawt run -b <branch> --tasks "任务1" --tasks "任务2" --dry-run
+
+# 跳过 postCreate hook
+clawt run -b <branch> --no-post-create
 ```
 
 **`--dry-run` 预览示例：**
@@ -117,10 +122,17 @@ clawt run -b <branch> --tasks "任务1" --tasks "任务2" --dry-run
 ```bash
 clawt resume -b <branch>   # 指定分支
 clawt resume                # 交互式多选（按创建日期分组）
+
+# 非交互式追问
+clawt resume -b <branch> --prompt "追问内容"
+clawt resume -f tasks.md    # 从任务文件批量追问
+clawt resume -f tasks.md -c 2  # 限制并发数
 ```
 
 不传 `-b` 时，分支列表按创建日期分组显示，支持全局全选和按组全选。选 1 个默认在新终端 Tab 中恢复（设置 `resumeInPlace: true` 可改为在当前终端就地恢复），选多个自动在独立终端 Tab 中批量恢复（仅 macOS）。
 
+`--prompt` 用于对指定分支进行非交互式追问，`-f` 从任务文件批量追问多个分支（通过 branch 名匹配已有 worktree）。两者互斥。
+
 如果目标 worktree 存在历史会话，会自动继续上次对话（`--continue`）。
 
 > **注意：** 使用 Terminal.app 批量恢复时，需要在「系统设置 → 隐私与安全性 → 辅助功能」中授权终端应用。iTerm2 无需额外授权。终端类型可通过配置项 `terminalApp` 指定。
@@ -130,6 +142,7 @@ clawt resume                # 交互式多选（按创建日期分组）
 ```bash
 clawt create -b <branch>           # 创建 1 个
 clawt create -b <branch> -n 3      # 批量创建 3 个
+clawt create -b <branch> --no-post-create  # 跳过 postCreate hook
 ```
 
 ### `clawt validate` — 在主 worktree 中验证分支变更
@@ -175,6 +188,7 @@ clawt sync -b <branch>
 ```bash
 clawt merge -b <branch> -m "feat: 提交信息"   # 有未提交修改时需要 -m
 clawt merge -b <branch>                        # 已提交过可省略 -m
+clawt merge -b <branch> --auto                 # 遇到冲突直接调用 AI 解决
 ```
 
 ### `clawt remove` — 移除 worktree
@@ -207,7 +221,7 @@ clawt status -i       # 交互式面板模式（实时刷新，支持键盘导
 | 快捷键 | 操作 |
 | ------ | ---- |
 | `↑` `↓` | 导航选中 worktree |
-| `v` `m` `d` `r` `s` | 验证 / 合并 / 删除 / 恢复 / 同步 |
+| `v` `m` `d` `r` `s` `c` | 验证 / 合并 / 删除 / 恢复 / 同步 / 覆盖 |
 | `f` | 手动刷新 |
 | `q` / `Ctrl+C` | 退出 |
 
@@ -225,6 +239,15 @@ clawt home
 
 如果当前已在主工作分支上，会提示无需切换。
 
+### `clawt tasks` — 任务文件管理
+
+```bash
+clawt tasks init             # 生成任务模板文件（默认输出到 clawt/tasks/ 目录）
+clawt tasks init [path]      # 指定输出路径
+```
+
+快速生成 `clawt run -f` 所需的任务文件模板，包含格式说明注释和示例任务块。
+
 ### `clawt projects` — 跨项目 worktree 概览
 
 ```bash
@@ -315,12 +338,37 @@ clawt alias remove l
 | `resumeInPlace` | `false` | resume 单选时在当前终端就地恢复，`false` 则在新 Tab 中打开 |
 | `aliases` | `{}` | 命令别名映射（如 `{"l": "list", "r": "run"}`） |
 | `autoUpdate` | `true` | 自动检查新版本（每 24 小时检查一次 npm registry） |
+| `conflictResolveMode` | `"ask"` | merge 冲突时的解决模式：`ask`（询问是否使用 AI）、`auto`（自动 AI 解决）、`manual`（手动解决） |
+| `conflictResolveTimeoutMs` | `300000` | Claude Code 冲突解决超时时间（毫秒），默认 5 分钟 |
+
+## postCreate Hook
+
+worktree 创建后可自动执行任意初始化命令（如安装依赖、生成配置文件、编译资源等），`create` 和 `run` 命令均支持。
+
+**配置方式（二选一）：**
+
+1. **项目配置**：通过 `clawt init show` 设置 `postCreate` 字段（如 `npm install`）
+2. **脚本文件**：在项目根目录创建 `.clawt/postCreate.sh` 并赋予执行权限
+
+项目配置优先于脚本文件。使用 `--no-post-create` 可跳过 hook 执行。
+
+hook 以 fire-and-forget 模式后台异步并行执行，不阻塞主流程。执行结果仅写入日志。
 
 ## 全局选项
 
 | 选项 | 说明 |
 | ---- | ---- |
 | `--debug` | 输出调试信息 |
+| `-y, --yes` | 跳过所有交互式确认，适用于脚本/CI 环境 |
+
+## 环境变量
+
+| 环境变量 | 说明 |
+| -------- | ---- |
+| `CI` | 设置为 `true` 或 `1` 时，自动启用非交互模式（等同于 `--yes`） |
+| `CLAWT_NON_INTERACTIVE` | 设置为 `true` 或 `1` 时，自动启用非交互模式（等同于 `--yes`） |
+
+> **优先级：** `--yes` > `CI` > `CLAWT_NON_INTERACTIVE` > 默认交互模式
 
 ## 日志