Lane: triage · Category: behavioral (scope-definition gap)
Triggering example
2026-07-19 triage loop cycle. The needs-triage queue held 7 issues (#459, #475, #477, #478, #479, #480, #481), all authored by the team's own members and filed by the skill's own self-observation / dogfood rule ("file every distinct problem/improvement you notice as an issue … label priority: needs-triage"). They carried only priority: needs-triage, so they correctly surfaced in the attention-view queue and genuinely needed triage (priority normalization, tier routing, plan drafting).
But the triage SKILL.md "Scope: raw intake only" section defines the flow's input as:
raw intake — items the team did not author (bug reports, incoming feature requests, unsolicited PRs)
By that prose, team-authored dogfood issues are out of scope — yet they are exactly what the queue contains and what the lane exists to triage.
Observed vs expected
- Observed: two skill statements are in tension. (1) Scope says raw intake = "items the team did not author." (2) The same plugin ships a self-observation rule that has the team author
priority: needs-triage issues, plus an attention view that surfaces every priority: needs-triage item regardless of author. An operator reading the scope prose literally would exclude the very items the queue is built from.
- Expected: the scope definition keys on triage state, not authorship — an item is raw intake if it is untriaged (unlabeled or
status: needs-triage / priority: needs-triage), whoever authored it. The "did not author" phrasing should become an illustrative list of common raw-intake sources, not the defining boundary. The real exclusion the section wants is "never re-triage already-triaged output" (decompose / track add items born with classification labels), which is authorship-independent and already stated separately.
Category
bug (behavioral/definitional) — the scope prose contradicts the plugin's own self-observation rule and attention-view construction.
Note
Distinct from #459 (wait-gate vs autonomous mutation), #478 (routing-rule absorption), and #449 (no-local-checkout mode). This is specifically the authorship-based scope boundary excluding legitimately-queued team-authored intake.
Lane: triage · Category: behavioral (scope-definition gap)
Triggering example
2026-07-19 triage loop cycle. The needs-triage queue held 7 issues (#459, #475, #477, #478, #479, #480, #481), all authored by the team's own members and filed by the skill's own self-observation / dogfood rule ("file every distinct problem/improvement you notice as an issue … label
priority: needs-triage"). They carried onlypriority: needs-triage, so they correctly surfaced in the attention-view queue and genuinely needed triage (priority normalization, tier routing, plan drafting).But the triage
SKILL.md"Scope: raw intake only" section defines the flow's input as:By that prose, team-authored dogfood issues are out of scope — yet they are exactly what the queue contains and what the lane exists to triage.
Observed vs expected
priority: needs-triageissues, plus an attention view that surfaces everypriority: needs-triageitem regardless of author. An operator reading the scope prose literally would exclude the very items the queue is built from.status: needs-triage/priority: needs-triage), whoever authored it. The "did not author" phrasing should become an illustrative list of common raw-intake sources, not the defining boundary. The real exclusion the section wants is "never re-triage already-triaged output" (decompose /track additems born with classification labels), which is authorship-independent and already stated separately.Category
bug (behavioral/definitional) — the scope prose contradicts the plugin's own self-observation rule and attention-view construction.
Note
Distinct from #459 (wait-gate vs autonomous mutation), #478 (routing-rule absorption), and #449 (no-local-checkout mode). This is specifically the authorship-based scope boundary excluding legitimately-queued team-authored intake.