Grooming
Cat-grade engineering skills for coding agents. Spec → tickets → TDD in worktrees, plus repo hygiene. No slop.
npx -y skills add ai-meow/felix-skills --skill groomingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 20 days oldThe repository was created 20 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Slice a spec into GitHub issues and sub-issues. Takes a docs/specs/*.md file (or the current conversation) and produces vertically-sliced tickets via the gh CLI, each carrying its slice of the Definition of Done. Use when the user says grooming, wants to break a feature into tickets, create issues, or plan implementation work.
SKILL.md
1.9 KB, as published. Nobody here has run it
grooming 🐈
Groom the backlog, not the fur. Spec in, issues out. Read ../no-slop.md first.
Input
A spec file (docs/specs/*.md, usually from scratch-me). If none exists, offer to run scratch-me first — grooming without a DoD produces guesses, not tickets.
Slicing rules
- Vertical slices: each ticket ships observable behavior end-to-end (UI → logic → storage), never "backend part" / "frontend part".
- Tracer bullet first: ticket #1 is the thinnest path through the whole feature; later tickets thicken it.
- Each ticket gets the DoD lines it owns, copied verbatim from the spec. Every DoD line lives in exactly one ticket.
- A ticket
meowcan't finish in one worktree session is too big — split it. - 2–6 tickets for most features. More means the spec is too big; say so.
Issue format
Title: <verb> <object> (e.g. Add retry queue for failed webhooks). Body:
Spec: docs/specs/<feature>.md
## DoD
- [ ] <lines owned by this ticket, verbatim>
## Depends on
#<n> (omit section if none)
No context paragraphs — the spec is the context, linked once.
Create
Show the ticket list (titles + DoD counts) for a yes/no before touching GitHub. Then:
gh issue create --title "..." --body-file /tmp/issue-N.md --label "meow:ready"
Link sub-issues to a parent with gh issue create ... && gh api sub-issue endpoints if the repo uses them; otherwise a task-list in the parent body. Respect existing labels — check gh label list before inventing any.
End by outputting the issue URLs. Nothing else.