task-analyzer
The task-analyzer skill provides metacognitive guidance for breaking down work requests and selecting appropriate Claude Code skills. Use it when facing ambiguous assignments, determining whether a task is small or large-scale, identifying whether work requires implementation versus refactoring versus design, and matching task characteristics to available skills through tag extraction and implicit dependency analysis.
git clone --depth 1 https://github.com/shinpr/claude-code-workflows /tmp/task-analyzer && cp -r /tmp/task-analyzer/dev-workflows-frontend/skills/task-analyzer ~/.claude/skills/task-analyzerSKILL.md
# Task Analyzer
Provides metacognitive task analysis and skill selection guidance.
## Skills Index
See **[skills-index.yaml](references/skills-index.yaml)** for available skills metadata.
## Task Analysis Process
### 1. Understand Task Essence
Identify the fundamental purpose beyond surface-level work:
| Surface Work | Fundamental Purpose |
|--------------|---------------------|
| "Fix this bug" | Problem solving, root cause analysis |
| "Implement this feature" | Feature addition, value delivery |
| "Refactor this code" | Quality improvement, maintainability |
| "Update this file" | Change management, consistency |
**Action**: Map the user request to one row in the Surface Work → Fundamental Purpose table above. If no row matches, state the fundamental purpose explicitly before proceeding.
### 2. Estimate Task Scale
| Scale | File Count | Indicators |
|-------|------------|------------|
| Small | 1-2 | Single function/component change |
| Medium | 3-5 | Multiple related components |
| Large | 6+ | Cross-cutting concerns, architecture impact |
**Scale affects skill priority:**
- Scale >= Large → include documentation-criteria and implementation-approach in selectedSkills with priority high
- Scale = Small → limit selectedSkills to task-type essential skills only (max 3)
### 3. Identify Task Type
| Type | Characteristics | Key Skills |
|------|-----------------|------------|
| Implementation | New code, features | coding-principles, testing-principles |
| Fix | Bug resolution | ai-development-guide, testing-principles |
| Refactoring | Structure improvement | coding-principles, ai-development-guide |
| Design | Architecture decisions | documentation-criteria, implementation-approach |
| Quality | Testing, review | testing-principles, integration-e2e-testing |
### 4. Tag-Based Skill Matching
Extract relevant tags from task description and match against skills-index.yaml:
```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. Implicit Relationships
Consider hidden dependencies:
| Task Involves | Also Include |
|---------------|--------------|
| Error handling | debugging, testing |
| New features | design, implementation, documentation |
| Performance | profiling, optimization, testing |
| Frontend | typescript-rules, test-implement |
| API/Integration | integration-e2e-testing |
## Output Format
Return structured analysis with skill metadata from skills-index.yaml:
```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
```
**Note**: Section selection (choosing which sections are relevant) is done after reading the actual SKILL.md files.
## Skill Selection Priority
1. **Essential** - Directly related to task type
2. **Quality** - Testing and quality assurance
3. **Process** - Workflow and documentation
4. **Supplementary** - Reference and best practices
## Metacognitive Question Design
Generate 3-5 questions according to task nature:
| Task Type | Question Focus |
|-----------|----------------|
| Implementation | Design validity, edge cases, performance |
| Fix | Root cause (5 Whys), impact scope, regression testing |
| Refactoring | Current problems, target state, phased plan |
| Design | Requirement clarity, future extensibility, trade-offs |
## Warning Patterns
Detect and flag these patterns:
| Pattern | Warning | Mitigation |
|---------|---------|------------|
| Large change detected | Pair with implementation-approach | Split into phases per strategy |
| Implementation task detected | Pair with testing-principles | Apply TDD from start |
| Error fix requested | Pair with ai-development-guide | Apply 5 Whys before fixing |
| Multi-file task without plan | Pair with documentation-criteria | Create work plan first |Generates integration/E2E test skeletons from Design Doc ACs using ROI-based selection and journey-based E2E reservation. Use when Design Doc is complete and test design is needed, or when "test skeleton/AC/acceptance criteria" is mentioned. Behavior-first approach for minimal tests with maximum coverage.
Validates Design Doc compliance and implementation completeness from third-party perspective. Use PROACTIVELY after implementation completes or when "review/implementation check/compliance" is mentioned. Provides acceptance criteria validation and quality reports.
Validates consistency between PRD/Design Doc and code implementation. Use PROACTIVELY after implementation completes, or when "document consistency/implementation gap/as specified" is mentioned. Uses multi-source evidence matching to identify discrepancies.
Analyzes existing codebase objectively for facts about implementation, user behavior patterns, and technical architecture. Use when existing code needs to be understood without hypothesis bias. Invoked before Design Doc creation to produce focused guidance for technical designers.
Detects conflicts across multiple Design Docs and provides structured reports. Use when multiple Design Docs exist, or when "consistency/conflict/sync/between documents" is mentioned. Focuses on detection and reporting only, no modifications.
Reviews document consistency and completeness, providing approval decisions. Use PROACTIVELY after PRD/UI Spec/Design Doc/work plan creation, or when "document review/approval/check" is mentioned. Detects contradictions and rule violations with improvement suggestions.
Verifies consistency between test skeleton comments and implementation code. Use PROACTIVELY after test implementation completes, or when "test review/skeleton verification" is mentioned. Returns quality reports with failing items and fix instructions.
Comprehensively collects problem-related information and creates evidence matrix. Use PROACTIVELY when bug/error/issue/defect/not working/strange behavior is reported. Reports only observations without proposing solutions.