Agent skill

Database Migration

by qf-studio in qf-studio/navigator

Create database migration with schema changes and rollback. An agent skill from qf-studio/navigator.

MITAuto-check: notesDatabases

Install Database Migration

skills CLI
$ npx skills add qf-studio/navigator --skill database-migration -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install qf-studio/navigator database-migration --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/qf-studio/navigator.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/database-migration .claude/skills/database-migration && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
database-migration
GitHub stars
354
Token cost
~3.7k tokens
SKILL.md length
732 words
Files
1
Skills in repo
32
Repo updated
First seen
Licence
MIT

At a glance

Create database migration with schema changes and rollback. An agent skill from qf-studio/navigator.

  • Works in 9 steps: Check Existing Patterns (Phase 0) → Detect Migration Framework → Gather Migration Requirements → …
  • Says create migration
  • SKILL.md covers When to Invoke, What This Does, Execution Steps and Schema Change Templates, plus 4 more sections
  • Calls npx and python3

What it does

Database Migration is an agent skill from qf-studio/navigator. Create database migration with schema changes and rollback. Auto-invoke when user says "create migration", "add table", "modify schema", or "change database".

Its SKILL.md is about 3.7k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Databases, covering Database migrations. The repository describes itself as: Finish What You Start — Context engineering for Claude Code. Sessions last 20+ exchanges instead of crashing at 7. The licence is MIT.

When your agent uses it

  • Says create migration
  • Change database

Example prompts

  • “create migration”
  • “add table”
  • “modify schema”
  • “/database-migration”

Requirements

  • Python 3
  • Node.js
  • Pre-approved tools (allowed-tools): Read, Write, Edit, Grep, Glob, Bash

Workflow steps

9 steps, taken from the step headings in SKILL.md.

  1. Check Existing Patterns (Phase 0)
  2. Detect Migration Framework
  3. Gather Migration Requirements
  4. 5: Verify Understanding (ToM Checkpoint - ALWAYS for DB) [EXECUTE]
  5. Generate Migration File
  6. Generate Rollback Logic
  7. Validate Migration Safety
  8. Show Migration Summary
  9. Emit Execution Summary (Graph Ingestion)

What it can do on your machine

Read from SKILL.md and the folder at commit f1cf0eb. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Write
    • Edit
    • Grep
    • Glob
    • Bash

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • npx
    • python3

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use npx, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Database Migration loads about 3.7k tokens when it runs. Until then it costs about 44 tokens; SKILL.md has 732 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~44
When it runs · the whole SKILL.md, loaded when a task matches
~3.7k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NotePre-approves every shell command (allowed-tools: Bash)SKILL.md
    allowed-tools: Read, Write, Edit, Grep, Glob, Bash

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from qf-studio/navigator at commit f1cf0eb, republished under its MIT licence (© qf-studio). 732 words, ~3,745 tokens.

