ワンクリックで
migration-create
Create database migrations with proper validation, rollback support, and testing. For SEA-Forge services using databases.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Create database migrations with proper validation, rollback support, and testing. For SEA-Forge services using databases.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | migration-create |
| description | Create database migrations with proper validation, rollback support, and testing. For SEA-Forge services using databases. |
| disable-model-invocation | true |
Use this skill when:
Before creating a migration:
# Check current schema
# (database-specific command)
# Check for pending migrations
ls -la apps/*/migrations/pending/ 2>/dev/null
# Review recent migrations
find . -name "*migration*" -type f -mtime -7
Generate migration file with proper naming:
# Naming convention: YYYYMMDDHHMMSS_description.{ext}
# Example: 20240304120000_add_user_preferences_table.sql
# Create migration file
touch apps/sea-mq-worker/migrations/20240304120000_add_user_preferences_table.sql
Use this template for SQL migrations:
-- Migration: {description}
-- Created: {timestamp}
-- Author: {name}
-- Up: {what this migration does}
-- Down: {how to rollback}
-- ═══════════════════════════════════════════════════════════
-- UP MIGRATION
-- ═══════════════════════════════════════════════════════════
BEGIN;
-- Example: Create table
CREATE TABLE user_preferences (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
preferences JSONB NOT NULL DEFAULT '{}',
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
-- Example: Create index
CREATE INDEX idx_user_preferences_user_id ON user_preferences(user_id);
-- Example: Add constraint
ALTER TABLE user_preferences ADD CONSTRAINT check_preferences_not_empty CHECK (jsonb_array_length(preferences) > 0 OR preferences = '{}');
COMMIT;
-- ═══════════════════════════════════════════════════════════
-- DOWN MIGRATION (ROLLBACK)
-- ═══════════════════════════════════════════════════════════
BEGIN;
-- Rollback in reverse order
DROP INDEX IF EXISTS idx_user_preferences_user_id;
DROP TABLE IF EXISTS user_preferences;
COMMIT;
Validate migration before applying:
# Check SQL syntax
psql -f migration.sql --parse-only
# Dry run (if tool supports)
# Some migration tools support --dry-run
# Test migration on test database
# (service-specific command)
Write tests for the migration:
// migration.test.ts
import { describe, it, expect, beforeAll, afterAll } from 'vitest';
import { PostgreSqlContainer } from '@testcontainers/postgresql';
describe('Migration: add_user_preferences_table', () => {
let container;
beforeAll(async () => {
container = await PostgreSqlContainer.start();
});
afterAll(async () => {
await container.stop();
});
it('should create user_preferences table', async () => {
const client = await container.getClient();
// Run up migration
await client.query(/* up migration SQL */);
// Verify table exists
const result = await client.query(`
SELECT EXISTS (
SELECT FROM information_schema.tables
WHERE table_name = 'user_preferences'
)
`);
expect(result.rows[0].exists).toBe(true);
}));
it('should rollback successfully', async () => {
const client = await container.getClient();
// Run up migration
await client.query(/* up migration SQL */);
// Run down migration
await client.query(/* down migration SQL */);
// Verify table is gone
const result = await client.query(`
SELECT EXISTS (
SELECT FROM information_schema.tables
WHERE table_name = 'user_preferences'
)
`);
expect(result.rows[0].exists).toBe(false);
});
});
After validation, apply to development database:
# Apply up migration
# (service-specific command)
# Verify migration applied
# (service-specific command)
# Check schema
# (database-specific command)
ALTER TABLE users ADD COLUMN preferences JSONB;
ALTER TABLE users ADD COLUMN status TEXT NOT NULL DEFAULT 'active';
-- Step 1: Add as nullable
ALTER TABLE users ADD COLUMN status TEXT;
-- Step 2: Backfill data
UPDATE users SET status = 'active' WHERE status IS NULL;
-- Step 3: Make non-nullable
ALTER TABLE users ALTER COLUMN status SET NOT NULL;
ALTER TABLE users RENAME COLUMN old_name TO new_name;
CREATE INDEX idx_users_email ON users(email);
ALTER TABLE posts ADD CONSTRAINT fk_posts_user
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE;
Before committing migration:
After creating migration, output:
## Migration Created
**File**: {path/to/migration.sql}
**Description**: {what it does}
**Type**: {schema|data|rollback}
### Changes
{bullet list of changes}
### Rollback
{how to rollback}
### Tests
{test file location}
### Next Steps
1. Review migration file
2. Run tests: `pnpm test migration.test.ts`
3. Apply to local DB
4. Verify changes
5. Commit with descriptive message
User invokes with:
postgres MCP for database operations@testcontainers/postgresql for testingGuide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends AI agent capabilities with specialized knowledge, workflows, or tool integrations.
Use when creating, scaffolding, or updating the repository AI harness in VS Code. Trigger on requests to bootstrap or refresh instructions, prompts, agents, hooks, skills, or memory layers while preserving useful existing structure and avoiding monolithic always-on context.
Canonical SEA-Forge release workflow for release preparation, validation, branch promotion, tagging, rollback, and release-gate evidence. Use when preparing a release, promoting dev to stage or stage to main, cutting a version tag, validating release readiness, handling hotfix forward-merges, planning rollback, or executing a full end-to-end release. Prefer existing just recipes and evidence-producing gates over ad hoc deployment steps.
Use when SEA work touches specs, generators, manifests, semantic fixtures, regeneration, `src/gen`, or behavior projected from ADR/PRD/SDS/SEA authority.
Use when a SEA context has valid specs and generated contracts but lacks handwritten logic, runtime wiring, persistence, integration, tests, or executable proof.
Create concise, copy-paste-ready bridge prompts between a repo-aware coding agent and an external strategic reasoning agent such as S1 ArchDevAgent. Use when the user wants to offload architecture, research, large refactor planning, migration design, plan critique, implementation-spec drafting, test-strategy design, whole-repo analysis, or diff review to an external agent while keeping repo inspection and implementation in the coding agent. Also use when the user says "use S1", "ask S1", "make a prompt for S1", "bridge this to my external agent", "prepare a context packet", or "validate this S1 response".