work-items:triage: routing step doesn't strip conflicting priority: labels before adding the default, allowing duplicate priority-axis values

[kyle-sexton]

This was generated by AI during triage.

Lane: triage. Category: behavioral.

Triggering example

#446 and #537 (both filed 2026-07-19, sat in the priority: needs-triage queue with a stale priority: high already attached from an earlier partial labeling pass) got a second priority: medium added on top via gh issue edit --add-label this cycle, leaving both labels present simultaneously until caught and corrected by hand mid-cycle. Every other item processed this session was clean (audited #605, #608, #610, #374-376, #497, #611, #619, #621 — no other conflicts).

Observed vs expected

Observed: the triage lane's routing step adds the default priority: medium via --add-label without first checking for (and stripping) any other priority: value already on the item, so a requeued/relabeled item can end up carrying two priority values on what the label taxonomy treats as a single-value axis.

Expected: before adding a priority label, read the item's current labels and remove any existing priority: label that isn't the one being set (mirrors how umbrella-fold and needs-human routing already strip priority: needs-triage first).

Category

behavioral — lane-rule gap, not a one-off typo; would recur on any future item that reaches the queue with a stale/conflicting priority label already attached.

[kyle-sexton]

This was generated by AI during triage.

Triage (umbrella-fold, corrected) — this is a 4th instance of #538's stated pattern ("lane prompts make the model re-do pure mechanics every cycle... what needs no reasoning gets a script"), not one of its three enumerated violations but the same root cause: label hygiene (strip conflicting priority: before adding the default) is deterministic mechanical work a script should own, proven by this session's #446/#537 miss where the model forgot to do it by hand. Folding rather than routing standalone per the umbrella-fold rule.

Blocked by #538's decision. Not routed to needs-human individually.

[kyle-sexton]

This was generated by AI during triage (historic normalization, rule 8g).

This finding is about the loop's own STANDING RULES text (pasted fresh into context on every /loop invocation), not a file in this repo — there is no script or skill in melodic-software/claude-code-plugins that implements "the triage lane's routing step"; the behavior described lives entirely in operator-maintained prompt text this lane cannot durably self-amend from inside a single cycle. Routing to a human for that reason (a process/location decision — does the fix belong in the operator's standing-rules template, or should the underlying work-items:triage skill in melodic-software/work-items gain this as a general best practice, or both), not because the described fix itself is unclear — both the priority-label-stripping and the umbrella+item-comment-atomicity fixes are already fully specified in the issue body.

[kyle-sexton]

Decision brief (human-operator lane). I do not decide, label, or close — this is one brief with RECOMMENDED options for the operator.

Problem (2 sentences)

