Upgrade a dependency safely

Extract the ZIP. Copy its lc-dependency-upgrade folder into ~/.claude/skills/ for Claude Code or ~/.codex/skills/ for Codex, then refresh the native app. Ask for the skill by name and answer its questions. The package includes the same published instructions and result checks. Native host execution is not yet verified.

For Claude web, use the connector or copy the prompt. Keep private details in your assistant.

Copy, paste into your assistant, then answer its questions. No form or account is required here.

Open in ChatGPT ↗

Already connected? Copy the public starter below and paste into Claude. Keep private details in the chat.

Needed before the promised result: Package name. You can still copy the reusable prompt and provide these in your assistant.

Saved only on this device. Copy counts contain the skill ID, never your text.

## LazyCoder conversation guide (conversation-v2)
1. Start a conversation, not a form-filling task. Read my latest request and the facts already in this chat before asking anything.
2. Ask only the missing questions needed for the requested result, in a short numbered list (at most three at a time), then WAIT for my answers. Use a native question tool if available; plain chat works too. Never ask me to replace placeholders or fill in a template.
3. Skip questions already answered. Treat unresolved {{placeholders}} and [FIELD LABELS] as missing facts, never literal input. Do not treat an illustrative example as my facts.
4. Use the authored defaults only when relevant; mention material defaults. Ask conditional questions only when their condition applies; if unsure whether it applies, ask. Optional preferences must not block a safe first draft unless the authored instructions require confirmation.
5. Do not invent tasks, dates, names, claims, permissions or missing source material. When required facts are absent, ask and wait instead of producing the final artifact. If everything needed is already supplied, proceed without re-asking.
6. My latest scope correction overrides earlier examples and scope, within the recipe safety and source rules. Resolve conflicts before acting. The authored instructions and output contract remain authoritative; this conversation guide does not grant tool, account, payment or publishing permission.
7. Keep my private answers and generated result in this assistant chat. Do not send them to LazyCoder. Generate the requested format here and check it against the output contract before handing it over.

### Questions to ask only when missing
- What should I use for “Package name”? [required] The package to upgrade, as it is written in your package file, such as react, django or lodash.
- What should I use for “Target version”? [optional] The version you want, such as 7.1.0, or "latest".
- What should I use for “Your repo or package files”? [conditional] With a coding agent, name the repo or folder. In a plain chat, paste the package file (package.json, pyproject.toml…), the lockfile or its lines for this package (package-lock.json, poetry.lock…), the files that use the package, and one test file. When: Required in Chat mode without package files. In Run mode the current repository supplies them.
- What should I use for “How you run tests and build”? [optional] Optional. Such as npm test && npm run build. Leave it and the AI looks for it. Authored default: find it in the repo

## LazyCoder delivery guide (delivery-guide-v1)
1. Read the latest request, source material and authored requirements first. Ask only for missing facts. Check that this host can create the promised format; use only a fallback explicitly allowed by the authored recipe. If neither is available, explain the gap before starting. Do not promise a rendered film, editable deck or working file when you can only provide its script or outline.
2. Create the complete result in the authored output specification, preserving source facts and the latest agreed scope. Keep assumptions and missing information explicit. Do not silently omit required parts or leave unresolved ingredient markers. Intentional blanks in a reusable template are different from unanswered recipe inputs.
3. Check the actual result against every authored check, including source facts, counts, dates and required sections. Where tools allow it, inspect the actual saved file and compare it with the answer. Record which checks ran, which failed and which still need human or destination review. A filename, render, successful command or preview alone does not prove the promise was met.
4. Hand over the complete editable file, or the complete copyable fallback explicitly allowed by this recipe. Say which delivery you used and any unresolved limitations. Do not report a file as attached, imported, sent or published unless that action actually succeeded. Keep private inputs and output in this assistant; never send them to LazyCoder.
Use existing authorization for ordinary work. Before any additional paid generation, external write or publishing step, check that the current request authorizes that exact action and cost. If it does not, finish the useful authorized draft and ask at that boundary. Never silently retry or replace an ambiguous paid job.
The authored recipe and latest safe scope remain authoritative. This guide grants no new tools, permissions, provider access or claim of successful execution.

## Authored skill instructions
## 1. Outcome
Upgrade the package below to the target version and handle every breaking change that touches this code, then report in the sections set out in part 6. Done means every check in part 7 passes: the installed version is the target, every breaking change this code uses is fixed or listed, nothing that passed in the baseline now fails, no test was weakened, and the report says exactly what was run and what was not. If that can't be reached, done means stopping by the stop rule in part 5 with a report that says why.

## 2. Context
Package: [PACKAGE NAME]
Target version: [TARGET VERSION]
The repo or package files: [YOUR REPO OR PACKAGE FILES]
How the checks are run: find it in the repo

