---
name: complexity-assess
description: Use when evaluating how complex a task is before deciding on an approach. Scores scope, clarity, risk, and novelty to produce a complexity tier (trivial, moderate, complex). Use this whenever the user asks how hard something is, wants a complexity check, or before starting unfamiliar work.
---

# Complexity Assessment

Evaluate a task's complexity using a structured heuristic. This is a pure analysis skill — it reports a tier and rationale but does NOT execute anything.

## Process

1. **Read the task description** — what the user wants to accomplish
2. **Explore the codebase** — grep for relevant terms, read related files, understand what's involved. When invoked from `task-start`, exploration has already been done — use those findings directly rather than re-exploring.
3. **Score each dimension** (see heuristic below) with a one-line justification
4. **Report the tier** and recommended approach

## Heuristic

Score each dimension 1-3:

### Scope — How many files and modules are affected?

- **1**: 1-3 files in one module
- **2**: 4-15 files or 2-3 modules
- **3**: 15+ files or 4+ modules or new module creation

### Clarity — How specific is the task?

- **1**: Exact file, function, or error referenced
- **2**: Clear goal, but approach needs figuring out
- **3**: Vague goal, significant design decisions needed

### Risk — What breaks if this goes wrong?

- **1**: Isolated, easily reversible
- **2**: Touches shared code or has moderate blast radius
- **3**: Auth, payments, data integrity, or public API changes

### Novelty — Has the codebase done this before?

- **1**: Pattern already exists, just replicate
- **2**: Extends existing patterns in new directions
- **3**: No precedent in the codebase

## Tiers

| Total Score | Tier | Meaning |
|-------------|------|---------|
| 4-5 | **Trivial** | Straightforward — just do it |
| 6-8 | **Moderate** | Multi-step — break it down and work through sequentially |
| 9-12 | **Complex** | Significant — plan first, then execute phase by phase |

## Output Format

```
## Complexity: <TIER> (score: <N>/12)

| Dimension | Score | Rationale |
|-----------|-------|-----------|
| Scope     | <1-3> | <one line> |
| Clarity   | <1-3> | <one line> |
| Risk      | <1-3> | <one line> |
| Novelty   | <1-3> | <one line> |

Recommended: <one-line approach based on tier>
```

## Rules

- Always explore the codebase before scoring — don't guess from the task description alone
- Be honest about uncertainty — if you can't determine scope without deeper exploration, that itself suggests higher complexity
- Scores should reflect the actual codebase state, not abstract difficulty
- This skill can be invoked standalone ("how complex would X be?") or as part of `task-start`