agentsclimarketplace

Grooming

Skill ai-meow/felix-skills/skills/grooming

Cat-grade engineering skills for coding agents. Spec → tickets → TDD in worktrees, plus repo hygiene. No slop.

Install
npx -y skills add ai-meow/felix-skills --skill grooming

Assembled 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 meow can'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.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.