Who it's for: the person who owns this code and whoever reviews the change. They need an upgrade they can merge with confidence, a list of what changed and why, and a quick way back if it goes wrong.

How you work (pick one; the report says which):
- **Run mode**: you can open the files in this repo and run commands in it (a coding agent, or a chat app with code tools connected to the repo). Make the changes and run every command yourself.
- **Chat mode**: anything else, including a plain chat and a code sandbox where you can only run pasted snippets. Write every change as a patch or full file, and for every step that runs something, give the exact command and the result the person should see. The report then starts with the line "Nothing was run here. The results below are what to expect, not what happened."
Never report a command's output that you did not see.

Blank fill-ins: a value above that still reads as a capitalised placeholder in square brackets (such as [TARGET VERSION]) was left blank.
- No package name: reply only "No package name came through. Say which package to upgrade, and send again."
- No target version, or "latest": use the latest stable release (no alpha, beta or release candidate). In Run mode, look it up with the package manager. In Chat mode, name the latest version you know and mark it "(check this is still the latest)".
- A target version that doesn't exist or is older than the installed one: stop and say so.
- No repo or files: in Run mode, use the repo you are in. In Chat mode with no package file pasted, reply only "No package file came through. Paste your package file, your lockfile and the files that use the package, and send again."
- No lockfile in Chat mode: take the current version from the package file's range and mark it "(range, lockfile not given)".
- No check commands ("find it in the repo" or blank): look in the package file, Makefile, CI config or README for the test, build, lint and typecheck commands, and name the ones you used. In Chat mode without them, give the most likely commands and mark them "(guessed, check)".

## 3. What to pull out
- The package manager and lockfile (npm, pnpm, yarn, pip, Poetry, uv, Bundler, Cargo, Go modules…).
- The current version: the version actually installed, from the lockfile, not only the range in the package file.
- Every major version between current and target, and the release notes or migration guide for each.
- The breaking changes and deprecations in those notes, and where this code uses each affected API, option or import.
- Peer dependencies, runtime minimums (such as the Node or Python version), and tools whose own version ranges exclude the target (type definitions, plugins, linters, build tools).
- Version strings outside the package file: CI config, Dockerfiles, .nvmrc, .tool-versions.

Edge cases:
- Release notes you can't open (no web access, or none published): use what you know and mark each such change "(from memory, check the notes)". If you don't know a version's notes, say "Notes not known for <version>" and list no changes for it. Never invent a version number, option name or changelog entry.
- A peer or tool that doesn't support the target yet: upgrade it in step if a compatible version exists; if none exists, stop (part 5).
- An official codemod or migration tool: run it (in Chat mode, give the command and the files it should change), then review its changes by hand.
- Tests that already fail in the baseline: record them; they are not yours to fix and never count against the upgrade.
- Little or no test coverage where the package is used: first add a few small tests that pin today's behaviour there. These pinning tests are part of the upgrade; list them in their own row under Changes by file.
- A monorepo or several package files: upgrade the package everywhere it is listed, to one version, and list each place.
- Uncommitted changes in the working tree (Run mode): stop before changing anything and say so; never stash or discard someone's work.
- The upgrade changes behaviour users would notice (output, defaults, timing): keep today's behaviour if the new version allows; if not, list it as a decision for the owner.

## 4. Steps
Each step that runs something: in Run mode, run it and record what you saw; in Chat mode, write the command and the result it should show.
1. Read the package file, the lockfile and the code that imports the package.
2. Safety net: confirm the working tree is clean, then create a branch named upgrade/<package>-<version>.
3. Baseline: before changing anything, install, then run tests, build, lint and typecheck, and record the pass and fail counts and the names of any failures. Run the package manager's security audit if it has one, and note the count.
4. List every major version between current and target, read the notes for each, and list the breaking changes.
5. Search the code for each breaking change and list the affected files and lines. Add pinning tests where coverage is thin, and run them green on the old version before upgrading.
6. For each major version in order: update the version and any peers that must move with it, install so the lockfile is regenerated, run the codemod if there is one, fix the code, config and types, then run tests, build, lint and typecheck. When they are as green as the baseline, commit with the message "Upgrade <package> to <major>" (in Chat mode, give that commit command). Fix failures before moving to the next major.
7. Confirm the installed version with the package manager's list or why command (not the package file) is the target, and that only one copy is installed if the package must be single.
8. Update version pins outside the package file to match, where they refer to this package or its required runtime.
9. Run the full checks and the security audit once more, compare with the baseline, write the report, then run the self-check.

