企业官网建设流程全解析

claude-task-master 的 Kiro Hook 驱动工作流：用自动化钩子替代手动任务管理

【免费下载链接】claude-task-masterAn AI-powered task-management system you can drop into Cursor, Lovable, Windsurf, Roo, and others.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-task-master

在 Kiro（以及 Cursor、Lovable、Windsurf、Roo 等 AI 编程环境）中使用 claude-task-master 时，任务管理不应成为打断编码心流的手动负担。本项目在 .kiro/steering/taskmaster_hooks_workflow.md 中定义了一套完整的Hook 驱动工作流（Hook-Driven Workflow），通过"文件保存触发钩子 → 钩子询问 AI Agent → Agent 执行 Taskmaster 命令"的闭环，让测试通过、代码变更与依赖就绪自动转化为任务状态更新。读完本文，你将掌握这 7 个 Kiro Hook 的职责划分、触发机制与底层命令调用链，并能复现"实现 → 保存 → 测试通过 → 自动完成 → 依赖任务自动启动"的完整自动化循环。

核心原则：让 Hooks 接管任务管理

在 Kiro 中与 Taskmaster 协作时，避免手动将任务标记为 done。Hook 系统会根据以下信号自动处理任务完成：

• 测试成功：[TM] Test Success Task Completer检测到通过的测试，并提示完成对应任务
• 代码变更：[TM] Code Change Task Tracker持续监控实现进度
• 依赖链：[TM] Task Dependency Auto-Progression自动启动满足依赖条件的后续任务

这套原则与 .kiro/steering/dev_workflow.md 中"基本循环"一脉相承：传统流程要求开发者在编码后手动执行update-subtask记录进度、再手动执行set-status标记完成；而 Hook 工作流把这两步"决策权"移交给了自动化的钩子，让人工只保留最终确认权。

Hook 系统的整体架构

项目在 .kiro/hooks/ 目录下集中存放了 7 个 Kiro Hook 文件（同一份副本也发布在 assets/kiro-hooks/），覆盖从日常开发到提交流程的完整链路：

其中前三个是"自动化三件套"，直接支撑本文档描述的主工作流；后四个属于增强与周边环节。

Hook 文件结构：JSON 即声明

每个.kiro.hook文件都是标准 JSON，以[TM] Test Success Task Completer（.kiro/hooks/tm-test-success-task-completer.kiro.hook）为例，其字段含义如下：

{ "enabled": true, "name": "[TM] Test Success Task Completer", "description": "Mark tasks as done when their tests pass", "version": "1", "when": { "type": "fileEdited", "patterns": ["**/*test*.{js,ts,jsx,tsx,py,go,java,rb,php,rs,cpp,cs}", "!**/node_modules/**"] }, "then": { "type": "askAgent", "prompt": "A test file was just saved. Please:\n1. Identify the test framework/language and run the appropriate test command...\n4. If confirmed, mark the task as done with 'tm set-status --id=<task_id> --status=done'" } }

