Prompt Library

You are helping me bring {{project}} up to date. Read the dependency manifest and lockfile, then produce a table of every direct dependency that is more than one major version behind. For each one give: current version, latest version, and the concrete breaking changes I need to handle.

Order the work so the build stays green after every step, and flag anything that must be upgraded together (peer dependencies, coupled packages). Do not suggest upgrades for packages that are already current, and tell me if any package is unmaintained.

Write a step-by-step migration plan to upgrade {{library}} from {{from}} to {{to}} in {{project}}.

For each step give the exact command or code change, what is most likely to break, and how to verify it worked. Put the risky and codemod steps last, keep the test suite passing at every checkpoint, and call out anything that cannot be done incrementally.

Search {{path}} for usages of APIs that are deprecated in {{library}} {{version}}.

For each hit report file:line, the deprecated call, and the modern replacement, with a diff-ready before/after. Group by replacement so I can apply similar changes together, and skip matches inside vendored, generated, or build output directories.

List every dependency in the manifest that is never actually imported anywhere in the source, config, or CI.

For each, show the evidence and whether removal is safe. Watch specifically for side-effecting imports, packages only used from scripts or CLI entry points, type-only packages, and anything referenced by build tooling or config files. When you are unsure, say so rather than guessing.

Summarise the changes to {{library}} between {{old}} and {{new}} that affect us. Read the changelog and release notes, then group the findings into: breaking changes, new deprecations, and behaviour changes that could silently alter output.

Ignore cosmetic and documentation-only changes. For each breaking item, name which of our files it most likely touches and what the fix looks like.

Review this diff as a staff engineer. Focus on correctness, edge cases, error handling, and regressions. For each finding give file:line, severity (blocker / major / minor), why it matters, and a concrete fix.

Do not restate what the code does, and do not comment on formatting or style. If you genuinely see nothing wrong, say so plainly instead of inventing concerns.

Compare the public interface before and after this change.

Flag anything that would break existing callers: renamed or removed exports, newly required parameters, changed return types, altered thrown errors, narrowed accepted inputs, and changed default values. For each, list the affected call sites in this repository.

Read the surrounding code and existing conventions in {{path}}. Then review this change and flag anywhere it diverges: naming, error handling, module boundaries, test style, logging, and dependency choices.

For each finding, quote the existing pattern it should follow so the correction is obvious. Prefer the conventions already in this repository over your general preferences.

Review this code for async and concurrency correctness: unawaited promises, missing error propagation, race conditions, unbounded parallelism, cancellation that never happens, and leaked resources.

For each issue give file:line, the specific interleaving or failure scenario that triggers it, and a fix. Rank them by how likely they are to appear in production rather than in theory.

Review this change for anything that could destroy or silently corrupt data: writes without a transaction, destructive or irreversible migrations, deletes without guards, overwrite-on-conflict, truncated output, and missing rollback.

Rank each finding by blast radius and give a safer alternative. Call out explicitly anything that would be unrecoverable once run.

Identify the highest-risk code in {{path}} that has no test coverage. Rank by risk — complexity multiplied by blast radius — not by how easy it is to test.

For each gap, describe the branch or failure mode that is untested and the first test you would write. Do not propose tests for trivial getters, pure formatting helpers, or generated code.

Write tests for this function. Cover the happy path, boundary values, empty and null inputs, and error cases. Match the existing test style in this file and use the same helpers and fixtures.

Explain what each test protects against, and flag any behaviour you discovered that looks unintentional rather than enshrining it as correct.

Here is a bug report and the fix. Write a test that fails before the fix and passes after it.

Make it minimal and deterministic — no sleeps, no network, no reliance on the current time or on test ordering. Name the test after the observed behaviour, not the implementation, so it stays valid if the code is refactored.

Review this test suite for flakiness: reliance on wall-clock time or timezones, dependence on execution order, shared mutable state between tests, real network or disk access, unseeded randomness, and arbitrary waits or retries.

