CtrlK
BlogDocsLog inGet started
Tessl Logo

database-migrations

Buenas prácticas de migración de base de datos para cambios de esquema, migraciones de datos, rollbacks y despliegues de tiempo cero en PostgreSQL, MySQL y ORMs comunes (Prisma, Drizzle, Kysely, Django, TypeORM, golang-migrate).

59

Quality

69%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./docs/es/skills/database-migrations/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

63%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body delivers strong, concrete migration guidance — GOOD/BAD SQL patterns, safety checklists, and a clear expand-contract strategy — but it is a monolithic file that inlines five ORM-specific references and ~80 lines of schema boilerplate Claude already knows. Splitting per-ORM content into references/ and fixing the invalid COMMIT-in-DO-block example would lift it substantially.

Suggestions

Split the Prisma, Drizzle, Kysely, Django, and golang-migrate sections into one-level-deep references/ files (e.g. "Prisma: See [prisma.md](prisma.md)"), keeping the shared principles, checklist, and PostgreSQL patterns in SKILL.md.

Fix the large-backfill example: COMMIT is invalid inside a DO block — move batching into a procedure or use explicit per-batch transactions in application code.

Drop the Prisma/Drizzle schema-definition examples and the Kysely migrator boilerplate, which re-teach what Claude already knows and add no migration-specific value.

DimensionReasoningScore

Conciseness

Mostly efficient — the GOOD/BAD SQL comparisons, checklist, and anti-pattern table earn their tokens — but roughly 80 lines re-teach what Claude already knows: full Prisma and Drizzle schema definitions ("model User { ... }", "pgTable(\"users\"...)") and the Kysely migrator boilerplate, which are not migration guidance. Not 4 because that padding is more than a minor instance (it spans three sections); not 2 because the majority of the body is high-value, non-obvious operational knowledge with no prose padding.

3 / 5

Actionability

Concrete, copy-paste-ready SQL and CLI commands throughout ("CREATE INDEX CONCURRENTLY idx_users_email ON users (email)", "npx prisma migrate dev --create-only --name add_email_index", the expand-contract step sequences). Not 5 because the batched-update example is not actually executable as written: "COMMIT" inside a DO block's LOOP is invalid in PL/pgSQL (transaction control is only allowed in procedures called via CALL), so the flagship large-backfill pattern fails if run verbatim.

4 / 5

Workflow Clarity

Multi-step processes are clearly sequenced with validation artifacts: the pre-migration checklist ("Probado contra una copia de datos de producción", "Plan de rollback documentado"), the numbered rename/drop sequences, the phased expand-contract strategy with a day-by-day timeline, and recovery guidance ("Forzar versión (corregir estado sucio)", "Verificar consistencia de datos" in Fase 2). Not 5 because no workflow includes an explicit fail-then-act feedback loop (e.g., what to check and do when a migration fails or a backfill stalls mid-batch), and the batch example reports progress via RAISE NOTICE but never verifies results; not 3 because checkpoints are genuinely present, not merely implicit, so the missing-feedback-loop cap at 3 does not apply.

4 / 5

Progressive Disclosure

Good internal structure with clear section headers, but it is a ~430-line monolith: the five per-ORM sections (Prisma, Drizzle, Kysely, Django, golang-migrate) are exactly the content that belongs in one-level-deep references/ files, since a Django user currently loads Drizzle, Kysely, and Go content on every activation. Scored 3 rather than 2 because there are no buried or nested references and the body is well-organized with clear navigation, fitting the "content that should be separate is inline" anchor; not 4 because no reference split or navigation to external material exists at all.

3 / 5

Total

14

/

20

Passed

Description

75%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong, specific description with comprehensive action coverage and a named technology stack, but it lacks any explicit "Use when..." trigger clause, capping completeness and leaving activation guidance implicit. Adding a trigger sentence would make it fully effective for skill selection.

Suggestions

Add an explicit trigger clause, e.g. "Usar cuando se modifiquen esquemas de base de datos, se ejecuten backfills, o se planifiquen despliegues de migraciones en producción".

Include natural user phrasings like "backfill", "agregar/quitar una columna" or "crear un índice" to broaden trigger term coverage.

Remove "TypeORM" (and "MySQL", if not covered) from the tool list, or ensure the body covers them, so the description does not over-claim coverage.

DimensionReasoningScore

Specificity

The description lists multiple concrete action areas — "cambios de esquema, migraciones de datos, rollbacks y despliegues de tiempo cero" — plus a comprehensive named stack ("PostgreSQL, MySQL y ORMs comunes (Prisma, Drizzle, Kysely, Django, TypeORM, golang-migrate)"), matching the comprehensive-coverage anchor. Not 4 because coverage of the domain's action categories is complete rather than having minor gaps (TypeORM is claimed but unreferenced in the body, a minor over-claim but not a specificity gap in the description itself).

5 / 5

Completeness

The "what" is clear and concrete (migration best practices across the four action areas), but there is no "Use when..." clause or equivalent explicit trigger guidance anywhere in the description — the rubric explicitly caps this at 3. Not 2 because the "what" is specific, not vague; not 4 because the "when" is entirely missing rather than weakly implied.

3 / 5

Trigger Term Quality

Natural terms users would say are present: "migración de base de datos", "cambios de esquema", "rollbacks", plus tool names (Prisma, Django) users mention by name. Falls short of 5 because common variations users actually say — "backfill", "alter table", "agregar una columna", "índice" — are absent; it stays above 3 because keyword coverage across databases and ORMs is genuinely broad.

4 / 5

Distinctiveness Conflict Risk

A clear niche — database schema/data migrations and rollbacks with named engines and ORMs — with minimal overlap risk against generic SQL or deployment skills. Not 4 because the specific tool list and "despliegues de tiempo cero" make the trigger surface distinctly about migrations rather than only "mostly distinct".

5 / 5

Total

17

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository
affaan-m/ECC
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.