• enabled：是否启用，false即静默停用（如 Complexity Analyzer 默认关闭）
• when：触发条件，type支持fileEdited（文件保存/编辑）、manual（手动触发）、userTriggered（用户主动调用）；patterns用 glob 精确圈定监听范围，并以!**/node_modules/**这类排除规则过滤无关目录
• then：钩子触发后的动作，全部采用askAgent模式——把一段指令式 prompt 交给 AI Agent 执行，Agent 再调用tm（Taskmaster CLI）完成实际操作

fileEdited是这套自动化最关键的触发类型：保存文件即触发钩子，这也是文档强调"随时保存（Save Frequently）"的原因。

三个核心自动化 Hook 的调用链

1. 测试成功 → 任务完成（Test Success Task Completer）

监听范围覆盖主流测试文件命名：.kiro/hooks/tm-test-success-task-completer.kiro.hook 中的patterns匹配**/*test*.{js,ts,jsx,tsx,py,go,java,rb,php,rs,cpp,cs}、**/*spec*.{js,ts,jsx,tsx,rb}、**/test_*.py、**/*_test.go、**/*Test.java、**/*Tests.cs等，同时排除node_modules与vendor。

触发后的 Agent 指令链为：

1. 识别测试框架/语言，运行对应测试命令（npm test、pytest、go test、cargo test、dotnet test、mvn test等）
2. 若全部通过，找出引用该功能的任务
3. 对状态为in-progress的匹配任务，询问是否意味着任务完成
4. 经确认后执行tm set-status --id=<task_id> --status=done

这条链路与 .kiro/steering/taskmaster.md 中set_task_status的 MCP/CLI 说明一致（MCP 工具set_task_status，CLI 命令task-master set-status，支持pending/in-progress/done/review/cancelled等状态）。测试文件保存是任务完成信号中最可靠的一种，这也是文档要求"总是写测试"的根本原因。

2. 代码变更 → 进度记录（Code Change Task Tracker）

.kiro/hooks/tm-code-change-task-tracker.kiro.hook 监听所有主流源码文件（js/ts/py/go/rs/java/cpp/c/h/cs/rb/php/swift/kt/scala/clj 等），并排除node_modules、vendor、.git、build、dist、target、__pycache__。

触发后的 Agent 指令链为：

1. 用tm list --status=in-progress找到当前进行中的任务
2. 分析刚保存的文件，总结变更内容
3. 用tm update-subtask --id=<task_id> --prompt="Implemented: <summary_of_changes> in <file_path>"将实现细节追加到任务备注
4. 若变更看起来完成了任务描述，询问是否标记为 done

这里的update-subtask对应 .kiro/steering/taskmaster.md 中的update_subtask工具 /task-master update-subtask命令——其语义是带时间戳追加而非覆盖，天然适合持续记录实现旅程（implementation journey）。

3. 依赖完成 → 自动启动（Task Dependency Auto-Progression）

.kiro/hooks/tm-task-dependency-auto-progression.kiro.hook 监听.taskmaster/tasks/tasks.json及其目录下所有 JSON 文件——这是 Taskmaster 的任务存储文件，任何状态变更都会落盘于此。

触发后的 Agent 指令链为：

1. 检查tasks.json中刚变为done的任务
2. 找出所有依赖它的任务
3. 若某任务的全部依赖已满足但仍为pending，用tm set-status --id=<task_id> --status=in-progress启动它
4. 汇报哪些任务被自动启动及原因

该钩子直接消费了 Taskmaster 的依赖管理能力：依赖（dependencies字段，示例[1, 2.1]）在 .kiro/steering/dev_workflow.md 中被描述为带状态指示器显示（✅ 已完成 / ⏱️ 待处理），next命令会优先挑选依赖全部满足的任务。三者结合，便形成了"上一任务完成 → 依赖就绪 → 下一任务自动开工"的流水线。

AI Assistant 工作流：四步循环

实现功能时，AI 助手应遵循以下模式（来自 .kiro/steering/taskmaster_hooks_workflow.md）：

1. 先实现（Implement First）：写代码、建测试、做改动
2. 勤保存（Save Frequently）：钩子在文件保存时触发，自动跟踪进度
3. 让钩子决策（Let Hooks Decide）：允许钩子检测完成状态，而非手动设置状态
4. 响应提示（Respond to Prompts）：钩子建议任务完成时给予确认

这套循环与 .kiro/steering/dev_workflow.md 中"迭代式子任务实现"过程的区别在于：原流程步骤 6（update-subtask记录）与步骤 8（set-status标记完成）是 Agent 的主动动作，而 Hook 工作流把它们变成被动响应——Agent 的职责从"调用命令"降级为"确认钩子提议"，从而把注意力集中在编码本身。

AI 助手的关键规则

• 不要使用tm set-status --status=done，除非钩子未能检测到完成
• 总是编写测试——测试是"完成"最可靠的信号（对应 Test Success Task Completer 的检测逻辑）
• 实现后保存文件——这会触发进度跟踪（对应 Code Change Task Tracker）
• 信任钩子的建议——如果没有出现完成提示，说明可能还有更多工作需要做

其中第一条"不要手动置 done"是有兜底条件的：当钩子因文件命名不符合 patterns、测试命令执行失败或任务状态不匹配等原因漏检时，才允许人工兜底。

自动化带来的四种行为

• 进度日志（Progress Logging）：实现细节自动写入任务备注（由 Code Change Task Tracker 通过update-subtask完成）
• 基于证据的完成（Evidence-Based Completion）：只有满足判据（测试通过等）的任务才会被标记 done，杜绝"假装完成"
• 依赖管理（Dependency Management）：依赖完成时自动启动下一任务（由 Dependency Auto-Progression 完成）
• 自然流程（Natural Flow）：专注编码，而非任务管理的额外开销

手动覆盖的边界场景

仅对以下情况手动设置任务状态：

• 纯文档任务：无代码变更，钩子无从触发
• 无可测结果的任务：没有测试文件，Test Success Task Completer 无信号来源
• 缺乏测试覆盖的紧急修复：时间紧迫，无法先写测试

此时才使用tm set-status，且应克制使用——优先选择钩子驱动的完成方式。这与 .kiro/steering/dev_workflow.md 中"Task Status Management"的状态语义一致（pending待处理、done已完成并验证、deferred推迟，也支持自定义状态），区别仅在由谁发起状态变更。

端到端实现模式

1. 实现功能 → 保存文件 2. 编写测试 → 保存测试文件 3. 测试通过 → 钩子提示完成 4. 确认完成 → 下一任务自动启动

将该模式与三钩子的触发点对应起来看：步骤 1 触发 Code Change Task Tracker 记录进度，步骤 2 触发 Test Success Task Completer 运行测试，步骤 3 完成确认后 tasks.json 落盘又触发 Task Dependency Auto-Progression 启动后续任务。一个文件保存动作即可串联起整个任务状态机，这正是本工作流的核心价值。

周边辅助 Hooks（锦上添花）

除了自动化三件套，.kiro/hooks/ 还提供了四个辅助钩子：

• Complexity Analyzer（默认关闭）：监听tasks.json新任务，运行tm analyze-complexity --id=<task_id>，若复杂度评分 > 7 则自动tm expand --id=<task_id> --num=5扩展为子任务并建议依赖关系。如需启用，将enabled改为true即可
• Git Commit Task Linker（manual触发）：提交前运行git diff --staged分析变更，生成feat(task-<id>): <description>格式的提交信息，并给相关任务追加提交备注
• PR Readiness Checker（manual触发）：提 PR 前校验所有 done 任务的子任务是否完成、新功能是否有测试文件、是否残留 TODO，并自动生成 PR 描述与标题建议
• Daily Standup Assistant（userTriggered触发）：组合tm list --status=done（近 24 小时完成）、tm list --status=in-progress（当前进行）、tm next（推荐最高优先级任务）和依赖图，生成每日站会摘要

配置与运行前提

• Hook 文件位于 .kiro/hooks/，随.kiro目录一起纳入 Kiro 项目配置（.kiro下另有 steering 策略文档与 settings/mcp.json）
• 钩子内的tm命令依赖 Taskmaster MCP 服务：在 .kiro/settings/mcp.json 中通过npx -y task-master-ai启动，并在env段配置ANTHROPIC_API_KEY、OPENAI_API_KEY、GOOGLE_API_KEY等提供方密钥（占位符需替换为真实密钥）
• AI 相关命令（如测试运行、复杂度分析）需要对应提供方的 API key 可用；所有命令的完整 MCP/CLI 双接口说明见 .kiro/steering/taskmaster.md
• 任务数据存储在.taskmaster/tasks/tasks.json，项目初始化与 PRD 解析等前置步骤同样参考 .kiro/steering/taskmaster.md 中的init/parse_prd说明

总结

Taskmaster Hook 驱动工作流的本质，是把"任务状态机"从 AI 助手的手动维护项，重构为事件驱动的自动响应系统：保存源码触发进度记录，保存测试触发完成判定，tasks.json 落盘触发依赖推进。对于在 Kiro 中开发、希望减少任务管理开销的团队，这套模式提供了开箱即用的实践范本——你只需写代码、保存文件、确认钩子提议，其余交给自动化。

【免费下载链接】claude-task-masterAn AI-powered task-management system you can drop into Cursor, Lovable, Windsurf, Roo, and others.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-task-master