work-item-creation

Required Checklist

Before creating ANY work item, verify:

1. Platform: Read .memory/board-config.md to identify GitHub or Azure DevOps
2. Duplicates: Check if a similar work item already exists on the board
3. Required tags/labels: all present (see section below)
4. Title in correct format: follow the Title section and check the outgoing title contains no invented sequential task or story identifier
5. Body filled in: per the platform format (see GitHub and Azure DevOps sections)
6. Hierarchy: parent linked correctly
7. Durable descriptions: body describes behavior using domain language, not implementation details (see Durability Rules below)
8. Content style: title and body follow the Content Style section below

Content Style

Work items live on the board, get rendered in GitHub/ADO UIs, and are read by humans and agents long after creation. Apply these rules to every title, description, comment, and acceptance criterion.

These rules apply to content sent to GitHub Issues, Azure DevOps work items, board comments, PR descriptions written from a work item, and triage artifacts. They do not replace the markdown rules in the documentation-style skill, which still govern files under docs/**/*.md.

AI Model Traceability

All generated work items must include the tag/label ai-model:<model-name>.

How to identify the model in use

1. Try reading Copilot CLI logs:

   grep -h "Using.*model" ~/.copilot/logs/*.log 2>/dev/null | tail -1

2. If not found, check config:

   cat ~/.copilot/config.json 2>/dev/null | grep -i model

3. If unable to identify, ask the user
4. Last resort: use ai-model:unknown

Required Tags/Labels (every work item)

Auto-creation of Labels (GitHub)

Before applying labels to a work item, check if they exist in the repository:

github/list_label(owner, repo)

If any required label does not exist, create it automatically via github/label_write:

Cache the list of existing labels to avoid repeated calls during the same creation session.

Tags/Labels by Type

User Stories

Tasks

Epics

Features

Missing ADRs

Tech Debt

Optional Labels

Title

• User Stories and Tasks: [<feature>] <description>
• Epics: [Epic] <name>
• Features: [Feature] <name>
• ADRs: [ADR] <domain> or [<feature>][ADR] <domain>
• Tech Debt: [Tech Debt] <description>

For GitHub and Azure DevOps, do not add sequential task or story identifiers such as T-1, T001, or US-01 to generated titles, including after the feature prefix. Do not copy local draft numbering into the title. The board supplies its own identity, and hierarchy and dependency links preserve relationships.

Keep meaningful domain numbers and versions, such as [pix] Support Pix API v2. Apply the title rule to newly generated work items without renaming existing board items as a cleanup.

Hierarchy

• Tasks are children of User Stories
• User Stories are children of Features
• Features are children of Epics
• Dependencies between tasks documented in the body or via links

Creation Order

1. User Stories first
2. Tasks second
3. Parent-child links third
4. Dependencies between tasks fourth

NEVER create duplicate work items. If a similar item already exists, skip it and record it in the report.

Durability Rules

Work items live longer than the code they reference. File paths, line numbers, and commit SHAs rot as the codebase evolves. Write descriptions that remain useful after major refactors.

Implementation-specific context (file paths, code snippets, stack traces) belongs in linked PRs, commits, and comments, not in the work item description.

Autonomy Classification

Classify each task to indicate whether it can be completed by an AI agent autonomously or requires human judgment.

Agent-autonomous (copilot-candidate)

Add copilot-candidate to tasks that meet ALL criteria:

• Low impact (no schema change, public API, or integration)
• Well-defined scope (specific files, clear behavior)
• Established pattern (follows existing code or ADR)
• No pending architectural decisions

Human-required (needs-human)

Add needs-human to tasks that meet ANY criteria:

• Requires architectural or design judgment not covered by an ADR
• Involves external system access, manual testing, or environment-specific verification
• Requires stakeholder input or approval (UX decisions, business rules, compliance)
• Touches security-sensitive code without an established pattern
• Cross-team coordination needed

Format by Platform

Read .memory/board-config.md to identify the platform, then read only the corresponding reference: