Skill: Issue Labelling

Use when new issues come in and need categorisation. Applies consistent labels for type, priority, and component to keep the issue tracker organised.

Trigger

Invoke this skill when processing new issues, during triage sessions, or when the /triage command runs.

Label Taxonomy

Type Labels (exactly one required)

Priority Labels (exactly one for bugs and features)

Status Labels (applied as needed)

Component Labels (project-specific)

Define component labels based on the project's architecture. Examples:

• component: parser
• component: cli
• component: api
• component: ui

Decision Process

For each issue:

1. Read the full issue including any reproduction steps or screenshots.
2. Assign type — What category does this fall into?
3. Check for duplicates — Search closed and open issues for similar reports.
4. Assign priority — Based on impact and affected user count.
5. Assign component — Which part of the project is affected?
6. Check for first-issue suitability — Is the fix obvious, well-scoped, and achievable without deep project knowledge?
7. Determine next action — Needs info? Ready to work on? Needs discussion?

Rules

• Every issue must have exactly one type label.
• Bugs and features must have exactly one priority label.
• If unsure about priority, default to medium and note the uncertainty.
• Never apply good first issue to anything requiring architectural knowledge or touching more than 2 files.
• When marking as duplicate, always link the original issue and explain why it is a duplicate.
• Labels are not permanent — re-label if new information changes the categorisation.