Make the local command label allowlist authoritative

Resolve conflicting label guidance by limiting the shared taxonomy's authority to issue classification labels and explicitly making this workflow's gh-* allowlist authoritative for command labels. This ensures the agent can suggest all current cli/cli command labels, including entries not yet documented in the shared taxonomy. Regenerate the compiled issue-triage workflow with gh-aw v0.87.5. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
sergiou87 · Sep 2, 2026 · Sep 2, 2026 · Sep 2, 2026 · Sep 2, 2026 · Sep 2, 2026
commit 6cdb7cb427f480a4fe1db56ee6347cfa68047e35
@@ -147,7 +147,10 @@ repository (main branch) using the GitHub file tools:
 2. `skills/issue-classifier/SKILL.md`
 3. `skills/issue-classifier/references/label-taxonomy.md`
 
-These are your primary triage instructions. Follow them exactly.
+These are your primary triage instructions. Follow them exactly for issue
+classification. For command labels, the local `gh-*` entries in the `add-labels`
+allowlist above are complete and authoritative; use them even when the shared taxonomy
+does not list them.
 
 ## Step 2: Read the issue
 
@@ -166,7 +169,8 @@ potential duplicates of this issue. Note your findings for the next step.
 ## Step 4: Classify the issue
 
 Follow the `issue-classifier` skill instructions. Use the `label-taxonomy` reference for
-valid labels. Incorporate your duplicate detection findings.
+issue type, priority, and status labels, and the local allowlist for command labels.
+Incorporate your duplicate detection findings.
 
 Assess the report independently. Treat the reporter's diagnosis, causal claims, and
 expected behavior as hypotheses rather than established facts. Separate direct