Codify ticket reality classification in ticket-intake

Context

After PRs #10533 and #10539 merged on 2026-05-01, @tobiu noted that the open backlog remains noisy: many tickets may be superseded, duplicated, or already resolved by PRs that did not close them correctly. A fresh live count immediately after those merges reported 265 open issues.

This ticket exists to harden the pickup-side workflow so agents do not treat ticket prose as authoritative truth. The existing ticket-intake skill already contains strong validation ingredients — remote truth fetch, Verify-Before-Assert, KB/memory checks, duplicate sweep, prescription challenge, ROI calculation, and rejection protocol — but it does not force a concise classification artifact before acceptance.

The Problem

Ticket-intake currently says an assigned ticket may be stale, duplicate active work, or architecturally wrong. It also says agents must validate the premise and reject Negative ROI work. What is missing is the explicit decision point that converts scattered checks into a stable verdict:

• Is this ticket still valid as written?
• Is it already resolved by merged code or docs?
• Is it superseded by a later ticket, epic, or architectural decision?
• Is it a duplicate?
• Does it need narrowing or native relinking before implementation?

Without a named classification step, agents can run several checks, find ambiguous evidence, and still drift into implementation because the workflow's output shape is not explicit enough.

Memory and current-session evidence reinforce the need:

• Current session guidance from @tobiu: challenge ticket content first against current repo reality.
• Memory hit 301d058e-9654-4ec8-8745-d784b2798057: swarm broadcast recommending classification as valid, already resolved, superseded, duplicate, needs narrowing, or needs relinking before branch/code work.
• Recent ticket precedent #10439 showed a ticket can become negative ROI after newer substrate decisions land; the right action was a closing/supersession comment, not implementation.

The Architectural Reality

Correct substrate: .agents/skills/ticket-intake/references/ticket-intake-workflow.md.

Why this belongs in ticket-intake:

• The issue is pickup-side execution discipline, not issue creation.
• The skill is invoked exactly when an agent is about to act on an existing ticket.
• The top-level SKILL.md router must stay lightweight per Progressive Disclosure; the payload reference is the right layer for the new rule.

Why this should NOT become a backlog-priority rule:

• @tobiu's recommendation to focus on what enables the team most is valuable portfolio guidance, but ticket-intake fires after a ticket is selected or assigned.
• Encoding team-enablement as a hard gate would make the skill reject otherwise valid tickets for the wrong reason.
• Team-enablement can inform ROI discussion, but it should not replace ticket reality classification.

The Fix

Update ticket-intake-workflow.md with a concise Ticket Reality Classification step inside the Validation Sweep, after remote truth / premise verification / history checks and before ROI acceptance.

The step should require agents to emit one of a small set of verdicts before branching or coding:

• valid-as-written
• already-resolved
• superseded
• duplicate
• needs-narrowing
• needs-relinking
• invalid-or-negative-roi

The workflow should route non-valid verdicts to the existing Rejection / human-in-the-loop protocol instead of implementation.

Acceptance Criteria

• ticket-intake-workflow.md contains an explicit Ticket Reality Classification step.
• The step requires checking current repo reality, including live issue conversation, linked PRs/commits, current source/docs/tests, and relevant memory/KB evidence where applicable.
• The step lists the allowed classification verdicts.
• The workflow states that only valid-as-written proceeds directly to Acceptance Protocol.
• needs-narrowing and needs-relinking halt implementation and require a comment or human clarification before branch/code work.
• already-resolved, superseded, duplicate, and invalid-or-negative-roi route to the existing rejection / re-triage path instead of implementation.
• The change does not add heavy content to .agents/skills/ticket-intake/SKILL.md; Progressive Disclosure router stays lightweight.

Out of Scope

• Adding a new skill. This is an existing-skill payload refinement.
• Creating an automated backlog sweeper for all open issues.
• Enforcing team-enablement as a hard priority rule in ticket-intake.
• Closing or labeling any existing tickets as part of this change.
• Changing the GitHub Workflow MCP sync pipeline.

Avoided Traps

• Trap: turn strategic portfolio advice into an intake hard gate. Rejected. Team-enablement is useful for selecting among valid work, but ticket-intake should decide whether the selected ticket is true and actionable.
• Trap: duplicate existing validation text with more prose. Rejected. The useful addition is a classification output, not another paragraph saying "validate carefully."
• Trap: create a new backlog-triage skill prematurely. Rejected. The immediate failure mode happens during pickup, and ticket-intake already owns that lifecycle moment.
• Trap: mutate the top-level SKILL.md router. Rejected per Progressive Disclosure; reference payload only.

Related

• #9969 — original ticket-intake skill scaffold.
• #9975 — pre-execution reflection / historical amnesia hardening.
• #10079 — broaden written-claim challenge in ticket-intake.
• #10159 / PR #10160 — precedent for integrating a missing predecessor check into ticket-intake after a skill interaction gap.
• #10216 — precedent for separating triage from intake when the lifecycle moment differs.

Origin Session ID: ce828999-cd17-4cc7-942b-93854a9bf795

Retrieval Hint: query_raw_memories(query="ticket intake challenge current repo reality superseded already resolved duplicate needs narrowing needs relinking")