Menu
Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.
Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
npx skills add https://github.com/adamayoung/TMDb --skill lintLa commande reste sur une seule ligne. Faites défiler horizontalement pour la vérifier avant de la copier.
Vous préférez une copie locale ? Téléchargez les fichiers actuellement disponibles dans SkillsMP.
Implement features and fix bugs test-first, the Canon TDD way (test list → one test → make it pass → refactor → repeat). Use when implementing any new feature, endpoint, model, or method, fixing a bug, or executing a plan — write the test list and a failing test BEFORE production code.
Capture durable, project-specific learnings from the work just done into the knowledge/ base — gotchas, implementation quirks, things looked up or web-searched, live-API behaviours, and design decisions (as ADRs). Use before opening a PR (it runs automatically in /deliver), or any time you've learned something worth remembering. Records only non-obvious, reusable facts; skips anything already in the repo, CLAUDE.md, or git history.
Take a plan all the way to a ready-to-merge pull request — review the plan (scaled to risk), implement it test-first, code-review and fix, run the CI gate, open the PR, and watch it green. Use after you have an approved plan (from plan mode, or the Plan agent); pass `issue <n>` to deliver a specific GitHub issue you name, or `next` to take the top startable issue off the project board's Ready column — either way it re-verifies, claims and plans the issue first. Invoking it with a plan already in hand is itself plan approval — it then runs autonomously to a single hard stop: ready-to-merge.
Affichage de SKILL.md
| name | lint |
| description | Lint code with swiftlint and swiftformat |
Run make lint from the project root to check code style. It runs eight
checks, in order: six Python scripts under Scripts/ — lint-witnesses
(check-defaulted-witnesses.py, protocol conveniences that would witness their
own requirement), lint-fixtures (check-fixtures.py, JSON fixture hygiene),
lint-curation (check-docc-curation.py, public methods missing from their
DocC page), lint-prose (check-prose-call-forms.py, code samples calling a
method that does not exist), lint-readme-version
(check-readme-version.py, README's .package(from:) vs the newest
CHANGELOG.md release) and lint-run-list (run-script-tests.py — despite
the target's name, every suite under Scripts/tests/: the /triage-issues
run-list builder, the /deliver selection-prose anti-drift cases, the
deliver-runfile.py writer, and the workflow cache-key/change-gate cases) —
then swiftlint --strict ., then swiftformat --lint ..
Each script enforces something no single-file linter can see, and a failure in
any of them is not a formatting problem: /format will not fix it.
Run this directly — it is fast and low-output, so delegating to a subagent would cost more (subagent overhead) than it saves.
If you see superfluous_disable_command errors on files you did not just change,
it is usually a swiftlint version-drift artifact (the pin is swiftlint 0.63.2 /
swiftformat 0.61.1), not a real violation. Run /format to auto-fix fixable
violations.
