Add complexity classification to assess-ticket and as a standalone skill
Problem
/assess-ticket evaluates drift, relevance, and progress but not complexity. Complexity answers "how should I approach it?", which is a natural companion question. The complexity-classification rubric (levels 1–4) already exists and is consumed by wrap-up, next-steps-after-plan, and next-steps-after-review, but only after planning or review. Knowing complexity before starting would help choose the right workflow upfront.
Context
- The 4-level rubric lives in
_data/complexity-classification.md and is already referenced by three consumer skills
assess-ticket has three existing dimensions (drift, relevance, progress) that follow a consistent pattern: investigation steps, verdict table, structured output
- Complexity uses a size scale (⚪/🟢/🟠/🔴), not the concern scale (🟢/🟠/🔴) used by the other dimensions
- The standalone skill and the assess-ticket dimension are independent — no delegation. Both reference the shared rubric. assess-ticket may arrive at a slightly more accurate classification because it has context from the other dimensions.
Solution
1. Create /classify-complexity skill
A standalone, user-invocable skill at content/skills/classify-complexity/SKILL.md. Takes the same ticket-source arguments as assess-ticket.
Investigation process:
- Resolve ticket source via the shared resolution table
- Identify the work surface — files, modules, APIs, dependencies mentioned or implied; verify against the codebase
- Assess cross-cutting extent — module/package count, boundary crossings, shared interfaces, downstream consumers
- Assess decision density — established patterns vs new patterns, design choices, new abstractions
- Classify against the rubric; prefer the higher level when characteristics span two
Output format: Header with provenance, verdict line, then three sections: Scope, Drivers, Risks (always present, even when "None identified").
Verdict mapping:
| Level |
Label |
Emoji |
| 1 |
trivial |
⚪ |
| 2 |
mechanical |
🟢 |
| 3 |
involved |
🟠 |
| 4 |
architectural |
🔴 |
Dimension icon: 🧩
2. Add complexity dimension to assess-ticket
Add complexity as a fourth dimension, investigated and displayed last (after progress). Include in the all default mode. Add complexity to the mode argument list.
Same investigation approach as the standalone skill, defined independently. Terse output consistent with the other dimensions (verdict line + evidence bullets).
The emoji mapping table needs a separate note for complexity since it uses a size scale, not the concern scale of the other dimensions.
Acceptance criteria
Add complexity classification to assess-ticket and as a standalone skill
Problem
/assess-ticketevaluates drift, relevance, and progress but not complexity. Complexity answers "how should I approach it?", which is a natural companion question. The complexity-classification rubric (levels 1–4) already exists and is consumed bywrap-up,next-steps-after-plan, andnext-steps-after-review, but only after planning or review. Knowing complexity before starting would help choose the right workflow upfront.Context
_data/complexity-classification.mdand is already referenced by three consumer skillsassess-tickethas three existing dimensions (drift, relevance, progress) that follow a consistent pattern: investigation steps, verdict table, structured outputSolution
1. Create
/classify-complexityskillA standalone, user-invocable skill at
content/skills/classify-complexity/SKILL.md. Takes the same ticket-source arguments asassess-ticket.Investigation process:
Output format: Header with provenance, verdict line, then three sections: Scope, Drivers, Risks (always present, even when "None identified").
Verdict mapping:
trivialmechanicalinvolvedarchitecturalDimension icon:
🧩2. Add complexity dimension to
assess-ticketAdd
complexityas a fourth dimension, investigated and displayed last (after progress). Include in thealldefault mode. Addcomplexityto the mode argument list.Same investigation approach as the standalone skill, defined independently. Terse output consistent with the other dimensions (verdict line + evidence bullets).
The emoji mapping table needs a separate note for complexity since it uses a size scale, not the concern scale of the other dimensions.
Acceptance criteria
classify-complexity/SKILL.mdexists with frontmatter, investigation process, output template, and verdict mappingassess-ticket/SKILL.mdincludes complexity as a fourth dimension: investigation section, output in both templates, mode argument, verdict reference table, emoji mappingallmode🧩icon and ⚪/🟢/🟠/🔴 verdict emojis/classify-complexityoutput includes Scope, Drivers, and Risks sections (Risks always present)complexity-classification.md