Download SKILL.mdSave it as .claude/skills/database-migration/SKILL.md (or your agent's skills folder).
name
database-migration
description
Create database migration with schema changes and rollback. Auto-invoke when user says "create migration", "add table", "modify schema", or "change database".
allowed-tools
Read, Write, Edit, Grep, Glob, Bash
version
2.0.0

Database Migration Generator

Generate database migrations with rollback capability for schema changes, with built-in ToM verification for safe database operations.

Implementation note: This skill uses direct Write() calls with inline templates (see Steps 3–4 and "Schema Change Templates" section below). Unlike frontend-component and backend-endpoint, there are no Python helper functions — the skill is prose-driven by design, since migration generation is highly schema-specific and benefits from inline framework templates. Future work (tracked for v6.6.0) may extract a timestamp generator and per-framework templates.

When to Invoke

Auto-invoke when user mentions:

  • "Create migration"
  • "Add table"
  • "Modify schema"
  • "Change database"
  • "Database migration for [change]"
  • "Add column to [table]"
  • "Rename [table/column]"

What This Does

  1. Detects migration framework (Knex, Prisma, TypeORM, raw SQL)
  2. Gathers migration requirements
  3. Verifies understanding before generating (ToM checkpoint - critical for DB changes)
  4. Generates migration file with timestamp
  5. Creates schema change (up migration)
  6. Creates rollback (down migration)
  7. Validates migration safety
  8. Shows migration summary

Execution Steps

Step 0: Check Existing Patterns (Phase 0)

Before detecting the framework, query the knowledge graph for what we already know about database work in this project. For migrations — the highest-stakes execution path — Phase 0 is especially valuable because past pitfalls (failed NOT NULL adds, bad rollback assumptions, naming collisions) often repeat.

bash
PLUGIN_DIR="${CLAUDE_PLUGIN_ROOT:-$(cat "${NAVIGATOR_CONFIG_HOME:-${XDG_CONFIG_HOME:-$HOME/.config}/navigator}/plugin-root" 2>/dev/null)}"
[ -d "$PLUGIN_DIR/skills" ] || PLUGIN_DIR="$HOME/.claude/plugins/marketplaces/navigator-marketplace"
python3 "$PLUGIN_DIR/skills/nav-graph/functions/graph_manager.py" \
  --action query --concept database \
  --graph-path .agent/knowledge/graph.json 2>/dev/null | head -40

Also check migration, schema, and performance (for index decisions).

If memories surface (PATTERN, PITFALL, DECISION entries), read the full memory files for any relevant ones:

bash
ls .agent/knowledge/memories/{patterns,pitfalls,decisions}/ 2>/dev/null

What to do with what you find:

  • Patterns: apply them (e.g. "we always use UUIDs over auto-increment IDs")
  • Pitfalls: avoid them — these are the most important for migrations (record what you avoided in pitfalls_avoided in Step 7)
  • Decisions: respect them (e.g. "we chose JSONB over separate tables for tags")

Skip this step only if the knowledge graph is disabled in .agent/.nav-config.json.

Step 1: Detect Migration Framework

Check project for migration tool:

bash
# Check for Knex
if [ -f "knexfile.js" ] || [ -f "knexfile.ts" ] || grep -q '"knex"' package.json 2>/dev/null; then
  echo "Knex detected"
fi

# Check for Prisma
if [ -f "prisma/schema.prisma" ]; then
  echo "Prisma detected"
fi

# Check for TypeORM
if [ -f "ormconfig.json" ] || [ -f "ormconfig.ts" ] || grep -q '"typeorm"' package.json 2>/dev/null; then
  echo "TypeORM detected"
fi

# Check for Drizzle
if grep -q '"drizzle-orm"' package.json 2>/dev/null; then
  echo "Drizzle detected"
fi

Framework detection result:

Detected: {FRAMEWORK}
Migration directory: {MIGRATION_PATH}
Naming convention: {CONVENTION}

If no framework detected:

⚠️  No migration framework detected

Options:
1. Generate raw SQL migrations
2. Set up Knex (recommended for flexibility)
3. Set up Prisma (recommended for type safety)

Your choice [1-3]:
Step 2: Gather Migration Requirements

Ask user for migration details:

Migration name: [e.g., add_user_verification_columns]
Change type:
  - create_table (new table)
  - add_column (add to existing table)
  - modify_column (change existing column)
  - drop_column (remove column)
  - rename (rename table or column)
  - add_index (create index)
  - add_constraint (foreign key, unique, etc.)

Target table: [e.g., users]

Schema details: [describe the changes]
Step 2.5: Verify Understanding (ToM Checkpoint - ALWAYS for DB) [EXECUTE]

CRITICAL: This step MUST ALWAYS be executed for database migrations. No exceptions.

Database migrations are high-stakes - ALWAYS verify before generating.

Display verification:

I understood you want:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Migration: {MIGRATION_NAME}
Framework: {FRAMEWORK} (detected)
Type: {CHANGE_TYPE}
Target: {TABLE_NAME}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Schema Changes (UP):
{SCHEMA_CHANGE_PREVIEW}

Rollback (DOWN):
{ROLLBACK_PREVIEW}

⚠️  Database migrations affect production data
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Assumptions I'm making:
- Column types match existing conventions
- Indexes will use default naming
- No data migration needed (schema only)

Proceed with generation? [Y/n]

Never skip verification for database migrations - they can cause data loss.

Step 3: Generate Migration File

Based on detected framework:

Knex Migration
bash
# Generate filename
TIMESTAMP=$(date +%Y%m%d%H%M%S)
FILENAME="${TIMESTAMP}_${MIGRATION_NAME}.ts"

# Create migration file
Write(
  file_path: "migrations/${FILENAME}",
  content: [knex migration template]
)

Knex template:

typescript
import { Knex } from 'knex';

export async function up(knex: Knex): Promise<void> {
  ${UP_MIGRATION}
}

export async function down(knex: Knex): Promise<void> {
  ${DOWN_MIGRATION}
}
Prisma Migration
bash
# Prisma uses schema.prisma + migrate commands
# Update schema.prisma with new models/fields
# Then run: npx prisma migrate dev --name ${MIGRATION_NAME}

Show Prisma workflow:

Prisma detected - updating schema.prisma

1. I'll update prisma/schema.prisma with:
   ${SCHEMA_CHANGES}

2. Run migration:
   npx prisma migrate dev --name ${MIGRATION_NAME}

3. Generate client:
   npx prisma generate
TypeORM Migration
bash
TIMESTAMP=$(date +%Y%m%d%H%M%S)
FILENAME="${TIMESTAMP}-${MIGRATION_NAME}.ts"

TypeORM template:

typescript
import { MigrationInterface, QueryRunner, Table } from 'typeorm';

export class ${MIGRATION_CLASS_NAME}${TIMESTAMP} implements MigrationInterface {
  public async up(queryRunner: QueryRunner): Promise<void> {
    ${UP_MIGRATION}
  }

  public async down(queryRunner: QueryRunner): Promise<void> {
    ${DOWN_MIGRATION}
  }
}
Step 4: Generate Rollback Logic

Ensure every UP has a corresponding DOWN:

UP OperationDOWN Operation
CREATE TABLEDROP TABLE
ADD COLUMNDROP COLUMN
ADD INDEXDROP INDEX
ADD CONSTRAINTDROP CONSTRAINT
RENAMERENAME (reverse)
ALTER COLUMNALTER COLUMN (reverse)

Warning for destructive operations:

⚠️  DROP COLUMN in DOWN migration will lose data!

Column: {COLUMN_NAME}
Type: {COLUMN_TYPE}

If this column has data, consider:
1. Backup data before migration
2. Add data migration step
3. Keep column but deprecate

Understood? [Y/n]
Show full SKILL.md (299 more words)Show less
Step 5: Validate Migration Safety

Check for common issues:

Migration Safety Check:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ Rollback defined (can undo changes)
✅ No DROP TABLE without backup warning
✅ No ALTER on large tables without consideration
⚠️  Adding NOT NULL column - needs DEFAULT value
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Safety warnings to check:

  • Adding NOT NULL without DEFAULT (will fail on existing rows)
  • Dropping columns with data
  • Renaming columns (may break application code)
  • Adding UNIQUE constraint (may fail if duplicates exist)
  • Large table alterations (may lock table)
Step 6: Show Migration Summary

Display completed migration:

✅ Migration Created: {MIGRATION_NAME}

File: {MIGRATION_PATH}/{FILENAME}
Framework: {FRAMEWORK}
Timestamp: {TIMESTAMP}

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Schema Changes:
┌─────────────────────────────────────────────┐
│ UP (Apply)                                  │
├─────────────────────────────────────────────┤
│ {UP_MIGRATION_SUMMARY}                      │
└─────────────────────────────────────────────┘

┌─────────────────────────────────────────────┐
│ DOWN (Rollback)                             │
├─────────────────────────────────────────────┤
│ {DOWN_MIGRATION_SUMMARY}                    │
└─────────────────────────────────────────────┘

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Run Migration:
{RUN_COMMAND}

Test Rollback:
{ROLLBACK_COMMAND}

Next Steps:
1. Review migration file
2. Test on development database
3. Run migration: {RUN_COMMAND}
4. Verify schema changes
5. Commit migration file
Step 7: Emit Execution Summary (Graph Ingestion)

After Step 6, emit an execution_summary JSON block. Database migrations are the highest-stakes execution path — recording the patterns and decisions here is the most valuable. This block flows into the knowledge graph via execution_to_graph.py.

Output the block verbatim (replace placeholders with actual values):

json
{
  "execution_summary": {
    "skill": "database-migration",
    "task": "{MIGRATION_NAME}",
    "files_created": ["{migration file path}"],
    "files_modified": [],
    "tests_added": [],
    "stack_detected": "{e.g. knex+postgres or prisma+postgres}",
    "patterns_followed": [
      {"summary": "{convention applied — e.g. timestamp-prefixed filenames, UUID primary keys}", "concepts": ["database"], "confidence": 0.8}
    ],
    "decisions_made": [
      {"summary": "{non-obvious choice — e.g. used VARCHAR(255) over TEXT for indexability}", "concepts": ["database"], "confidence": 0.75, "evidence": "{path:line}"}
    ],
    "pitfalls_avoided": [
      {"summary": "{e.g. added DEFAULT to NOT NULL column to avoid failing on existing rows}", "concepts": ["database"], "confidence": 0.9}
    ],
    "assumptions_made": ["{e.g. PostgreSQL 14+ — used gen_random_uuid()}"]
  }
}

Ingestion (run from project root):

bash
PLUGIN_DIR="${CLAUDE_PLUGIN_ROOT:-$(cat "${NAVIGATOR_CONFIG_HOME:-${XDG_CONFIG_HOME:-$HOME/.config}/navigator}/plugin-root" 2>/dev/null)}"
[ -d "$PLUGIN_DIR/skills" ] || PLUGIN_DIR="$HOME/.claude/plugins/marketplaces/navigator-marketplace"
echo '<execution_summary JSON>' | python3 "$PLUGIN_DIR/skills/nav-graph/functions/execution_to_graph.py" -

Migration-specific rules:

  • Always record pitfalls — DB changes are easy to get wrong, future agents need the warning.
  • Stack detection should include both the migration framework AND the target DB (e.g. knex+postgres).
  • Decisions about column types, indexes, and constraints are valuable to capture even when they feel obvious.

Schema Change Templates

Create Table (Knex)
typescript
export async function up(knex: Knex): Promise<void> {
  await knex.schema.createTable('${TABLE_NAME}', (table) => {
    table.uuid('id').primary().defaultTo(knex.raw('gen_random_uuid()'));
    ${COLUMN_DEFINITIONS}
    table.timestamps(true, true);
  });
}

export async function down(knex: Knex): Promise<void> {
  await knex.schema.dropTableIfExists('${TABLE_NAME}');
}
Add Column (Knex)
typescript
export async function up(knex: Knex): Promise<void> {
  await knex.schema.alterTable('${TABLE_NAME}', (table) => {
    table.${COLUMN_TYPE}('${COLUMN_NAME}')${MODIFIERS};
  });
}

export async function down(knex: Knex): Promise<void> {
  await knex.schema.alterTable('${TABLE_NAME}', (table) => {
    table.dropColumn('${COLUMN_NAME}');
  });
}
Add Index (Knex)
typescript
export async function up(knex: Knex): Promise<void> {
  await knex.schema.alterTable('${TABLE_NAME}', (table) => {
    table.index(['${COLUMN_NAME}'], '${INDEX_NAME}');
  });
}

export async function down(knex: Knex): Promise<void> {
  await knex.schema.alterTable('${TABLE_NAME}', (table) => {
    table.dropIndex(['${COLUMN_NAME}'], '${INDEX_NAME}');
  });
}

Framework-Specific Commands

Knex
bash
# Run pending migrations
npx knex migrate:latest

# Rollback last batch
npx knex migrate:rollback

# Run specific migration
npx knex migrate:up ${MIGRATION_NAME}

# Check status
npx knex migrate:status
Prisma
bash
# Create and apply migration
npx prisma migrate dev --name ${MIGRATION_NAME}

# Apply in production
npx prisma migrate deploy

# Reset database (dev only)
npx prisma migrate reset

# Check status
npx prisma migrate status
TypeORM
bash
# Run pending migrations
npx typeorm migration:run

# Revert last migration
npx typeorm migration:revert

# Generate migration from entities
npx typeorm migration:generate -n ${MIGRATION_NAME}

# Show migrations
npx typeorm migration:show

Error Handling

Framework not detected:

⚠️  No migration framework detected in project

Please set up a migration framework first:
- Knex: npm install knex && npx knex init
- Prisma: npm install prisma && npx prisma init
- TypeORM: npm install typeorm && create ormconfig

Migration name conflict:

⚠️  Migration with similar name already exists

Existing: 20251209_add_users_table.ts
Requested: add_users_table

Options:
1. Use different name
2. Add version suffix (add_users_table_v2)
3. Check if existing migration is sufficient

Your choice [1-3]:

Validation failure:

❌ Migration validation failed

Issues:
- Column 'status' is NOT NULL but has no DEFAULT
- Table 'orders' doesn't exist (referenced in foreign key)

Fix these issues before generating migration.

Success Criteria

Migration is successful when:

  • Migration file generated with unique timestamp
  • Framework conventions followed
  • UP migration creates/modifies schema correctly
  • DOWN migration rolls back changes completely
  • ToM verification passed (user confirmed understanding)
  • Safety checks passed
  • Commands shown for running migration

Best Practices

Naming Conventions
  • create_users_table - for new tables
  • add_email_to_users - for adding columns
  • add_index_on_users_email - for indexes
  • change_status_type_in_orders - for modifications
Safety
  • Always test on development database first
  • Backup production before running migrations
  • Use transactions where supported
  • Consider data migration for non-null columns
Code Review
  • Review generated SQL before running
  • Check rollback logic is complete
  • Verify no data loss in DOWN migration
  • Test full rollback cycle

Database migrations affect production data - ToM verification is mandatory for this skill 🗄️

© qf-studio, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/database-migration of qf-studio/navigator.

Open the folder on GitHubat commit f1cf0eb

Compare with similar skills

Database Migration next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Database Migration compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Database Migration this skillqf-studio/navigator354—~3.7kAutomated safety check: NotesMIT
Evolving The Data ModelTriliumNext/Trilium38k—~2.1kAutomated safety check: PassAGPL-3.0
Creating Database MigrationsNangoHQ/nango13k—~449Automated safety check: PassCustom licence
Openwrt Package UpdateNethServer/nethsecurity191—~841Automated safety check: PassCustom licence
Free Willsyahiidkamil/Software-Engineer-AI-Agent-Atlas401—~3.4kAutomated safety check: PassNone
Ecto Migrationsoperately/operately577—~1.2kAutomated safety check: PassCustom licence

Similar skills

  • Evolving The Data Model

    TriliumNext/Trilium

    A skill your agent uses when adding a DB migration or a new column/field to a Becca entity in Trilium ("add a migration", "new column on notes/attributes", "ALTER TABLE", "add a field to…

    38k GitHub stars~2.1k tokensUpdated today
    DatabasesAuto-check passed
  • A skill your agent uses when adding or editing Nango database migrations - covers migration directory selection, timestamped .cjs naming, matching recent migration style, down migration decisions…

    13k GitHub stars~449 tokensUpdated today
    DatabasesAuto-check passed
  • Openwrt Package Update

    NethServer/nethsecurity

    A skill your agent uses when updating any forked OpenWrt package in a NethSecurity workspace from the upstream openwrt/packages feed.

    191 GitHub stars~841 tokensUpdated today
    DatabasesAuto-check passed
  • Free Will

    syahiidkamil/Software-Engineer-AI-Agent-Atlas

    Deliberate-choice procedure for a medium-to-high-stakes engineering fork — when the first plausible solution (the instinct, the default next-token pull) would be costly to get wrong.

    401 GitHub stars~3.4k tokensUpdated 3 mo ago
    DatabasesAuto-check passed
  • Ecto Migrations

    operately/operately

    Rules for Operately schema migrations (app/priv/repo/migrations/) and data migrations (app/lib/operately/data/change.ex).

    577 GitHub stars~1.2k tokensUpdated today
    DatabasesAuto-check passed
  • DB Migrate

    simstudioai/sim

    Author or review a Drizzle DB migration for zero-downtime safety — expand/contract phasing, backward-compatibility with the deployed app version, and writing the -- migration-safe acknowledgment the…

    30k GitHub stars~2k tokensUpdated today
    DatabasesAuto-check passed

More from qf-studio/navigator

All 32 skills in this repo
  • Backend Endpoint

    qf-studio/navigator

    Create REST/GraphQL API endpoint with validation, error handling, and tests.

    354 GitHub starsUsed in 1 repo~4.5k tokens
    Auto-check: notes
  • Nav Start

    qf-studio/navigator

    Load Navigator documentation navigator when starting development session, resuming work, or beginning new feature.

    354 GitHub stars~4.7k tokensUpdated yesterday
    Auto-check: notes
  • Backend Test

    qf-studio/navigator

    Generate backend tests (unit, integration, mocks) for existing code.

    354 GitHub stars~1.5k tokensUpdated yesterday
    Auto-check: notes
  • Frontend Component

    qf-studio/navigator

    Create React/Vue component with TypeScript, tests, and styles.

    354 GitHub stars~4.5k tokensUpdated yesterday
    Auto-check: notes
  • Frontend Test

    qf-studio/navigator

    Generate frontend component tests (React Testing Library, Vue Test Utils, snapshot) for existing components.

    354 GitHub stars~1.6k tokensUpdated yesterday
    Auto-check: notes
  • Nav Compact

    qf-studio/navigator

    Clear conversation context while preserving knowledge via context marker.

    354 GitHub stars~2.1k tokensUpdated yesterday
    Auto-check: notes

Categories

Questions about Database Migration

What does Database Migration do?

Create database migration with schema changes and rollback. An agent skill from qf-studio/navigator. Database Migration is an agent skill from qf-studio/navigator. Create database migration with schema changes and rollback.

When should I use Database Migration?

Database Migration fits situations like: says create migration; change database.

How do I install Database Migration in Claude Code?

Run `npx skills add qf-studio/navigator --skill database-migration -a claude-code`. Or copy the skill folder (skills/database-migration in qf-studio/navigator) into .claude/skills/database-migration in your project. Claude Code loads it when a task matches its description.

How do I install Database Migration in Codex?

Run `npx skills add qf-studio/navigator --skill database-migration -a codex`. Or copy the skill folder (skills/database-migration in qf-studio/navigator) into .agents/skills/database-migration in your project. Codex loads it when a task matches its description.

Can I use Database Migration in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add qf-studio/navigator --skill database-migration -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/database-migration, .gemini/skills/database-migration, .github/skills/database-migration and .opencode/skills/database-migration in your project.

What does Database Migration need to run?

Going by SKILL.md and its folder, Database Migration needs the command-line tools its instructions call (npx and python3). Our summary lists: Python 3; Node.js. Its frontmatter pre-approves these tools: Read, Write, Edit, Grep, Glob, Bash.

Does Database Migration access the network?

SKILL.md contains no URLs. Its commands use npx, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Database Migration safe to install?

Our automated static check of SKILL.md found notes only (pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Database Migration use?

Database Migration is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Database Migration use?

About 3.7k tokens (SKILL.md is roughly 15k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Database Migration?

Skills that share tags, products or a category with Database Migration: Evolving The Data Model (TriliumNext/Trilium, 38k stars), Creating Database Migrations (NangoHQ/nango, 13k stars), Openwrt Package Update (NethServer/nethsecurity, 191 stars) and Free Will (syahiidkamil/Software-Engineer-AI-Agent-Atlas, 401 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Database Migration?

qf-studio (a GitHub organization) maintains it in qf-studio/navigator, which has 354 GitHub stars. The repository holds 32 skills in this directory. The repository was last updated on October 7, 2026.

Source: qf-studio/navigator on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.