Describe issue type and label taxonomy for slicing and triage

skills/architecture-impact/SKILL.md

@@ -35,9 +35,10 @@ source of truth when these rules evolve.
    create or update an Epic. If it is small enough for one reviewable slice,
    create or update a UserStory. If the size is unclear and the decision affects
    issue structure, ask a short clarifying question before creating the issue.
-4. Mark Epics and UserStories in the remote project backlog. Use the
-   repository's Epic or UserStory issue type, label, or metadata when available;
-   otherwise prefix the issue title with `[EPIC]` or `[UserStory]`.
+4. Mark Epics and UserStories in the remote project backlog following the type
+   and label taxonomy in `../references/issue-labels.md`. Use the repository's
+   Epic or UserStory issue type, label, or metadata when available; otherwise
+   prefix the issue title with `[EPIC]` or `[UserStory]`.
 5. Start every Epic and UserStory description with the pattern
    `As a [Role], I want to [Action], so that [Benefit].`
 6. Assign each UserStory to a matching Epic when one exists. Prefer real

skills/references/issue-labels.md

@@ -0,0 +1,70 @@
+# Issue Type and Label Taxonomy
+
+Shared guidance for how backlog issues (Epics, UserStories, slices, refactorings)
+are typed and labelled so they are easy to find, filter, and classify — for
+example when triaging them into a project board.
+
+This is engine-independent guidance. It is referenced by
+`skills/architecture-impact/SKILL.md` (which decides Epic vs UserStory) and
+`skills/slice-issues/SKILL.md` (which creates the child slices). A consuming
+project adopts the taxonomy that fits its tooling; the toolkit only fixes the
+*dimensions* and the precedence, not a project's exact label names.
+
+## Issue type
+
+Every backlog issue has exactly one type. Set it with, in order of preference:
+
+1. A **native issue type** when the platform supports it
+   (`gh issue create --type <Type>`). GitHub issue types are currently an
+   organization-level feature; personal repositories usually cannot use them.
+2. Otherwise a **`type:` label** (see below).
+3. Otherwise a **title prefix** as a last resort (`[EPIC]`, `[UserStory]`,
+   `[REFACTORING]`), as described in `../architecture-impact/SKILL.md`.
+
+Recommended type vocabulary:
+
+| Type | Meaning |
+|------|---------|
+| `epic` | Coordination issue for work too large for one reviewable slice. |
+| `user-story` | A reviewable slice of user or stakeholder value. |
+| `task` | Technical work with no direct user-facing value (tooling, tests, docs, chores). |
+| `refactoring` | Internal change that does not alter observable behaviour. |
+| `bug` | Defect in existing behaviour. |
+
+Epics and UserStories still begin their description with
+`As a [Role], I want to [Action], so that [Benefit].` (see
+`../architecture-impact/SKILL.md`). Tasks and refactorings use a short goal
+statement plus acceptance criteria instead.
+
+## Label dimensions
+
+Apply labels along independent dimensions so a board can filter on each:
+
+- **Type** — `type:epic`, `type:user-story`, `type:task`, `type:refactoring`,
+  `type:bug` (mirror the native issue type as a label when the board cannot
+  filter on the native type). Exactly one.
+- **Area / domain** — `area:<name>` (for example `area:docs`, `area:testing`,
+  `area:observability`). One or more; project-defined.
+- **Grouping** — an optional project-defined grouping such as a roadmap phase or
+  a component, expressed as a label (`phase-4`) or a GitHub milestone. Optional.
+
+Keep **workflow status** (todo / in progress / done) in the project board, not
+in labels; labels describe what an issue *is*, the board describes where it *is*.
+
+Prefix labels by dimension (`type:`, `area:`) so they group and colour
+consistently and are unambiguous when several are applied at once.
+
+## Creating issues with type and labels
+
+```sh
+# Native type when available (org repos):
+gh issue create --type UserStory --label "area:testing,phase-4" \
+  --parent <epic> --title "<title>" --body-file <file>
+
+# Label-based type when native types are unavailable (personal repos):
+gh issue create --label "type:user-story,area:testing,phase-4" \
+  --parent <epic> --title "<title>" --body-file <file>
+```
+
+Create the `type:` and `area:` labels once per repository (for example with
+`gh label create`) so they exist before issues reference them.

skills/slice-issues/SKILL.md

@@ -15,21 +15,38 @@ acceptance criteria, branch, PR, and verification.
 This skill is GitHub-specific but engine-independent. Keep runtime-specific
 integration details in `adapters/`.
 
+## Required Reading
+
+- `../references/issue-labels.md` before creating child issues, to set each
+  slice's issue type and labels so the backlog and any project board can filter
+  them.
+
 ## Workflow
 
 1. Identify the parent issue number or URL.
 2. Read the parent issue body and comments before slicing.
 3. Check existing open issues to avoid duplicate slices.
 4. Decide whether the work should be split into sub-issues or kept in one PR
    with clearly separated commits.
-5. For each sliced task, create a child issue with GitHub's sub-issue support:
+5. For each sliced task, create a child issue with GitHub's sub-issue support,
+   setting its type and labels per `../references/issue-labels.md`. Use exactly
+   one type representation — a native issue type **or** a `type:` label, never
+   both:
 
    ```sh
-   gh issue create --parent <parent> --title "<title>" --body "<body>"
+   # Org repos with native issue types:
+   gh issue create --parent <parent> --title "<title>" --body-file <file> \
+     --type <Type> --label "<area>,<grouping>"
+
+   # Personal repos (native issue types unavailable) — carry the type as a label:
+   gh issue create --parent <parent> --title "<title>" --body-file <file> \
+     --label "<type-label>,<area>,<grouping>"
    ```
 
-   Use `--body-file` instead of `--body` when the body is multi-line or
-   contains Markdown that would be awkward to quote safely.
+   A slice is normally a `user-story` (a reviewable slice of value) or a `task`
+   (technical work with no direct user value). Use `--body-file` instead of
+   `--body` when the body is multi-line or contains Markdown that would be
+   awkward to quote safely.
 6. Comment on the parent issue with the created child issue links and the
    recommended implementation order.
 7. Report the created child issues and any fallback used.
@@ -39,6 +56,12 @@ integration details in `adapters/`.
 - Make each child issue independently reviewable and small enough for one
   focused PR.
 - Give each child issue a clear goal, scope, and acceptance criteria.
+- Give each child issue an explicit type and labels per
+  `../references/issue-labels.md` — exactly one type representation (a native
+  issue type or a `type:` label) plus `area:` and any project grouping such as a
+  roadmap phase — so it can be triaged onto a project board
+  without re-reading the body. Do not encode workflow status in labels; that
+  belongs to the board.
 - Preserve the parent issue as the coordination point.
 - Prefer dependency order over arbitrary numbering.
 - Keep implementation work out of the slicing step unless the user explicitly