Major Dependency Upgrade

Plan a major framework or library upgrade: breaking changes that hit your code, a staged order, and a verification step per stage.

Plan an upgrade from [PACKAGE] [CURRENT VERSION] to [TARGET VERSION].

Why we are upgrading: [SECURITY FIX / FEATURE WE NEED / END OF SUPPORT / STAYING CURRENT]
How the package is used in our codebase:
"""
[PASTE THE IMPORT SITES, THE CONFIG, AND ANY WRAPPER OR ADAPTER CODE. A GREP FOR THE PACKAGE NAME IS A GOOD START.]
"""
Migration guide or changelog, if you have it:
"""
[PASTE THE OFFICIAL BREAKING CHANGES LIST, OR DELETE THIS BLOCK]
"""
Test coverage over the affected code: [WHAT EXISTS]
Other packages that depend on this one: [PEER DEPENDENCIES, PLUGINS, TYPE PACKAGES]
Deploy and rollback process: [HOW WE SHIP AND HOW WE UNDO]

Produce:

1. **Breaking changes that affect us.** Go through the migration guide and separate the changes that touch our actual usage from the ones that do not. For each relevant one: the guide's item, our code that uses it, and what has to change. This filtered list is the plan; the full changelog is not.

2. **Unknowns.** Anything you cannot judge from what I pasted, especially behavior changes that are not compile errors: changed defaults, altered timing, different error types, stricter validation. These are what break in production after a green build, so list them explicitly with how to check each one.

3. **Staged order.** Break the work into stages that each end in a working, shippable state. Prefer stages that can ship independently over one large branch, and say where that is not possible. For each stage: what changes, what to verify, and the rollback.

4. **Codemods and automation.** Which changes have an official codemod or can be done with a reliable search and replace, and which need judgment. Be honest about the second category.

5. **Verification.** What to run after each stage, what to check manually because tests will not catch it, and what to watch in production after deploy. Name the metrics.

6. **Coverage gaps.** Where our tests do not cover code this upgrade touches, and the smallest tests to add before starting. Write these first; they are the safety net for the whole migration.

7. **Abort criteria.** What would make us stop and revert rather than push through, decided now rather than at 6pm on a Friday.

Rules: work from the migration guide I pasted and my code. Do not recall breaking changes from memory, since version-specific details are exactly what memory gets wrong. Where the guide is missing something you would need, say so and name what to look up.

How to use

Section 2 is why these upgrades hurt. Compile errors are the easy half and they announce themselves; the expensive half is a changed default or a stricter validator that passes CI and fails on real data three days later. Writing the missing tests first (section 6) feels like a detour and is the only thing that makes a staged migration verifiable. Paste the real migration guide rather than trusting recalled version details.

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.