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 名称触发类型启用状态核心职责[TM] Test Success Task CompleterfileEdited测试文件✅测试通过时标记任务完成[TM] Code Change Task TrackerfileEdited源码文件✅记录实现进度到任务备注[TM] Task Dependency Auto-ProgressionfileEditedtasks.json✅依赖完成后自动启动后续任务[TM] Complexity AnalyzerfileEditedtasks.json⛔默认关闭新任务复杂度分析并自动扩展[TM] Git Commit Task Linkermanual✅提交信息与任务关联[TM] PR Readiness Checkermanual✅提 PR 前校验任务完成度[TM] Daily Standup AssistantuserTriggered✅每日站会总结与任务推荐其中前三个是自动化三件套直接支撑本文档描述的主工作流后四个属于增强与周边环节。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 --idtask_id --statusdone } }enabled是否启用false即静默停用如 Complexity Analyzer 默认关闭when触发条件type支持fileEdited文件保存/编辑、manual手动触发、userTriggered用户主动调用patterns用 glob 精确圈定监听范围并以!**/node_modules/**这类排除规则过滤无关目录then钩子触发后的动作全部采用askAgent模式——把一段指令式 prompt 交给 AI Agent 执行Agent 再调用tmTaskmaster 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 指令链为识别测试框架/语言运行对应测试命令npm test、pytest、go test、cargo test、dotnet test、mvn test等若全部通过找出引用该功能的任务对状态为in-progress的匹配任务询问是否意味着任务完成经确认后执行tm set-status --idtask_id --statusdone这条链路与 .kiro/steering/taskmaster.md 中set_task_status的 MCP/CLI 说明一致MCP 工具set_task_statusCLI 命令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 指令链为用tm list --statusin-progress找到当前进行中的任务分析刚保存的文件总结变更内容用tm update-subtask --idtask_id --promptImplemented: summary_of_changes in file_path将实现细节追加到任务备注若变更看起来完成了任务描述询问是否标记为 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 指令链为检查tasks.json中刚变为done的任务找出所有依赖它的任务若某任务的全部依赖已满足但仍为pending用tm set-status --idtask_id --statusin-progress启动它汇报哪些任务被自动启动及原因该钩子直接消费了 Taskmaster 的依赖管理能力依赖dependencies字段示例[1, 2.1]在 .kiro/steering/dev_workflow.md 中被描述为带状态指示器显示✅ 已完成 / ⏱️ 待处理next命令会优先挑选依赖全部满足的任务。三者结合便形成了上一任务完成 → 依赖就绪 → 下一任务自动开工的流水线。AI Assistant 工作流四步循环实现功能时AI 助手应遵循以下模式来自 .kiro/steering/taskmaster_hooks_workflow.md先实现Implement First写代码、建测试、做改动勤保存Save Frequently钩子在文件保存时触发自动跟踪进度让钩子决策Let Hooks Decide允许钩子检测完成状态而非手动设置状态响应提示Respond to Prompts钩子建议任务完成时给予确认这套循环与 .kiro/steering/dev_workflow.md 中迭代式子任务实现过程的区别在于原流程步骤 6update-subtask记录与步骤 8set-status标记完成是 Agent 的主动动作而 Hook 工作流把它们变成被动响应——Agent 的职责从调用命令降级为确认钩子提议从而把注意力集中在编码本身。AI 助手的关键规则不要使用tm set-status --statusdone除非钩子未能检测到完成总是编写测试——测试是完成最可靠的信号对应 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 --idtask_id若复杂度评分 7 则自动tm expand --idtask_id --num5扩展为子任务并建议依赖关系。如需启用将enabled改为true即可Git Commit Task Linkermanual触发提交前运行git diff --staged分析变更生成feat(task-id): description格式的提交信息并给相关任务追加提交备注PR Readiness Checkermanual触发提 PR 前校验所有 done 任务的子任务是否完成、新功能是否有测试文件、是否残留 TODO并自动生成 PR 描述与标题建议Daily Standup AssistantuserTriggered触发组合tm list --statusdone近 24 小时完成、tm list --statusin-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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 claude-task-master 的 Kiro Hook 驱动工作流：用自动化钩子替代手动任务管理
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 名称触发类型启用状态核心职责[TM] Test Success Task CompleterfileEdited测试文件✅测试通过时标记任务完成[TM] Code Change Task TrackerfileEdited源码文件✅记录实现进度到任务备注[TM] Task Dependency Auto-ProgressionfileEditedtasks.json✅依赖完成后自动启动后续任务[TM] Complexity AnalyzerfileEditedtasks.json⛔默认关闭新任务复杂度分析并自动扩展[TM] Git Commit Task Linkermanual✅提交信息与任务关联[TM] PR Readiness Checkermanual✅提 PR 前校验任务完成度[TM] Daily Standup AssistantuserTriggered✅每日站会总结与任务推荐其中前三个是自动化三件套直接支撑本文档描述的主工作流后四个属于增强与周边环节。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 --idtask_id --statusdone } }enabled是否启用false即静默停用如 Complexity Analyzer 默认关闭when触发条件type支持fileEdited文件保存/编辑、manual手动触发、userTriggered用户主动调用patterns用 glob 精确圈定监听范围并以!**/node_modules/**这类排除规则过滤无关目录then钩子触发后的动作全部采用askAgent模式——把一段指令式 prompt 交给 AI Agent 执行Agent 再调用tmTaskmaster 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 指令链为识别测试框架/语言运行对应测试命令npm test、pytest、go test、cargo test、dotnet test、mvn test等若全部通过找出引用该功能的任务对状态为in-progress的匹配任务询问是否意味着任务完成经确认后执行tm set-status --idtask_id --statusdone这条链路与 .kiro/steering/taskmaster.md 中set_task_status的 MCP/CLI 说明一致MCP 工具set_task_statusCLI 命令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 指令链为用tm list --statusin-progress找到当前进行中的任务分析刚保存的文件总结变更内容用tm update-subtask --idtask_id --promptImplemented: summary_of_changes in file_path将实现细节追加到任务备注若变更看起来完成了任务描述询问是否标记为 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 指令链为检查tasks.json中刚变为done的任务找出所有依赖它的任务若某任务的全部依赖已满足但仍为pending用tm set-status --idtask_id --statusin-progress启动它汇报哪些任务被自动启动及原因该钩子直接消费了 Taskmaster 的依赖管理能力依赖dependencies字段示例[1, 2.1]在 .kiro/steering/dev_workflow.md 中被描述为带状态指示器显示✅ 已完成 / ⏱️ 待处理next命令会优先挑选依赖全部满足的任务。三者结合便形成了上一任务完成 → 依赖就绪 → 下一任务自动开工的流水线。AI Assistant 工作流四步循环实现功能时AI 助手应遵循以下模式来自 .kiro/steering/taskmaster_hooks_workflow.md先实现Implement First写代码、建测试、做改动勤保存Save Frequently钩子在文件保存时触发自动跟踪进度让钩子决策Let Hooks Decide允许钩子检测完成状态而非手动设置状态响应提示Respond to Prompts钩子建议任务完成时给予确认这套循环与 .kiro/steering/dev_workflow.md 中迭代式子任务实现过程的区别在于原流程步骤 6update-subtask记录与步骤 8set-status标记完成是 Agent 的主动动作而 Hook 工作流把它们变成被动响应——Agent 的职责从调用命令降级为确认钩子提议从而把注意力集中在编码本身。AI 助手的关键规则不要使用tm set-status --statusdone除非钩子未能检测到完成总是编写测试——测试是完成最可靠的信号对应 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 --idtask_id若复杂度评分 7 则自动tm expand --idtask_id --num5扩展为子任务并建议依赖关系。如需启用将enabled改为true即可Git Commit Task Linkermanual触发提交前运行git diff --staged分析变更生成feat(task-id): description格式的提交信息并给相关任务追加提交备注PR Readiness Checkermanual触发提 PR 前校验所有 done 任务的子任务是否完成、新功能是否有测试文件、是否残留 TODO并自动生成 PR 描述与标题建议Daily Standup AssistantuserTriggered触发组合tm list --statusdone近 24 小时完成、tm list --statusin-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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考