Meow
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 meowAssembled 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
Pick up a GitHub issue (or a standalone task) in an isolated git worktree and implement it TDD, red-green-refactor, driven by the Definition of Done from the spec. Use when the user says meow, wants to take a ticket, implement an issue, or start coding a planned feature.
SKILL.md
1.8 KB, as published. Nobody here has run it
meow 🐱
Take the ticket. Test first. Ship. Read ../no-slop.md first.
Pick
- With an issue number:
gh issue view <n>— the DoD checklist in the body is the contract. - Without: list
meow:readyissues (gh issue list --label "meow:ready") and let the user pick, or accept a standalone task (then extract a 2–5 line DoD from the conversation before writing any code).
Isolate
One ticket = one worktree = one branch:
git worktree add ../<repo>-meow-<n> -b meow/<n>-<kebab-title>
cd ../<repo>-meow-<n>
Install deps if the lockfile demands it. Never work on a shared branch.
TDD loop
For each DoD line, in order:
- Red — write the smallest failing test that encodes the DoD line. Run it, confirm it fails for the right reason.
- Green — write the minimum code to pass. Resist generalizing.
- Refactor — only with all tests green, only within touched files.
- Commit:
meow(#<n>): <DoD line, abridged>.
Rules:
- Test the behavior through the module interface, not the internals.
- A DoD line you can't test is a spec bug — stop and flag it, don't fake a test.
- No code without a red test first. No TODO comments — either do it or open an issue.
- Full suite must pass before moving to the next DoD line.
Ship
When every DoD box is checked:
gh pr create --fill --body "Closes #<n>"
Tick the DoD boxes in the issue. Offer to clean the worktree (git worktree remove) after merge — don't do it unasked.
End by outputting the PR URL. Nothing else.
Gives 2 of the 12 instructions most tdd skills give
Counted across 439 of the 443 authors here whose files we hold, read 2026-08-06
- write minimal code to pass the testhere, and in 302 of 439, across 218 files
- write a failing test firsthere, and in 176 of 439, across 112 files
- refactor code only after tests passin 171 of 439, across 101 files
- watch the test fail before writing codein 142 of 439, across 93 files
- test one behavior per testin 106 of 439, across 44 files
- refactor code while keeping tests greenin 99 of 439, across 86 files
- delete code written before testsin 98 of 439, across 54 files
- run tests after each refactor stepin 85 of 439, across 54 files
- Use real code instead of mocks unless unavoidablein 64 of 439, across 21 files
- confirm the test fails for the right reasonin 64 of 439, across 60 files
- reproduce bugs with a test before fixingin 53 of 439, across 36 files
- write tests before implementationin 48 of 439, across 39 files
Said here and by no other author read
- create an isolated git worktree for the task
- extract a definition of done before writing code
- refactor only within touched files
- commit code using the definition line
- open a pull request when tests pass
- tick the definition boxes in the issue
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.