Describe issue type and label taxonomy for slicing and triage

[dieterbaier]

Problem

When slice-issues decomposes a parent issue, it creates each child with only a
title and body — no issue type and no labels. Slices therefore can't be
filtered or triaged onto a project board without opening each one.
architecture-impact defines Epic vs UserStory, but nothing carries that
typing through to slices, and there is no shared, board-friendly label
convention.

Change

• Add skills/references/issue-labels.md — a reusable taxonomy:
  • type vocabulary: epic, user-story, task, refactoring, bug;
  • precedence for setting type: native issue type (gh --type, org-only) →
    type: label → title prefix ([EPIC]/[UserStory]);
  • independent label dimensions — type:, area:, and an optional project
    grouping (e.g. a roadmap phase-N label or a milestone);
  • keep workflow status in the board, not in labels;
  • gh issue create --type/--label/--parent examples.
• slice-issues — require reading the taxonomy, set --type/--label when
  creating each child, and add a slicing rule to type and label every slice.
• architecture-impact — point Epic/UserStory marking at the shared
  taxonomy.

Why

Derived from real use: creating roadmap Epics + sub-issues for a consuming
project surfaced that the slicing step gave no guidance on issue type or on the
labels needed to classify issues on a GitHub project board.

Notes

Engine-independent: the toolkit fixes the dimensions and precedence; a project
chooses concrete area:/grouping label names. GitHub issue types are org-only,
so personal repos fall back to type: labels — documented explicitly.

🤖 Generated with Claude Code

[dieterbaier]

Die Taxonomie ist als gemeinsame Referenz sinnvoll und die Trennung von Typ, Bereich, Gruppierung und Board-Status ist sauber. Ich habe einen operativen Widerspruch im slice-issues-Beispiel kommentiert: Die Taxonomie beschreibt native Issue Types und type:-Labels als alternative Fallback-Stufen, der Beispielbefehl und die Slicing-Regel verlangen aktuell beides gleichzeitig. Das kann auf persönlichen Repositories direkt scheitern und führt auf Org-Repositories zu einer unnötigen Doppelklassifikation.

[dieterbaier]

Hier widerspricht der ausführbare Beispielbefehl der Taxonomie: --type und <type-label> werden gleichzeitig verlangt, obwohl issue-labels.md sie als bevorzugte Alternative bzw. Fallback beschreibt. Auf persönlichen Repositories scheitert --type; auf Org-Repositories entsteht unnötig eine doppelte Typklassifikation. Bitte zwei explizite Varianten zeigen (native Type oder type:-Label) und in der Regel darunter ebenfalls klarstellen, dass genau eine Typ-Repräsentation verwendet wird – außer ein Projekt entscheidet bewusst, native Types zusätzlich für Board-Kompatibilität zu spiegeln. Außerdem sollte vor gh issue create geprüft bzw. festgelegt werden, dass die verwendeten Labels existieren, sonst schlägt das Slicing trotz korrekter Taxonomie fehl.

[dieterbaier]

Addressed: the slice-issues step 5 now shows two explicit variants — native --type (org repos) or a type: label (personal repos) — and both step 5 and the slicing rule state that exactly one type representation is used, never both. Matches the precedence in issue-labels.md.

[dieterbaier]

Nachprüfung abgeschlossen: Der bisherige Reviewpunkt ist sauber behoben. slice-issues zeigt jetzt zwei getrennte Erstellungsvarianten (native Issue Type oder type:-Label), fordert ausdrücklich genau eine Typ-Repräsentation und verweist weiterhin auf die Taxonomie, die das vorherige Anlegen der verwendeten Labels festlegt. Die CI ist grün. Ich habe keine weiteren Findings.