· Agentic AI · 5 min read
📋 Prerequisites
- Python Skill Pack (previous lesson)
🎯 What You'll Learn
- Build a Validator skill that catches destructive or unsafe migration patterns before they run
- Build a Reviewer skill that checks query safety and performance against real anti-patterns
- Design failure handling for a skill that could recommend a genuinely destructive action
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 findingsql-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 Engineeringsays 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.