feat(workflows): enforce research checkpoints across development phases

shared/skills/implementation/sql-write/SKILL.md

@@ -9,11 +9,11 @@ Use when writing or changing SQL statements, schema definitions, or database mig
 
 ## Workflow
 
-1. Identify the database engine and version, target schema, affected callers, and expected data shape. Inspect existing migrations and SQL style first.
+1. Identify the database engine and version, target schema, affected callers, and expected data shape. Inspect existing migrations and SQL style first. Before relying on engine-specific syntax, transaction, locking, or migration behavior, MUST apply the implementation checkpoint in `technical-research`.
 2. Parameterize values and validate any dynamic identifiers against an allowlist. Preserve tenant boundaries and authorization filters in every query path.
 3. For schema changes, consider existing rows, nullability, defaults, constraints, indexes, and deployment order. Prefer additive, backward-compatible steps when old and new application versions may overlap.
 4. Use transactions and explicit rollback or recovery steps where supported and appropriate. Estimate affected rows before broad updates or deletes.
 5. Do not execute destructive or production SQL without explicit authorization. A request to write SQL does not authorize running it against live data.
-6. Verify syntax and behavior against the intended engine, then inspect query results, migration ordering, and relevant application tests.
+6. Verify syntax and behavior against the intended engine, then inspect query results, migration ordering, and relevant application tests. MUST apply the verification checkpoint in `technical-research` to external claims; documentation cannot replace execution evidence.
 
 Report the database dialect, files or migration changed, verification, and any operational prerequisite.