## 5. Rules
- Never change code before the baseline, and never move to the next major until the current one is green and committed.
- Never weaken, skip, delete or loosen a test, assertion, lint rule or type to get a pass. If a test fails because the package's behaviour really changed, fix the code to keep today's behaviour, or list it as a decision for the owner.
- If a failure points to a bug that was already there, report it under suspected bugs; never bend an assertion to hide it.
- Change only what the upgrade needs: the version bumps, required peers, code, config and type fixes, codemod changes and pinning tests. No unrelated refactors, renames, formatting or other dependency bumps.
- Keep the lockfile and commit it with each step; never delete it to force a fresh resolve unless the package manager's own docs say to, and then say so.
- Stop rule: stop and report when the same failure survives 3 fix attempts, when a required peer or runtime has no compatible version, when the fix needs a product decision, or when hand edits pass about 15 files (codemod changes are counted separately and listed by count). Go back to the last green commit (or the baseline if there is none), keep the branch, and set the status to "Stopped: <reason>", with what you would try next.
- Facts: cite each breaking change with the version and the source (release notes or migration guide with its link, or "(from memory, check the notes)"). Name only files, functions and commands that exist here.
- Write for a reviewer: plain words, short sentences, code in fenced blocks with the language named.

## 6. Output
In Chat mode, the first line is "Nothing was run here. The results below are what to expect, not what happened." Then use these sections in this order. Write "None" under any that is empty.
1. **Status**: one line, exactly one of "Upgraded" (Run mode only), "Upgrade written, not run" (Chat mode) or "Stopped: <reason>"; then the mode, the package manager, and the commands used for tests, build, lint and typecheck.
2. **Versions**: a table with the columns Package | Before | After | Why it moved. The upgraded package first, then each peer or tool that moved with it. In Run mode, Before and After are the installed versions you saw. In Chat mode, Before is from the lockfile (or marked "(range, lockfile not given)") and After is "Not run (target <version>)".
3. **Breaking changes that touch this code**: a table with the columns Version | Change | Source | Files affected | What was done, one row per breaking change this code uses. Then one line: "<n> other breaking changes in these versions don't touch this code."
4. **Changes by file**: each changed file with one line on why, pinning tests in their own row, then a unified diff of the code and config changes (lockfile changes summarised, not shown; codemod changes summarised by count with one example).
5. **Evidence**: a table with the columns Step | Command | Tests | Build | Lint | Typecheck. Rows: baseline, one row per major step with its commit, final run; then the installed-version check and the security audit (before and after counts). In Run mode, fill it from what you saw. In Chat mode, put "Not run" in every result cell and add one line under the table per row saying what the person should see.
6. **Commands in order**: every command to reproduce the upgrade from a clean tree, in one fenced block.
7. **Rollback**: the commands to undo it, in one fenced block (for example switching back to the main branch, deleting the upgrade branch, and reinstalling from the old lockfile).
8. **Risks, notes to check and manual follow-ups**: behaviour changes users could notice, changes marked "(from memory, check the notes)", versions whose notes weren't known, suspected bugs, and anything a person must do by hand.
9. **Commit message and PR text**: a commit subject under 72 characters, then a PR description with the version change, the breaking changes handled and how it was tested. In Chat mode, the PR text says the checks have still to be run.

## 7. Self-check
Before replying, check each of these and fix any failure:
- The mode is right (a sandbox with pasted code is Chat mode), and in Chat mode the first line is "Nothing was run here…", the status is "Upgrade written, not run" (or "Stopped: <reason>" when a stop rule applied), and no cell, including After, claims a result.
- The baseline was taken before any change, and every failure in the final run that is not in the baseline is fixed or explained.
- Every major version between current and target has its notes cited, marked "(from memory, check the notes)", or listed as not known.
- Every breaking change this code uses has a row, every affected file is in Changes by file, and the count of the rest is given.
- In Run mode, the installed version shown is the target, from the lockfile or package manager, and each green major has its commit.
- No test, assertion, lint rule or type was weakened, skipped or deleted.
- The diff holds only what the upgrade needs, and every file, option and command you name exists.
- Every section of part 6 is present, in order, with the rollback commands.
Then reply with the output only, ending with one line: "Checked: <Upgraded | Upgrade written, not run | Stopped>, <before> → <target>, <n> breaking changes handled, <n> files changed."

## 8. Setup
With a coding agent that has your repo (Claude Code, Codex, Cursor, or ChatGPT with code tools connected to the repo), it runs the baseline, the upgrade, the tests, lint and typecheck itself and reports what it saw. In a plain chat (ChatGPT, Claude, Gemini or Grok), paste your package file, your lockfile, the files that use the package and one test file: you get every change as a patch, with the commands to run in order and what each should show, and the reply says plainly that nothing was run. Release notes are checked where the app can browse; elsewhere each change is marked to check.

Paste the result after your assistant creates it. This optional check stays in this tab and is not sent to LazyCoder.