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>
2.5 KiB
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,refactorpriority/high,priority/low- Component labels specific to project
Dependencies
Identify and link dependencies when creating issues:
-
In the description, document dependencies:
## Dependencies - Depends on #12 (must complete first) - Related to #15 (informational) -
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.