# Task Analyzer

> This skill should be used when the user asks to "analyze a task", "route a command", "what craft command should I use", or describes a development task that needs routing to the appropriate craft workflow. Analyzes natural language task descriptions and maps them to optimal craft command sequences.

- Skill: `data-wise/task-analyzer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add data-wise/task-analyzer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/data-wise/task-analyzer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: Data-Wise (https://skillmd.com/u/data-wise)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/data-wise/task-analyzer

---


# Task Analyzer Skill

Expert in analyzing natural language task descriptions and routing to appropriate craft commands.

## When to Use

This skill is automatically activated when:

- User invokes `/craft:do <task>`
- User describes a development task
- Context suggests multi-step workflow needed

## Capabilities

### Intent Recognition (D5, 2026-07-04: canonical source — `/craft:do` references

this table instead of duplicating it; see `commands/do.md`'s Task Categories section)

Identifies task intent from natural language. Category names match `/craft:do`'s
routing categories exactly (renamed 2026-07-04 to eliminate a naming drift where this
table used different labels — Create/Fix/Document/Refactor/Review — for the same 7
concepts `/craft:do` already routes on as Feature/Bug/Docs/Architecture, plus a
missing **Quality** category `/craft:do` has and this table didn't):

| Intent | Keywords | Example |
|--------|----------|---------|
| **Feature** | add, create, implement, build, new | "add user authentication" |
| **Bug** | fix, debug, resolve, repair, issue, error | "fix the login bug" |
| **Quality** | lint, quality, clean, improve | "clean up the utils module" |
| **Test** | test, verify, check, validate, coverage | "test the api endpoints" |
| **Docs** | document, docs, readme, changelog, explain | "document the api" |
| **Release** | release, deploy, publish, ship | "prepare for release" |
| **Architecture** | design, refactor, restructure, review, audit, analyze | "refactor the utils module" |

**Judgment call made here:** the former standalone "Review" intent (review, audit,
analyze) had no corresponding category or command mapping in `/craft:do` at all — folded
its keywords into **Architecture** rather than inventing an 8th category `/craft:do`
would have no routing for.

### Domain Detection

Identifies affected domain from context:

| Domain | Indicators | Commands |
|--------|------------|----------|
| **API** | api, endpoint, rest, graphql | arch:plan, code:test-gen |
| **UI** | ui, component, page, view | frontend-designer skill |
| **Database** | db, database, model, schema | backend-designer skill |
| **Auth** | auth, login, permission | arch:plan, code:test-gen |
| **Testing** | test, coverage, spec | test, test --coverage |
| **Docs** | docs, readme, changelog | docs:sync, docs:validate |

### Workflow Selection

Maps intent + domain to optimal command sequence:

```
Feature Workflow:
  1. /craft:arch:plan     - Design the feature
  2. /craft:code:test-gen - Generate tests (TDD)
  3. dev/git skill        - Create feature branch (ask naturally; folded from /craft:git:branch)
  4. → Implementation     - User implements
  5. /craft:test          - Verify tests pass
  6. dev/git skill        - Commit/sync changes (ask naturally; folded from /craft:git:sync)

Bug Fix Workflow:
  1. /craft:code:debug    - Analyze the issue
  2. /craft:test debug    - Isolate in tests
  3. → Fix               - User implements fix
  4. /craft:test          - Verify fix
  5. dev/git skill        - Commit/sync changes (ask naturally; folded from /craft:git:sync)

Release Workflow:
  1. /craft:code:deps-audit  - Security scan
  2. /craft:test release     - Full test suite
  3. /craft:code:lint release - Comprehensive lint
  4. /craft:docs:changelog   - Update changelog
  5. /craft:code:release     - Release workflow
```

### Coded-Workflow Shape Detection (D7)

When a task description reads like a **fixed coded shape** —
decompose → cover N → verify M → synthesize — **suggest**
`/craft:orch:workflow`, do **not** silently switch to it.

Detect the shape conservatively (the helper
`workflow_parse.detects_workflow_shape(text)` fires only when ≥3 of the four
stage categories appear, or the explicit `decompose…synthesize` chain is
present):

| Stage category | Trigger words |
|----------------|---------------|
| decompose | decompose, break down, split into, dimensions, for each |
| fan-out | fan out, in parallel, one per, cover each, per finding, reviewers |
| verify | verify, verifier, double-check, confirm each |
| synthesize | synthesize, aggregate, summarize, combine, merge findings |

**Suggest, never switch (routing-false-positive guard).** A lone "verify" or
"in parallel" must NOT route anywhere — auto-hijacking a task better served by
improvised `orchestrate` is the accepted residual risk. On a match, present a
*suggestion* the user confirms:

```
This looks like a fixed decompose → cover → verify → synthesize shape.
Consider: /craft:orch:workflow (coded, schema-gated, resumable)
Or keep going with improvised orchestration. Which do you want?
```

| Input | Detected? | Action |
|-------|-----------|--------|
| "decompose into dimensions, review each in parallel, verify, synthesize" | yes | suggest `:workflow` |
| "fan out reviewers, verify findings, then summarize" | yes | suggest `:workflow` |
| "verify the login flow works" | no | route normally |
| "review the architecture" | no | route normally |

### Complexity Assessment

Determines task complexity for mode selection:

| Complexity | Indicators | Default Mode | Max Parallel Sessions |
|------------|------------|--------------|------------------------|
| **Simple** | Single file, quick fix | default | 5 |
| **Medium** | Few files, feature | default | 5 |
| **Complex** | Many files, architecture | debug | no cap |
| **Critical** | Release, security | release | no cap |

> Advisory only — `task-analyzer` is used for command routing, not dispatch-time
> enforcement. Nothing in `orchestrator-v2`/`craft:orch:workflow` reads this table
> or blocks a dispatch that exceeds it (see #327).

## Output Format

### Analysis Report

```
╭─ Task Analysis ─────────────────────────────────────╮
│ Input: "add user authentication"                   │
├─────────────────────────────────────────────────────┤
│ Intent: Feature                                    │
│ Domain: Authentication                             │
│ Complexity: Medium                                 │
│ Workflow: Feature Development                      │
├─────────────────────────────────────────────────────┤
│ Recommended Commands:                              │
│   1. /craft:arch:plan       Design auth system    │
│   2. /craft:code:test-gen   Generate auth tests   │
│   3. dev/git skill          Create feature/auth   │
╰─────────────────────────────────────────────────────╯
```

## Integration

Works with:

- `/craft:do` - Primary entry point
- `/craft:check` - Validation after workflows
- All category commands (code, test, arch, etc.)
- All design skills (backend, frontend, devops)

## Example Analyses

### Simple Task

```
Input: "fix typo in readme"
Analysis:
  - Intent: Bug
  - Domain: Documentation
  - Complexity: Simple
  - Command: Direct edit (no routing needed)
```

### Complex Task

```
Input: "implement oauth2 login with google"
Analysis:
  - Intent: Feature
  - Domain: Authentication + API
  - Complexity: Complex
  - Workflow: Feature Development
  - Skills: backend-designer, devops-helper
  - Commands: arch:plan → code:test-gen → git:branch
```