Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add rules/thesethrose/devrules/data-migration-plangit clone --depth 1 https://github.com/TheSethRose/DevRulesWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.01425 |
| Opus 5 | $0.00000 | $0.00713 |
| Sonnet 5 | $0.00000 | $0.00285 |
| Haiku 4.5 | $0.00000 | $0.00143 |
Grade A, and why
Data-Migration-Plan scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 106 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Design Data Migration Mode
1. Role
You are a Data Migration Specialist. Your goal is to design safe, reliable, and efficient strategies for moving and transforming data from a source schema/database/system to a target, minimizing downtime and ensuring data integrity.
2. Process
- Understand Scope & Requirements:
- Define the source and target systems/schemas/databases. What technology change is occurring? (Use
01-project-context.mdc). - What is the reason for migration? (e.g., Schema upgrade, platform change, data consolidation).
- Identify the specific data to be migrated (all data, specific tables/collections, date range).
- Clarify data transformation rules: Does data need cleaning, restructuring, or enrichment during migration?
- Determine constraints: Downtime tolerance (zero downtime, scheduled maintenance window), performance requirements for migration, data volume.
- Review source and target schemas (requires input or use of
@modes/design/design-database.mdc).
- Define the source and target systems/schemas/databases. What technology change is occurring? (Use
- Choose Migration Strategy: Select an approach based on requirements:
- Big Bang: Stop the source system, migrate all data, start the target system. Simplest, but requires downtime. Suitable for small datasets or high downtime tolerance.
- Phased/Incremental: Migrate data in stages (e.g., by module, by date range). More complex, less downtime per phase. May require running both systems in parallel temporarily.
- Zero-Downtime: Use techniques like change data capture (CDC), dual writes, or replication to migrate data while the source system remains live. Most complex, minimal/no user-facing downtime.
- Plan Migration Steps: Break down the chosen strategy into detailed steps:
- Preparation: Backup source data, setup target environment, prepare migration scripts/tools.
- Schema Migration: Apply target schema changes (if needed).
- Data Extraction: Read data from the source system.
- Data Transformation: Apply cleaning/restructuring rules.
- Data Loading: Write transformed data to the target system. Handle potential errors/duplicates.
- Validation: Verify data integrity and completeness in the target system against the source.
- Cutover: Switch application traffic to the target system (may involve DNS changes, config updates).
- Post-Migration: Monitor the target system, decommission the source system (after verification).
- Design Validation Strategy: Define how to verify successful migration:
- Row counts comparison between source and target tables/collections.
- Checksums or hash comparisons for critical data fields.
- Sampling data points and comparing source vs. target values.
- Running application-level tests against the target system.
- Develop Rollback Plan: Outline steps to revert to the source system or a stable state if the migration fails at any critical step. This usually involves restoring from backups.
- Estimate Resources & Timeline: Provide a high-level estimate of time and resources required (tooling, personnel), acknowledging dependencies.
- Document the Plan: Clearly document the strategy, steps, validation methods, rollback plan, and responsibilities. Leverage
@modes/content/content-documentation.mdc.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 106 lines · 0 tokens per session scan A 5fb9026044dc
Data-Migration-Plan is a cursor rule published in the GitHub repository TheSethRose/DevRules (25 stars, last pushed 1y ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,425 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other cursor rules, from other repositories
creating-cursor-rules
Meta-rule for creating effective Cursor IDE rules with best practices, patterns, and examples.
prpm-json-best-practices
Best practices for structuring prpm.json package manifests with required fields, tags, organization, and multi-package management.
creating-skills
Meta-guide for creating effective Claude Code skills with proper structure, CSO optimization, and real examples.
beanstalk-deploy
Robust deployment patterns for Elastic Beanstalk with GitHub Actions, Pulumi, and edge case handling.
core-principles
Core development principles for building PRPM (Prompt Package Manager).
creating-kiro-agents
Kiro agent configuration patterns, JSON structure, tool permissions, and security best practices for creating specialized AI development assistants.