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/j-pster/psters_ai_workflow/typeorm-migrationsgit clone --depth 1 https://github.com/J-Pster/Psters_AI_WorkflowWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/j-pster/psters_ai_workflow/typeorm-migrations)<a href="https://agentmods.dev/rules/j-pster/psters_ai_workflow/typeorm-migrations"><img src="https://agentmods.dev/badge/rules/j-pster/psters_ai_workflow/typeorm-migrations.svg" alt="Measured on agentmods" height="20"></a>What 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.01132 | $0.01132 |
| Opus 5 | $0.00566 | $0.00566 |
| Sonnet 5 | $0.00226 | $0.00226 |
| Haiku 4.5 | $0.00113 | $0.00113 |
Grade A, and why
typeorm-migrations 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 5d 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 — 123 lines — stays where its author put it; the contents beside it link to each section on GitHub.
TypeORM Migrations - CLI Only
CRITICAL: Always Use TypeORM CLI for Migrations
IMPORTANT: You MUST NEVER create migration files manually. Always use the TypeORM CLI to generate migrations automatically based on entity definitions.
CRITICAL: Generate → Drift-Check → Run IMMEDIATELY (Atomic Chain)
THIS IS THE #1 SOURCE OF PRODUCTION BUGS. When a migration is generated but NOT run on the local database immediately, the next typeorm:generate compares against the OLD schema and produces a migration with schema drift — it re-includes changes from the unrun migration plus new changes, creating a broken migration that will fail in production.
THE RULE: Every migration MUST be run on the local DB immediately after generation. Never defer. Never skip. Never "do it later."
The atomic chain (NEVER break this sequence):
1. Generate: npm run typeorm:generate -- src/database/migrations/MigrationName
2. Drift-check: Run schema-drift-detector agent on the new file → fix any unrelated changes
3. Run locally: npm run typeorm:run (or npm run dev:migrate for Docker)
4. Verify: If typeorm:run fails → STOP. Fix the issue before continuing.
BLOCKING: Do NOT proceed to the next task, the next entity change, or the next migration until step 3 succeeds. If you need to generate a second migration in the same session, the first one MUST be run first.
Production deployment: Use project-specific migration scripts (e.g. npm run migrate:localtoprod) that:
- Run
typeorm:runon local DB first (fails fast if local is broken) - Run guard scripts to block schema dumps and wrong-baseline migrations
- Only then run migrations on the production DB
NEVER edit past migrations. If a migration is wrong, create a new corrective migration.
Why This Rule Exists
- Automatic Schema Detection: TypeORM CLI compares the current database schema with entity definitions and generates the exact SQL needed
- Consistency: Ensures migrations match entity definitions exactly
- Error Prevention: Avoids manual errors in SQL generation
- Drift Prevention: Running immediately keeps the local DB in sync so future generations are clean
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.
- 5d ago First seen · 123 lines · 1,132 tokens per session scan A 99259bf6f02d
typeorm-migrations is a cursor rule published in the GitHub repository J-Pster/Psters_AI_Workflow (290 stars, last pushed 5mo ago), licensed MIT. It adds 1,132 tokens to every session, about $0.0057 per session on Opus 5. 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
no-backward-compatibility
Do not add backward-compatibility shims or migration scaffolding.
postgresql
This guide defines the definitive best practices for writing clean, performant, and maintainable PostgreSQL SQL, focusing on modern conventions and avoiding common pitfalls.
query-optimization
查詢優化、EXPLAIN、index 設計與 RLS 效能測量.
ehs-ims-conventions
EHS IMS app — RBAC, data layer, tRPC, migrations, AI boundaries.
sync-timedb-archive-janitor-contract
Day-close / cold-path worker contracts for synctimedb (A invariants; B tick coordinator retired).
schema
Scalable and secure schema design patterns for relational databases, NoSQL, and APIs. / TR: İlişkisel veri tabanları, NoSQL ve API'ler için ölçeklenebilir ve güvenli şema tasarım kalıpları.