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

packages/agents/content/skills/assess-ticket/SKILL.md

@@ -1,19 +1,19 @@
 ---
 name: assess-ticket
-description: Assess a ticket against the current codebase for drift, relevance, and progress
+description: Assess a ticket against the current codebase for drift, relevance, progress, and complexity
 user-invocable: true
 ---
 
 # Assess ticket
 
-Assess a ticket's relationship to the current codebase. Produces a structured assessment with constrained verdicts and supporting evidence.
+Assess a ticket against the current codebase across four dimensions: drift, relevance, progress, and complexity. Produces a structured assessment with constrained verdicts and supporting evidence.
 
 **Announce at start:** "Using assess-ticket to assess {ticket reference} (mode: {mode})."
 
 ## Arguments
 
 - **Ticket source** (optional): issue URL, shorthand reference (`#99`, `issue 99`), file path, or plain text. When omitted, auto-resolved from the environment (see [ticket source resolution](../_data/ticket-source-resolution.md#auto-resolve)).
-- **Mode** (optional): `drift`, `relevance`, `progress`, or `all` (default: `all`)
+- **Mode** (optional): `drift`, `relevance`, `progress`, `complexity`, or `all` (default: `all`)
 
 ## Process
 
@@ -23,7 +23,7 @@ Resolve the ticket source using the [ticket source resolution](../_data/ticket-s
 
 ### 2. Investigate
 
-Run the investigation for the requested mode (or all modes in order when mode is `all`).
+Run the investigation for the requested mode (or all modes in order when mode is `all`). When mode is `all`, complexity is investigated last so it benefits from context gathered during drift, relevance, and progress analysis.
 
 #### Drift
 
@@ -79,9 +79,25 @@ Determine whether the described work has been implemented. The output format ada
 - 🟠 `partial` — some of the described work has been done but significant portions remain
 - 🔴 `none` — none of the described work is present in the codebase
 
+#### Complexity
+
+Classify how complex the described work is relative to the current codebase. Reference the [complexity classification](../_data/complexity-classification.md) rubric for level definitions.
+
+1. Identify the work surface — files, modules, packages, APIs, interfaces, and dependencies that the ticket describes changing or creating. Verify against the codebase.
+2. Assess cross-cutting extent — how many modules or packages are touched, whether changes cross package boundaries, and whether shared interfaces or data structures are affected.
+3. Assess decision density — whether the work follows established patterns or requires new ones, and whether design choices could go multiple ways.
+4. Classify against the rubric. When characteristics span two levels, prefer the higher level.
+
+**Verdicts:**
+
+- ⚪ `trivial` — single-line or purely mechanical; no judgment needed
+- 🟢 `mechanical` — follows an obvious pattern; single module, no API or behavioral changes
+- 🟠 `involved` — requires understanding context; touches multiple files or modules; may involve design decisions
+- 🔴 `architectural` — cross-cutting concerns, new patterns, dependency boundary changes, or far-reaching consequences
+
 ### 3. Output
 
-Format the assessment using the structure below. When a single mode is requested, output only that dimension's section (with the header and provenance line). When mode is `all`, output all three dimensions in order.
+Format the assessment using the structure below. When a single mode is requested, output only that dimension's section (with the header and provenance line). When mode is `all`, output all four dimensions in order.
 
 Obtain the base SHA via `git rev-parse --short HEAD`.
 
@@ -107,6 +123,11 @@ Assessed at {YYYYMMDD-HHMMSSZ} against {short SHA}
 - [x] {Criterion met}
 - [x] {Criterion met}
 - [ ] {Criterion not met}
+
+🧩 **Complexity:** {emoji} `{label}`
+
+- {Evidence bullet}
+- {Evidence bullet}
 ```
 
 **When the ticket has no acceptance criteria:**
@@ -128,25 +149,42 @@ Assessed at {YYYYMMDD-HHMMSSZ} against {short SHA}
 
 📶 **Progress:** {emoji} `{verdict}`
 
+- {Evidence bullet}
+- {Evidence bullet}
+
+🧩 **Complexity:** {emoji} `{label}`
+
 - {Evidence bullet}
 - {Evidence bullet}
 ```
 
 ### Emoji mapping
 
+Drift, relevance, and progress use a **concern scale** — green means no concern, red means high concern:
+
 | Verdict position | Emoji |
 | ---------------- | ----- |
 | No concern       | 🟢    |
 | Mixed / unclear  | 🟠    |
 | High concern     | 🔴    |
 
+Complexity uses a **size scale** — emojis represent effort and scope, not concern:
+
+| Level | Emoji |
+| ----- | ----- |
+| 1     | ⚪    |
+| 2     | 🟢    |
+| 3     | 🟠    |
+| 4     | 🔴    |
+
 ### Verdict reference
 
-| Dimension     | 🟢         | 🟠          | 🔴           |
-| ------------- | ---------- | ----------- | ------------ |
-| **Drift**     | `none`     | `partial`   | `severe`     |
-| **Relevance** | `relevant` | `uncertain` | `superseded` |
-| **Progress**  | `complete` | `partial`   | `none`       |
+| Dimension      | ⚪        | 🟢           | 🟠          | 🔴              |
+| -------------- | --------- | ------------ | ----------- | --------------- |
+| **Drift**      | —         | `none`       | `partial`   | `severe`        |
+| **Relevance**  | —         | `relevant`   | `uncertain` | `superseded`    |
+| **Progress**   | —         | `complete`   | `partial`   | `none`          |
+| **Complexity** | `trivial` | `mechanical` | `involved`  | `architectural` |
 
 ## Key principles
 

packages/agents/content/skills/classify-complexity/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: classify-complexity
+description: Classify a ticket's complexity against the current codebase using the 4-level rubric
+user-invocable: true
+---
+
+# Classify complexity
+
+Classify a ticket's complexity by examining the described work against the current codebase. Produces a structured assessment with a verdict, scope breakdown, drivers, and risks.
+
+**Announce at start:** "Using classify-complexity to classify {ticket reference}."
+
+## Arguments
+
+- **Ticket source** (optional): issue URL, shorthand reference (`#99`, `issue 99`), file path, or plain text. When omitted, auto-resolved from the environment (see [ticket source resolution](../_data/ticket-source-resolution.md#auto-resolve)).
+
+## Process
+
+### 1. Resolve ticket source
+
+Resolve the ticket source using the [ticket source resolution](../_data/ticket-source-resolution.md) table. Store the resolved metadata (platform, repo, issue number, ticket content).
+
+### 2. Identify the work surface
+
+Extract from the ticket what needs to change:
+
+- Files, modules, and packages mentioned or implied
+- New files or directories that need to be created
+- APIs, interfaces, or data structures that are added or modified
+- Dependencies that are added, removed, or changed
+
+Verify against the codebase — the ticket may reference things that have moved or no longer exist.
+
+### 3. Assess cross-cutting extent
+
+- How many modules or packages are touched?
+- Do changes cross package boundaries?
+- Are shared interfaces, types, or data structures affected?
+- Are there downstream consumers that need updating?
+
+### 4. Assess decision density
+
+- Does the work follow an established pattern, or does it require new patterns?
+- Are there design choices that could go multiple ways?
+- Does the work introduce new abstractions, interfaces, or module boundaries?
+
+### 5. Classify
+
+Map the findings to the [complexity classification](../_data/complexity-classification.md) rubric. When characteristics span two levels, prefer the higher level.
+
+### 6. Output
+
+Obtain the base SHA via `git rev-parse --short HEAD`.
+
+```markdown
+## Complexity: {ticket title} (#{number})
+
+Assessed at {YYYYMMDD-HHMMSSZ} against {short SHA}
+
+🧩 **Complexity:** {emoji} `{label}`
+
+### Scope
+
+- **Modules affected:** {list of modules or packages touched}
+- **New files:** {count and brief description, or "None"}
+- **Modified files:** {count and brief description}
+
+### Drivers
+
+- {What pushes the classification to this level}
+- {Key factor}
+
+### Risks
+
+- {Known unknowns or complications, or "None identified"}
+```
+
+## Verdict mapping
+
+| Level | Label           | Emoji |
+| ----- | --------------- | ----- |
+| 1     | `trivial`       | ⚪    |
+| 2     | `mechanical`    | 🟢    |
+| 3     | `involved`      | 🟠    |
+| 4     | `architectural` | 🔴    |
+
+## Key principles
+
+- **Evidence over opinion** — every classification must cite specific codebase evidence (file paths, module counts, dependency references)
+- **Prefer the higher level** — when characteristics span two levels, classify at the higher one
+- **No action, just assessment** — this skill produces output; it does not modify tickets, save artifacts, or post comments
+- **Scale to ticket complexity** — a simple ticket gets a brief assessment; a complex ticket with many moving parts gets a thorough one