Hugo Nijhuis
98796ba537
Updated all skill descriptions with proper trigger terms following the pattern: "What it does. Use when [trigger terms]." Skills updated: - code-review: triggers on PR review, code quality, bugs, security - issue-writing: triggers on creating issues, bug reports, features - backlog-grooming: triggers on grooming, reviewing issue quality - roadmap-planning: triggers on planning features, breaking down work Updated docs/writing-skills.md: - Added YAML frontmatter requirements section - Documented required and optional fields - Added guidance on writing effective descriptions - Updated "How Skills are Loaded" to reflect model-invoked behavior - Added note about subagent skill access - Updated checklist with frontmatter requirements - Added reference to official documentation 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
91 lines
2.2 KiB
Markdown
91 lines
2.2 KiB
Markdown
---
|
|
name: backlog-grooming
|
|
description: Review and improve existing issues for clarity and actionability. Use when grooming the backlog, reviewing issue quality, cleaning up stale issues, or when the user wants to improve existing issues.
|
|
---
|
|
|
|
# Backlog Grooming
|
|
|
|
How to review and improve existing issues.
|
|
|
|
## Grooming Checklist
|
|
|
|
For each issue, verify:
|
|
|
|
### 1. Title Clarity
|
|
- [ ] Starts with action verb
|
|
- [ ] Specific and descriptive
|
|
- [ ] Understandable without reading description
|
|
|
|
### 2. Description Quality
|
|
- [ ] Has clear summary
|
|
- [ ] Explains the "why"
|
|
- [ ] Provides enough context
|
|
|
|
### 3. Acceptance Criteria
|
|
- [ ] Criteria exist
|
|
- [ ] Each criterion is testable
|
|
- [ ] Criteria are specific (not vague)
|
|
- [ ] Complete set (nothing missing)
|
|
|
|
### 4. Scope
|
|
- [ ] Not too broad (can complete in reasonable time)
|
|
- [ ] Not too narrow (meaningful unit of work)
|
|
- [ ] Clear boundaries (what's included/excluded)
|
|
|
|
### 5. Dependencies
|
|
- [ ] Dependencies identified
|
|
- [ ] No circular dependencies
|
|
- [ ] Blocking issues are tracked
|
|
|
|
### 6. Labels
|
|
- [ ] Type label (bug/feature/etc)
|
|
- [ ] Priority if applicable
|
|
- [ ] Component labels if applicable
|
|
|
|
## Common Issues to Fix
|
|
|
|
### Vague Titles
|
|
- Bad: "Fix bug"
|
|
- Good: "Fix login form validation on empty email"
|
|
|
|
### Missing Acceptance Criteria
|
|
Add specific, testable criteria based on the description.
|
|
|
|
### Scope Creep
|
|
If issue covers multiple features, split into separate issues.
|
|
|
|
### Stale Issues
|
|
- Close if no longer relevant
|
|
- Update if context has changed
|
|
- Add "needs-triage" label if unclear
|
|
|
|
### Duplicate Issues
|
|
- Close duplicate with reference to original
|
|
- Merge relevant details into original
|
|
|
|
## Grooming Workflow
|
|
|
|
Use the gitea skill for issue operations.
|
|
|
|
1. **Fetch open issues**
|
|
2. **Review each issue** against checklist
|
|
3. **Improve or flag** issues that need work
|
|
4. **Update issue** with improvements
|
|
5. **Add labels** as needed
|
|
|
|
## Questions to Ask
|
|
|
|
When grooming, consider:
|
|
- "Could a developer start work on this today?"
|
|
- "How will we know when this is done?"
|
|
- "Is the scope clear?"
|
|
- "Are dependencies explicit?"
|
|
|
|
## Batch Grooming
|
|
|
|
When grooming multiple issues:
|
|
1. List all open issues
|
|
2. Categorize by quality (ready, needs-work, stale)
|
|
3. Focus on "needs-work" issues
|
|
4. Present summary of changes made
|