Best PromptsLegacy Migration Plan
Plan a framework upgrade or API migration the safe way: full usage inventory, old-to-new mapping rules, and compilable checkpoints.
Plan (do not yet execute) this migration: [FROM → TO, e.g. "Express 4 → 5", "moment → date-fns", "REST client X → Y", "Python 3.9 → 3.12"] Codebase context: [SIZE, STACK, TEST COVERAGE HONESTLY STATED] Why now: [THE FORCING FUNCTION: EOL, security, blocked feature] Relevant code (or run against the repo if you're an agent): """ [PASTE REPRESENTATIVE USAGE, or let the agent search] """ Produce the migration plan: 1. **Inventory**: every distinct usage pattern of the old API/framework in the codebase: pattern → where it appears (files/count) → risk level. Nothing gets changed before everything is counted; surprises mid-migration are how these projects die. 2. **Mapping rules**: for each inventoried pattern, the explicit transformation: old code → new code, as a concrete before/after pair. Note which mappings are mechanical (safe to batch or automate) vs. semantic (behavior differences that need a human decision: list the difference precisely). 3. **The cannot-auto-migrate list**: usages with no clean equivalent: what each does, why it's stuck, and the options (rewrite, shim, drop the feature). These need decisions from me before anything starts. 4. **Checkpoint sequence**: order the migration into stages where the codebase compiles and tests pass at every checkpoint (e.g. by module, by pattern, or old-and-new-coexisting behind an adapter). No big-bang step. For each stage: what changes, how it's verified, and how to roll it back. 5. **Safety net check**: which inventoried patterns have NO test coverage. Those tests get written before their stage begins, against the OLD behavior, so the migration can prove it changed nothing. Rules: version-specific claims about the target framework must be checkable. Cite the migration guide section or changelog entry for each breaking-change claim, or mark it [VERIFY IN CHANGELOG]. Don't shrink the inventory to be encouraging; underestimated migrations get abandoned halfway.
More coding prompts
Write the commit message for this change. Diff: """ [PASTE THE STAGED DIFF] """ Why I made this change: [THE REASON, THE TICKET, THE BUG REPORT, or "you infer it"] Convention: [Conventional Commits / this repo's existing style, pasted below / plain] Recent commits from this repo, to match style: """ [PASTE 5-10 RECENT COMMIT SUBJECT LIN
Commit Message
Write a commit message that explains why the change was made, in Conventional Commits format, split into separate commits when needed.
Codingbeginner
Help me recover from a git mistake without making it worse. What I was trying to do: [THE GOAL] What I ran: [THE EXACT COMMANDS, IN ORDER] What happened instead: [THE OUTPUT OR THE STATE NOW] Has this been pushed or shared: [YES/NO, and to which branch and whether anyone else has pulled] Uncommitted work I cannot lose: [WHAT AND WHERE, o
Undo a Git Mistake
Recover from a bad commit, force push, wrong branch, or lost work with a reversible plan and the exact commands, explained before you run them.
Codingintermediate
Handler code, routes, and models: """ [PASTE THE ROUTE DEFINITIONS, HANDLERS, REQUEST AND RESPONSE TYPES, VALIDATION SCHEMAS, AND MIDDLEWARE] """ Generate an OpenAPI 3.1 specification from the code above. API name, version, and base URL: [DETAILS] Auth scheme: [BEARER JWT / API KEY / OAUTH / SESSION COOKIE, and where it is enforced] Con
OpenAPI Spec From Code
Generate an accurate OpenAPI 3.1 spec from handler code, including error responses and auth, with gaps flagged instead of invented.
Codingintermediate