SQL Skill Pack

What This Pack Covers

Two skills: one that checks database migrations for destructive or risky changes before they run, and one that reviews hand-written queries for correctness and performance issues. Both deal with actions that are expensive or dangerous to get wrong, which makes the failure-handling discipline from Skill Engineering especially relevant here.

Skill 1: sql-migration-safety-check

---
name: sql-migration-safety-check
description: Reviews a SQL migration file for destructive or risky changes before it runs — dropped columns, missing defaults on new NOT NULL columns, and lock-heavy operations on large tables. Use when reviewing a migration, before running one against production, or when the user asks if a migration is safe.
metadata:
  version: "1.0.0"
---

## Constraints

Never state a migration is "safe" without checking every rule below. When
uncertain about a table's size or production usage, say so explicitly
rather than assuming it's small.

## Review checklist

1. **Dropped columns or tables.** Flag any `DROP COLUMN` or `DROP TABLE` —
   these are irreversible without a backup. Confirm a rollback plan exists
   before calling this acceptable.
2. **NOT NULL without a default.** Adding a `NOT NULL` column to an
   existing table without a `DEFAULT` will fail on any table with existing
   rows. Flag this as a blocking issue, not a suggestion.
3. **Unindexed foreign keys.** A new foreign key column without an
   accompanying index will cause slow joins and slow cascade deletes as
   the table grows.
4. **Lock-heavy operations on large tables.** `ALTER TABLE` operations that
   rewrite an entire table (adding a column with a non-null default on
   most database engines, for example) lock the table for the duration.
   Flag this and suggest a safer, phased approach when possible — add the
   column nullable first, backfill, then add the constraint separately.

## On failure

If any blocking issue is found, do not soften the assessment — state
clearly that the migration should not run as written, and what needs to
change first.

Pattern: Validator, with an explicit constraint (from Skill Engineering) against the failure mode that matters most here — a validator that’s been talked into softening a genuinely blocking finding is worse than no validator at all.

Skill 2: sql-query-review

---
name: sql-query-review
description: Reviews a SQL query for correctness and performance issues — missing WHERE clauses on UPDATE/DELETE, SELECT *, and likely N+1 query patterns. Use when reviewing a query before it ships, or when the user asks whether a query is safe or efficient.
metadata:
  version: "1.0.0"
---

## Review checklist

1. **UPDATE or DELETE without a WHERE clause.** This is the single highest-
   severity finding this skill can report — flag it first, ahead of every
   other check, and state plainly what rows would be affected (all of them).
2. **SELECT \*.** Flag in application code (fine in ad-hoc exploration, not
   in code that ships) — it breaks when columns are added later and pulls
   more data than needed.
3. **Queries inside a loop.** If the surrounding code shows a query being
   constructed or executed inside a loop over application-level records,
   flag this as a likely N+1 pattern and suggest a single batched query
   or a join instead.
4. **Unparameterized string-built queries.** Any query built via string
   concatenation or f-strings with user input inserted directly is a SQL
   injection risk — flag this as blocking, not a style note.

Report findings ordered by severity: missing WHERE clause and injection
risk first, then performance issues.

Pattern: Reviewer — assessing already-written SQL against criteria and reporting specific, prioritized findings, per Skill Design Patterns.

Why Severity Ordering Matters Here

Both skills above explicitly order their findings by severity rather than just listing checks in an arbitrary sequence. This matters more for a SQL pack than for most: a missing WHERE clause on a DELETE is catastrophic and a SELECT * is a minor style issue, and a skill that reports them with equal visual weight risks a genuinely dangerous finding getting lost among cosmetic ones. This is worth checking specifically during testing — not just whether a skill catches every issue, but whether the most dangerous one is impossible to miss in its output.

Testing Both Skills

Run sql-migration-safety-check against a migration with no issues, one with exactly one blocking issue (a DROP COLUMN), and one with several issues at different severities — confirm the blocking issue is never softened into a mere suggestion. Run sql-query-review against a query that’s genuinely fine, one with an unqualified DELETE, and one with a plausible N+1 pattern in the surrounding code — this last case is the hardest to get reliably right, since it depends on the skill reading context beyond just the query text itself, and is worth testing with a real code snippet, not just the bare SQL.

Summary

• sql-migration-safety-check is a Validator focused on irreversible or lock-heavy changes, with an explicit constraint against softening a blocking finding
• sql-query-review is a Reviewer covering correctness (missing WHERE, injection risk) and performance (SELECT *, N+1 patterns), ordered by severity
• Both skills deal with genuinely destructive or risky actions, which is exactly the case Skill Engineering says warrants explicit, non-negotiable constraints rather than soft suggestions
• Test not just whether each skill catches every issue, but whether the most severe one is impossible to miss in the output

Next, a pack for the collaboration layer around code — pull requests, issue triage, and release notes, using the GitHub CLI.