mpattee/skills

My agent skills, shared between Claude Code and Codex. Each skill is a folder under skills/ holding a SKILL.md in the Agent Skills format, which both tools read.
Install
install.sh symlinks each skill into ~/.claude/skills (Claude Code) and ~/.agents/skills (Codex). The links point into the clone, so git pull updates every installed skill, and editing a skill in the clone changes it for both tools at once. Rerun the script after adding or removing a skill. Restart Codex to pick up changes.
The script skips any skill whose name is already taken by a real folder in either location, rather than overwriting it. To bring in a skill from another machine, move its folder into skills/, then rerun.
To use the skills without cloning, npx skills add mpattee/skills copies them into place instead of linking them.
Adding a skill
- One folder per skill, directly under skills/. Keep the layout flat: a Codex plugin can only point at one skills folder, and Codex drops symlinks when it installs a plugin, so a flat skills/ keeps the option of publishing this repo as a Claude or Codex plugin later.
- agents/openai.yaml in a skill's folder is optional. It sets the name and one-line summary Codex shows.
- Nothing employer-specific goes here, because the repo is public. Work-only skills belong in a private repo.
Skills
- **canon-tdd:** test-driven development worked from a test list, following Kent Beck's Canon TDD: list the behaviours, then red, make it work, make it right, and back to the list.
- **setup-mike-pattee-skills:** run once per repo. Records where tickets live and how they're referenced, where pull requests are reviewed, and where the domain docs are, in docs/agents/. The other skills read those files. It uses the same files as Matt Pocock's setup-matt-pocock-skills, so a repo set up by either works with both.
- **whats-next:** the five highest-priority open, unblocked tickets for the repo's Setlist team, and which one to pick up.
- **wwcd-review** (What Would Claude Do)**:** reviews a pull request against its ticket. It writes its own implementation plan from the ticket and the code before reading the PR's description, commits or diff, so the plan doesn't simply echo the PR. Then it compares the two and says which approach is better and why.