Skip to content

Add complexity classification to assess-ticket and as a standalone skill #370

Description

@williamthorsen

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:

  1. Resolve ticket source via the shared resolution table
  2. Identify the work surface — files, modules, APIs, dependencies mentioned or implied; verify against the codebase
  3. Assess cross-cutting extent — module/package count, boundary crossings, shared interfaces, downstream consumers
  4. Assess decision density — established patterns vs new patterns, design choices, new abstractions
  5. 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

  • classify-complexity/SKILL.md exists with frontmatter, investigation process, output template, and verdict mapping
  • assess-ticket/SKILL.md includes complexity as a fourth dimension: investigation section, output in both templates, mode argument, verdict reference table, emoji mapping
  • Complexity is investigated last in all mode
  • Complexity uses 🧩 icon and ⚪/🟢/🟠/🔴 verdict emojis
  • /classify-complexity output includes Scope, Drivers, and Risks sections (Risks always present)
  • No changes to the consumer thresholds table in complexity-classification.md

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions