关于 task-analyzer
task-analyzer 是面向 Agent 的任务分析技能,可判断任务目的、规模和类型,并依据 skills-index.yaml 选择相关技能。它还规定了元认知问题和分析警告模式。
主要功能
- 01识别任务根本目的
- 02估算任务规模与类型
- 03按标签匹配技能
- 04生成元认知问题
- 05检测警告模式
适用场景
- 01为代码变更选择技能
- 02实施前分析任务范围
- 03判断是否需要计划或测试技能
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ shinpr/ claude-code-workflows --skill task-analyzer安装后在 Claude Code 中输入/task-analyzer确认已加载。
附带文件references/skills-index.yaml
详细介绍
任务分析器
提供元认知任务分析和技能选择指导。
技能索引
可用技能的元数据请参见 skills-index.yaml。
任务分析流程
1. 理解任务本质
识别表面工作背后的根本目的:
| 表面工作 | 根本目的 |
|---|---|
| “修复此错误” | 问题解决、根因分析 |
| “实现此功能” | 添加功能、交付价值 |
| “重构此代码” | 提升质量、增强可维护性 |
| “更新此文件” | 变更管理、保持一致性 |
操作:将用户请求映射到上方“表面工作 → 根本目的”表中的一行。如果没有匹配项,请先明确说明根本目的,再继续操作。
2. 估算任务规模
| 规模 | 文件数 | 指标 |
|---|---|---|
| 小 | 1-2 | 单个函数/组件变更 |
| 中 | 3-5 | 多个相关组件 |
| 大 | 6+ | 横切关注点、影响架构 |
规模会影响技能优先级:
- 规模 >= 大 → 将 documentation-criteria 的优先级设为 high,以遵循仓库针对 6+ 个文件的规划约定
- 规模 >= 大,且任务会改变可执行系统行为或需要依赖项/阶段策略 → 还要将 implementation-approach 的优先级设为 high
- 规模 >= 大,但任务属于研究、仅涉及文档或机械性工作 → 只有在确实需要制定实现策略时,才包含 implementation-approach
- 规模 = 小 → 仅选择任务类型必需的技能,最多选择 3 项;如果其他技能直接约束了明确提及的风险、语言或输出约定,则可超过 3 项
3. 确定任务类型
| 类型 | 特征 | 关键技能 |
|---|---|---|
| 实现 | 新代码、功能 | coding-principles、testing-principles |
| 修复 | 解决错误 | ai-development-guide、testing-principles |
| 重构 | 改进结构 | coding-principles、ai-development-guide |
| 设计 | 架构决策 | documentation-criteria、implementation-approach |
| 质量 | 测试、审查 | testing-principles、integration-e2e-testing |
4. 基于标签匹配技能
从任务描述中提取相关标签,并与 skills-index.yaml 匹配:
Task: "Implement user authentication with tests"
Extracted tags: [implementation, testing, security]
Matched skills:
- coding-principles (implementation, security)
- testing-principles (testing)
- ai-development-guide (implementation)
5. 隐含关系
考虑隐藏依赖关系:
| 任务涉及 | 还要包含 |
|---|---|
| 错误处理 | 调试、测试 |
| 新功能 | 设计、实现、文档 |
| 性能 | 性能分析、优化、测试 |
| 前端 | typescript-rules、test-implement |
| API/集成 | integration-e2e-testing |
输出格式
返回包含 skills-index.yaml 中技能元数据的结构化分析:
taskAnalysis:
essence: <string> # Fundamental purpose identified
type: <implementation|fix|refactoring|design|quality>
scale: <small|medium|large>
estimatedFiles: <number>
tags: [<string>, ...] # Extracted from task description
selectedSkills:
- skill: <skill-name> # From skills-index.yaml
priority: <high|medium|low>
reason: <string> # Why this skill was selected
# Pass through metadata from skills-index.yaml
tags: [...]
typical-use: <string>
size: <small|medium|large>
sections: [...] # All sections from yaml, unfiltered
注意:阅读实际的 SKILL.md 文件后,再选择相关章节。
使用方映射:rule-advisor 使用此中间结构,并负责最终的架构转换:将 type 转换为 taskType(quality → quality-improvement;其他值保持不变),将 tags 转换为 extractedTags,并在读取和提取所选技能的章节后,将 selectedSkills 转换为 selectedRules。将 metaCognitiveQuestions 保留为单独的最终字段,并根据下方的提问设计生成。
技能选择优先级
- 必需 - 与任务类型直接相关
- 质量 - 测试和质量保证
- 流程 - 工作流和文档
- 补充 - 参考资料和最佳实践
元认知问题设计
最多生成 5 个问题,这些问题的答案必须能够改变技能选择、验证方式或升级处理决策。如果没有任何问题会改变这些决策,则不生成问题。
| 任务类型 | 问题重点 |
|---|---|
| 实现 | 设计有效性、边界情况、性能 |
| 修复 | 根本原因(5 Whys)、影响范围、回归测试 |
| 重构 | 当前问题、目标状态、分阶段计划 |
| 设计 | 需求清晰度、未来可扩展性、权衡 |
警告模式
检测并标记以下模式:
| 模式 | 警告 | 缓解措施 |
|---|---|---|
| 检测到大型变更 | 配合 implementation-approach | 按策略拆分为多个阶段 |
| 检测到实现任务 | 配合 testing-principles | 从一开始就采用 TDD |
| 请求修复错误 | 配合 ai-development-guide | 修复前先应用 5 Whys |
| 多文件任务但没有计划 | 配合 documentation-criteria | 先制定工作计划 |
评论
支持 Markdown