For each problem, explain the condition under which it fails intermittently and how to make the test deterministic.

Review these tests for assertion strength.

Flag tests that assert truthiness instead of the actual value, snapshot-everything tests that no one reviews, tests that would still pass if the feature were deleted, and tests so heavily mocked that they only prove the mocks work.

Rewrite the three weakest tests to assert real behaviour, and be honest if a test adds no value and should be deleted.

Compare README.md against the actual code, scripts, and configuration.

List every claim that is now wrong, missing, or misleading: install steps, available scripts, environment variables, defaults, screenshots, and links. Give the corrected text for each.

Prefer deleting stale sections over inventing new ones, and do not add features to the README that do not exist.

Write documentation for {{path}} aimed at the next person who has to change it.

Cover what the module is responsible for, its public surface, the invariants callers must respect, and its failure modes. Include one short usage example that actually compiles and would pass lint.

Skip line-by-line commentary — describe intent and contracts instead.

Find documentation that no longer matches the code: comments describing removed behaviour, TODOs that are already done, docs referencing deleted files, flags, or functions, and examples that would not run today.

Report file:line, what it currently claims, and what it should say instead. Also flag any doc that is now actively misleading rather than merely outdated.

Write an architecture decision record for this decision.

Use these sections: Context, Decision, Alternatives considered, Consequences (both good and bad), and Status. Be specific about the constraints that drove the choice, so a future reader can tell whether those constraints still hold and whether the decision should be revisited.

Write a migration guide for this breaking change.

Show a before/after example for each affected usage, explain how someone can find the affected call sites in a large codebase, and describe how to verify the migration actually worked.

Assume the reader has hundreds of call sites, no time, and will only skim — put the mechanical steps first and the explanation after.

Refactor this code to be simpler without changing observable behaviour. Reduce nesting, remove redundant state, collapse needless abstraction, and name things by intent rather than by type.

Return the refactored code plus a list of what you changed and anything you deliberately left alone. Do not change the public signature, and do not fix unrelated issues you notice — list those separately instead.

Find duplicated logic across {{path}}.

Group near-identical blocks, and for each group say whether they are truly the same concern or only coincidentally similar. Only propose extraction where the duplication is real — premature abstraction is worse than repetition.

For each genuine case, sketch the shared abstraction and note what would have to change in each caller.

Identify code in {{path}} that is unreachable or unused: unreferenced exports, always-false branches, feature flags that are never set, compatibility shims for versions we no longer support, and commented-out blocks.

For each, show the evidence that it is dead and say whether removal is safe. Be explicit about anything that is exported publicly and might be used outside this repository — do not assume it is dead just because it looks unused here.

Break this function down. Identify its distinct responsibilities, the hidden inputs and outputs, the shared mutable state, and the parts that are hard to test.

Propose a decomposition into well-named units, then implement it keeping behaviour identical and the existing tests passing. If a unit cannot be tested in isolation, explain what would need to change first.

Replace the outdated pattern in this code with the modern equivalent for {{stack}}.

Keep the change mechanical and behaviour-preserving. Update every call site in the repository, list the files you touched, and flag anything that needs a manual review afterwards.

If the old pattern is load-bearing in a way the modern equivalent does not cover, stop and tell me instead of forcing the change.

Review the dependency tree for known-vulnerable or unmaintained packages.

For each risk report the package, the vulnerable version range, whether our lockfile actually resolves to an affected version, and the smallest upgrade that fixes it.

Prioritise by exploitability in our context — a vulnerable parser we only ever feed trusted input is not the same as one exposed to user data. Say when a finding is not reachable from our code.

Scan the repository for secrets that should not be committed: API keys, access tokens, private keys, connection strings, and credentials sitting in fixtures, tests, or CI configuration.

Report file:line with the value redacted. Also check git history for anything that looks like a secret which was later removed — removing it from the working tree does not remove it from history. For each real finding, say whether it needs to be rotated rather than just deleted.

Review where untrusted input enters this code.

