Hugo Nijhuis
bbd7870483
Set explicit model preferences to optimize for speed vs capability: - haiku: 11 commands, 2 agents (issue-worker, pr-fixer), 10 skills Fast execution for straightforward tasks - sonnet: 4 commands (groom, improve, plan-issues, review-pr), 1 agent (code-reviewer) Better judgment for analysis and review tasks - opus: 2 commands (arch-refine-issue, arch-review-repo), 1 agent (software-architect) Deep reasoning for architectural analysis Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
101 lines
2.6 KiB
Markdown
101 lines
2.6 KiB
Markdown
---
|
|
name: backlog-grooming
|
|
model: haiku
|
|
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.
|
|
user-invocable: false
|
|
---
|
|
|
|
# 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 in description
|
|
- [ ] Dependencies formally linked (`tea issues deps list <number>`)
|
|
- [ ] No circular dependencies
|
|
- [ ] Blocking issues are tracked
|
|
|
|
To check/fix dependencies:
|
|
```bash
|
|
tea issues deps list <number> # View current dependencies
|
|
tea issues deps add <issue> <blocker> # Add missing dependency
|
|
tea issues deps remove <issue> <dep> # Remove incorrect dependency
|
|
```
|
|
|
|
### 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
|