The triage routing step adds the default priority: * label via --add-label without first stripping any conflicting priority: value already on the item, so a requeued/relabeled item ends up carrying two values on a single-value axis (observed on #446 and #537). The open question is not what the fix is (the issue specifies it) but where it belongs — the operator's standing-rules /loop prompt, the work-items:triage skill, or both.

What's verified (this changes the earlier routing rationale)

• The work-items:triage skill DOES live in this repo, at plugins/work-items/skills/triage/SKILL.md. The 2026-07-20 comment above stated it "lives in melodic-software/work-items" and that "there is no script or skill in this repo that implements the triage routing step" — both are incorrect. There is no standalone melodic-software/work-items repo in the org (org repo listing shows only ci-workflows matching *work*); the plugin is authored in-repo (plugins/work-items/README.md: "A Claude Code plugin…").
• That skill file is locally-owned, not an upstream-synced materialization. standards/distribution/sync-manifest.yml lists claude-code-plugins as a sync target, but its managed components are all lint/CI tooling (agent-orientation, gitleaks, markdownlint, typos, …) — work-items is not among them. So editing the SKILL.md here is a normal locally-owned change via PR, not an upstream sync PR.
• The skill already implements the analogous hygiene rule — for the raw marker only. SKILL.md lines 120 and 144 mandate that applying any routing outcome replaces the needs-triage raw marker rather than stacking on it ("resolved from the live set … normalization replaces the raw marker, it never adds to it"). It assigns priority (line 95) but does not generalize that single-value-axis strip to the priority: axis. That missing generalization is exactly work-items:triage: routing step doesn't strip conflicting priority: labels before adding the default, allowing duplicate priority-axis values #632's gap.
• Live priority labels are priority: low|medium|high|critical|needs-triage; the SKILL.md prose names a priority:pN-… set. This is likely just config drift (the skill is explicitly config-driven, "resolved from the live set"), not proof the loop is independent of the skill — treat as ambiguous, noted for whoever writes the fix.

Scope check + overlap with #633 (correction)

• work-items:triage: routing step doesn't strip conflicting priority: labels before adding the default, allowing duplicate priority-axis values #632's body covers the label-strip issue ONLY. It does not describe the umbrella+item-comment atomicity concern.
• The earlier comment's claim that "both the priority-label-stripping and the umbrella+item-comment-atomicity fixes are already fully specified in the issue body" conflates work-items:triage: routing step doesn't strip conflicting priority: labels before adding the default, allowing duplicate priority-axis values #632 with work-items:triage: umbrella-fold routing misses the umbrella-side membership comment (item-side only, 3x this session) #633. The atomicity fix is specified in work-items:triage: umbrella-fold routing misses the umbrella-side membership comment (item-side only, 3x this session) #633's body ("umbrella-fold routing misses the umbrella-side membership comment"), a separate issue. Both fold into loops: script the deterministic lane mechanics — machine-behavior block, #502 telemetry upsert, wire script-the-deterministic-work into prompt ritual #538's "deterministic mechanics" class, but they are distinct findings — resolve the where question here for the label-strip only; work-items:triage: umbrella-fold routing misses the umbrella-side membership comment (item-side only, 3x this session) #633 owns atomicity.

The real (b)-vs-(c) discriminator (unverifiable from the repo)

Whether a skill-only fix actually stops the recurrence depends on whether the operator's per-cycle /loop invokes work-items:triage or runs its own prompt copy of the routing step. The /loop standing-rules text is operator-maintained and not in this repo, so this coupling can't be verified here. It decides how much of the fix the skill can carry.

Options

(c) Both — durable skill fix + interim prompt mitigation — RECOMMENDED

Generalize SKILL.md's existing raw-marker single-value rule (lines 120/144) to the whole priority: axis ("before adding a priority: label, strip any other live-set priority: value"), landed as a locally-owned PR here; and add the same one-line strip to the operator's standing-rules prompt as immediate mitigation for the next cycle.

• Why first: the skill is the durable root-cause home and is editable here today; the prompt layer is where the buggy --add-label demonstrably executed this cycle, so it gives coverage before the PR merges. Honest default while loop↔skill coupling is unverified.
• Tradeoffs: two edits; slight duplication risk — the prompt line should be removed once the skill PR lands (and once the operator confirms the loop derives from the skill) to avoid drift. Collapses cleanly to (b).
• Reversibility: high — prompt text and a single-file PR both trivially revertible.

(b) Skill only

Same SKILL.md generalization, no prompt change.

• Tradeoffs: cleanest single source of truth; benefits every consumer of the skill. But it stops the observed recurrence only if the /loop actually invokes the skill — unverified. Leaves a gap until the PR merges.
• Reversibility: high (single-file revert). Prefer this once the operator confirms the loop invokes work-items:triage.

(a) Operator prompt only

Add the strip to the standing-rules template; skill untouched.

• Tradeoffs: fastest, zero repo change — but leaves the durable skill contract silent, so any other consumer/session using work-items:triage stays exposed, and the fix lives only in operator-local text no reviewer sees. Treats a symptom, not the root cause.
• Reversibility: high, but lowest durability.

---

Confidence: skill location, local-ownership, and the #632/#633 conflation are verified against the repo and sync-manifest. The loop↔skill coupling and the operator prompt's contents are the only unverifiable inputs, and the RECOMMENDED option is chosen to be safe under that uncertainty.