Five skills every backend team should have by Friday

You don't need a skill library. You need five, and they can each be under 40 lines. Here's a short spec for each, sized to write and test in one afternoon.

review-endpoint

Input: a diff touching a route handler. Output: a list of findings with file:line references.

---
name: review-endpoint
description: Review a REST endpoint for auth, validation, and error handling. Use when reviewing or writing an API route.
---

Check: auth before any DB read, input validated against a schema,
consistent error shape, no raw stack traces, rate limiting on writes.
Report each finding with a file:line reference. Done when every
item is confirmed against the actual code.

write-tests

Input: a function or module. Output: a test file covering the stated behavior, not the implementation.

Write the description to state the boundary explicitly: "write tests against documented behavior and edge cases, not against internal implementation details" — this is what keeps the output from becoming a test an agent can trivially pass by asserting whatever the code currently does.

explain-failure

Input: a stack trace or failing CI log. Output: a plain-English root cause and the specific line that caused it, not a restatement of the error message.

---
name: explain-failure
description: Explain why a test or build failed in plain English. Use when a CI run fails or an error log needs interpreting.
---

Read the full log, not just the last line. State the root cause,
the file and line responsible, and whether it's a code bug, a
flaky test, or an environment issue. Don't suggest a fix unless asked.

release-notes

Input: merged PRs since the last release. Output: a changelog grouped by user-facing impact, not by commit order.

---
name: release-notes
description: Draft release notes from merged PRs since the last tag. Use when cutting a release or asked what shipped.
---

Group by user-facing impact: breaking changes first, then new
features, then fixes. Skip internal refactors unless they change
behavior. Link each entry to its PR number.

This one benefits from dynamic context injection if your tool supports it — pulling the actual PR list into the skill body rather than asking the agent to guess what merged.

migrate-safely

Input: a schema diff. Output: a rollout plan that separates the backward-compatible step from the breaking one.

---
name: migrate-safely
description: Plan a safe database migration for a schema change. Use when adding, removing, or changing a column or table.
---

Split into an additive step (safe to deploy alone) and a cleanup
step (only after the additive step is fully rolled out). Flag any
change that locks a table or breaks a running query mid-deploy.

Try it today

1. Save all five as .claude/skills/<name>/SKILL.md in one project this week — each under 40 lines.
2. Write each description as "what it does, when to use it," matching the exact phrasing your team already uses when asking for that task.
3. Run each once against something real: an actual PR, an actual failing build, an actual pending migration.
4. When one misses something, add a line to its checklist — don't rewrite the whole skill.
5. Commit all five together so the whole team picks them up on their next pull.

Where this breaks

These five cover common judgment calls, not your team's specific ones — a fintech team needs a different fifth skill than a media company. Treat this as a starting shape, not a checklist to copy verbatim. And a skill that no one has hit a failure with yet is unproven; the real value shows up after the first miss gets written back into the file.

Next: sharing and versioning skills across repos.