Context

Sub of #10214. See parent epic for architectural rationale. This ticket focuses on the implementation delta for Sub 2 — codifying the social contract for what happens when a non-maintainer-authored ticket arrives unlabeled.

The Problem

GitHub permissions enforce label-authority at the API layer: only maintainers (WRITE permission or higher) can call manage_issue_labels. Non-maintainer contributors and lower-privileged future agents can file tickets but can't apply labels. There is currently no agent-facing workflow for maintainer-side triage:

• A contributor files Fix X when Y without labels → the ticket enters the tracker unclassified
• ticket-create skill mandates ai + primary-label on agent-authored tickets, but doesn't cover the case where the author couldn't label
• No skill guides a maintainer agent (currently Opus / Gemini) through the triage decision (primary label + secondaries + assignment disposition)

The Architectural Reality

Two viable substrate designs:

• (A) Extend ticket-intake skill with a "triage-on-intake" branch — when an agent picks up an unlabeled ticket, apply labels as part of intake.
• (B) New ticket-triage skill — dedicated maintainer-facing workflow, distinct from intake (triage may happen without pickup — maintainer labels and leaves for contributor to claim).

(B) is structurally cleaner (triage ≠ intake; maintainer may triage without claiming) but adds a skill surface. (A) is lighter but conflates two distinct activities.

Recommendation for implementer: start with (B) as a new ticket-triage skill; cross-reference from ticket-intake ("if the ticket is unlabeled and you are a maintainer, consider running ticket-triage first").

The Fix

1. Create .agent/skills/ticket-triage/SKILL.md + references/ticket-triage-workflow.md.
2. Workflow structure:
   • Trigger: agent with maintainer permission encounters a ticket with no ai / no primary label.
   • Step 1: confirm the ticket passes ticket-create §2 Five-Stage Challenge retrospectively (premise/prescription/substrate/consumer/service-boundary). If it fails, post a review comment asking for clarification instead of labeling.
   • Step 2: apply primary label (bug / enhancement / epic) via manage_issue_labels add.
   • Step 3: apply secondary labels (architecture, performance, domain labels). Reference list_labels to avoid inventing names.
   • Step 4 (optional): assign if appropriate, OR leave unassigned + post a comment inviting the contributor to self-claim.
3. Cross-reference from ticket-intake §1 Validation Sweep — new sub-step: "if picking up an unlabeled ticket and you are a maintainer, run ticket-triage first."
4. AGENTS_STARTUP.md §9 Workflow skills list — add citation for the new ticket-triage skill.

Acceptance Criteria

• .agent/skills/ticket-triage/SKILL.md created
• .agent/skills/ticket-triage/references/ticket-triage-workflow.md codifies the four-step workflow + five-stage retrospective challenge
• Cross-reference from ticket-intake §1 Validation Sweep
• AGENTS_STARTUP.md §9 cites the new skill

Out of Scope

• Automatic label inference (ML classifier, keyword regex) — YAGNI; human/agent judgment is the correct substrate for label application
• Retroactive triage of historical unlabeled tickets — one-time migration; not a skill-level concern
• Changing the maintainer-permission gating itself — GitHub API handles it; this ticket codifies the workflow, not the permission model

Related

• Parent epic: #10214
• Sibling: ticket-create skill (authoring side)
• Sibling: ticket-intake skill (pickup side — this ticket adds a cross-reference)

Handoff Retrieval Hints

• query_raw_memories(query="ticket-triage skill maintainer label workflow contributor ticket")
• query_summaries(query="maintainer vs contributor label authority")

Known contributing sessions:

• ae546a40-2133-482f-85a6-779fdf6757b2 (epic authoring session)