For each entry point, trace what happens to the input and flag: missing validation, unsafe parsing, file paths or shell commands built from user input, and error messages that leak internals.

Give a concrete fix per finding and say which are exploitable versus merely poor practice. Do not flag internal functions that only ever receive already-validated data.

Review the authorization checks on these endpoints.

For each one state who is allowed to call it, and whether the check can be bypassed, forgotten on a newly added route, or is enforced only in the UI.

Flag any object-level check that trusts an identifier supplied by the request, and any place where authorization is implemented by filtering results after fetching them rather than by querying within the caller's scope.

Find injection sinks in {{path}}: string-built SQL, shell command construction, HTML rendering, template evaluation, and deserialisation of untrusted data.

For each, show the tainted flow from source to sink, explain what an attacker could achieve, and name the safe API to use instead.

Distinguish between sinks that are genuinely reachable from untrusted input and those that only ever see constants or configuration.

Turn these commits into a changelog for {{version}}.

Group into Added, Changed, Fixed, and Removed. Write for users rather than committers — describe the effect, not the implementation detail. Drop internal-only churn such as refactors and dependency bumps that users cannot observe.

If anything is a breaking change, put it at the top with the migration step.

Draft release notes for {{version}} aimed at people deciding whether to upgrade today.

Lead with the single headline change. Include the upgrade command, list breaking changes with their migration step, and link each notable fix to the issue it closes.

Keep it under a screen long — if it is longer, the release is doing too many things and you should tell me that.

Given these changes to the public API, decide the next semantic version and justify it.

Point to the specific changes that force major, minor, or patch. If the answer depends on whether something counts as public — an exported helper, an undocumented but reachable path, a type signature — say so explicitly and give me both answers.

Do not default to a patch bump to avoid the conversation.

Read this repository's CI configuration, build scripts, and recent releases. Draft a pre-release checklist that reflects what actually has to happen here.

Include migrations, generated files that must be regenerated, changelog and version bumps, deploy ordering, cache invalidation, and anything that must be done in a specific sequence.

Flag any step that is currently manual and easy to forget, and say which ones could be automated.

Write a deprecation notice for {{thing}}.

Cover what is being deprecated, what replaces it, and the timeline — when it starts warning, and when exactly it stops working. Include a before/after example for the migration.

Assume most people will not read this until their build breaks: put the migration step somewhere it cannot be missed, and say plainly whether the old behaviour can be kept behind a flag in the meantime.

Explain the architecture of this repository to an engineer joining the team.

Cover the entry points, the main modules and what each is responsible for, how data flows through the system, and where the sharp edges are — the parts that surprise people or break if touched wrongly.

Finish by naming the two or three files worth reading first, and say why those.

Write a CLAUDE.md / AGENTS.md for this repository so an AI assistant can work in it without breaking things.

Include: the exact build, test, and lint commands (verified against the repo, not guessed); conventions that are not obvious from reading the code; files that must never be edited by hand because they are generated; and any gotchas that have caused real mistakes.

Keep it short and factual. Only include rules that are actually true here — a guide full of generic advice gets ignored.

Create a task-to-file map for this repository.

For the twenty most common changes a contributor would make — add a route, add a component, change the schema, add a config option, add an endpoint, write a migration — name the files to touch and the pattern to follow.

Base every entry on an example that already exists in the codebase, and cite it. Do not invent a structure the repository does not have.

Write a CONTRIBUTING quickstart for this repository using only commands that actually work here.

Include prerequisites, setup, running the app locally, running the test suite, and what a good pull request looks like for this project.

Derive every command from the repository's own scripts and CI configuration rather than from convention. If a step is missing or broken, flag it instead of documenting something that will not work.

Write handoff notes for this project.

Cover what is finished, what is half-done and exactly where it stopped, what is deliberately not done and why, known bugs with reproduction steps, and the next three things you would work on.

Assume the reader has no context, will be paged about this in a month, and cannot ask you anything. Be blunt about the parts that are fragile.