Files
architecture/skills/issue-writing/SKILL.md
Hugo Nijhuis ff56168073 Mark skills as not user-invocable
Skills are knowledge modules referenced by commands, not
directly invoked by users. Added user-invocable: false to:
- backlog-grooming (used by /groom)
- claude-md-writing (used by /update-claude-md)
- code-review (used by /review-pr)
- issue-writing (used by /create-issue)
- roadmap-planning (used by /plan-issues)
- vision-management (used by /vision, /manifesto)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-09 13:01:19 +01:00

2.5 KiB

name, description, user-invocable
name description user-invocable
issue-writing Write clear, actionable issues with proper structure and acceptance criteria. Use when creating issues, writing bug reports, feature requests, or when the user needs help structuring an issue. false

Issue Writing

How to write clear, actionable issues.

Issue Structure

Title

  • Start with action verb: "Add", "Fix", "Update", "Remove", "Refactor"
  • Be specific: "Add user authentication" not "Auth stuff"
  • Keep under 60 characters when possible

Description

## Summary
One paragraph explaining what and why.

## Acceptance Criteria
- [ ] Specific, testable requirement
- [ ] Another requirement
- [ ] User can verify this works

## Context
Additional background, links, or references.

## Technical Notes (optional)
Implementation hints or constraints.

Writing Acceptance Criteria

Good criteria are:

  • Specific: "User sees error message" not "Handle errors"
  • Testable: Can verify pass/fail
  • User-focused: What the user experiences
  • Independent: Each stands alone

Examples:

- [ ] Login form validates email format before submission
- [ ] Invalid credentials show "Invalid email or password" message
- [ ] Successful login redirects to dashboard
- [ ] Session persists across browser refresh

Issue Types

Bug Report

## Summary
Description of the bug.

## Steps to Reproduce
1. Go to...
2. Click...
3. Observe...

## Expected Behavior
What should happen.

## Actual Behavior
What happens instead.

## Environment
- Browser/OS/Version

Feature Request

## Summary
What feature and why it's valuable.

## Acceptance Criteria
- [ ] ...

## User Story (optional)
As a [role], I want [capability] so that [benefit].

Technical Task

## Summary
What technical work needs to be done.

## Scope
- Include: ...
- Exclude: ...

## Acceptance Criteria
- [ ] ...

Labels

Use labels to categorize:

  • bug, feature, enhancement, refactor
  • priority/high, priority/low
  • Component labels specific to project

Dependencies

Identify and link dependencies when creating issues:

  1. In the description, document dependencies:

    ## Dependencies
    - Depends on #12 (must complete first)
    - Related to #15 (informational)
    
  2. After creating the issue, formally link blockers using tea CLI:

    tea issues deps add <this-issue> <blocker-issue>
    tea issues deps add 5 3    # Issue #5 is blocked by #3
    

This creates a formal dependency graph that tools can query.