This explains the procedure for reviewing changes that update libraries and, when necessary, handling migrations between versions and responding to breaking changes. The explanations use Node.js for concrete examples of commands and files, but please read them as appropriate in light of the libraries actually changed and common practices for the programming language.
Target
- Library update pull requests created by dependabot or renovatebot
- Library update pull requests created by humans
Checking the Execution Environment
Before starting the review, confirm that your execution environment matches one of the following. If it does not match, do not create a report; report that fact and stop.
- The model is Claude's Opus tier or above (Opus, Fable, Mythos, etc.). Lower tiers such as Sonnet and Haiku do not qualify even if they are a newer generation
- The model is a Codex flagship of Sol tier or above (Sol, Astra, etc.) and the reasoning effort is medium or higher. Lightweight tiers such as Luna and Terra, and models from generations before Sol, do not qualify
Chapter Structure and Work to Be Performed
Create the report following the chapter structure shown below. If you referenced external documents, specify their URLs.
At the beginning of the report, write your own Agent name and model name as the author in the following format:
Reviewer: Claude Code (claude-opus-5-5)
1. Overview of the Library
Investigate the overview of the library. Check the README in the library and the documentation on the official site, and report what the library is intended to achieve and what purposes it is used for.
2. Version Information
Read package.json and report the version information before and after the change made by this pull request, along with the release date and time of each.
Investigate npmjs.com and GitHub, and report whether there is a major version update. This pull request may be updating a patch version or minor version, but that may not actually be the latest version, and there may be a major version update. In a major version update, the library name may be changed, or the repository may be transferred to an organization.
3. Confirming the Scope of Changes
Understand what was changed by this pull request and its scope.
From the lock file diff, list the packages that were updated, added, or removed.
- Even if the number is large, clearly indicate all major change targets without omission
- If changes to packages whose relationship to the target library being updated is unclear are included, note that fact
- At this point, do not make a definitive judgment about safety or the scope of impact. Treat it as a caution to be confirmed in subsequent sections.
Example: For npm's package-lock.json ,gh pr diff や git diff to get the lock file diff. The surrounding context of an individual package can be checked with grep -C15 '<パッケージ名>' package-lock.json .
4. Library dependencies
Check the library's dependencies.
Read package-lock.json and check the dependencies.grep -C15 ライブラリ名 package-lock.json A command like this is effective.
- List any other libraries that depend on that library.
- List any other libraries that that library depends on.
5. Where the library is used and version information
In the repository, investigate where that library or runtime environment is referenced or specified.
Include not only import statements and require statements, but also places where the version is specified, such as configuration files, Dockerfiles, CI configurations, and development environment settings.
git grep ライブラリ名 In addition to that, also search by version number and package name.
Compile the investigation results into a list of reference locations, organized by file. Use this list as input for section 7-2 "Version consistency check." Files read in other sections such as sections 3 and 4 may also contain version specifications, so be sure to include them in the list without omission.
6. Summary of changes
Summarize the changes. Refer to the library's official website and GitHub, and read the release notes, changelog, and migration guide in detail to understand the changes. Among feature additions and API specification changes, extract and report changes that seem particularly relevant to features used on the application side. You need to check the changes in all versions contained between before and after the change, one by one.
Important: The description written in the pull request overview may be incorrect, so ignore it. Refer only to the current code and the diff.
7. Updating code and configuration
Check whether application code or configuration files need to be modified due to updating the library or runtime environment. If necessary, propose creating a pull request.
Check by distinguishing the following two perspectives.
7-1. Code modifications accompanying API or specification changes
If the library's API has changed, the application code needs to be modified.
If you cannot determine the correct modification method from the release notes or changelog alone, also check the actual change diffs in GitHub's commits and the official documentation. Also report those changes.
7-2. Version consistency check
Check whether the version number changed in the PR is also referenced elsewhere in the repository.
Investigate using the following steps:
- Identify the changed version number from the PR diff
- Identify both the pre-change and post-change versions
- Determine the type of the update target
- npm packages, runtimes, Docker base images, etc.
- Investigate the entire repository to see whether there are other places that should be updated at the same time to match the version updated in the PR
- Also check the list of reference locations created in "5. Library usage locations"
- In addition, for example, when updating the Node.js runtime, the versions need to match between the local development environment and the production environment. Check not only the Dockerfile but also engines and packageManager in package.json and package-lock.json, .nvmrc, CI configuration, etc.
- The examples of check targets above are only representative examples. Think carefully about whether there are any omissions depending on the situation
- If there are places where an old version remains, report and fix them
Note:
- Do not judge that there is "no problem" based only on an exact-match search for the version string. It may be managed with a range specification (
22.x, etc.) or an alias - Do not judge the correspondence between related versions by guesswork; confirm it based on official documentation or the actual distributed artifacts
- Example: the npm version corresponding to a Node.js version
- If related versions cannot be confirmed due to restrictions on external access, etc., report that as "unconfirmed" and encourage manual confirmation
8. Interesting updates
If there are any interesting updates, please report them. For example, content such as the following:
- Implementation of new features or invention of concepts that could also be applied to the application
- Implementation of interesting features that leverage new features of a programming language or runtime environment
- Changes in a library's development structure
9. Investigation of past failures
Investigate whether any problems related to the library you are trying to update this time have ever occurred in this repository. Search pull requests and issues by the library name, and report any cases that match the following examples.
- A pull request was closed without being merged
- It was merged, but a defect occurred and it was reverted
If a problem is found, check whether it has been resolved.
Final check
Consistency check between sections
Review the entire report cross-sectionally and check whether there are any contradictions or omissions between sections.
- Whether the files read or touched in a certain section are included in the reference location list in section 5
- Whether all the reference locations listed in Section 5 have been verified in the consistency check in Section 7-2
- Whether there is any contradiction between the dependency information confirmed in Section 4 and the summary of the changes in Section 6
- Among the change packages listed in Section 3, whether there are any whose rationale or intent is not explained in the release note summary in Section 6. If there are changes that are not explained, confirm whether they are included as unexplained changes in the review notes
If any discrepancies are found, please correct the relevant section.
Confirmation of output format
Please review the report format. If the output destination is a GitHub comment field, output in a format suitable for it.
Tips: Format suitable for a GitHub comment field
Issue numbers and pull request numbers of external repositories should be written in full URL format
Instead of #12345, https://github.com/:owner/:repo/issues/12345 write it as such. Add half-width spaces as appropriate so that the URL does not stick to the characters on either side. This way, it will be rendered as a clickable link in a web browser.
Add labels to pull requests to explain the status
If the output destination is a GitHub pull request, please add appropriate labels after submitting the report. For example, add the "security" label to pull requests for important security updates such as those for which a CVE number has been issued.
Report if permissions are insufficient
If you are Claude Code running on GitHub Actions, you may not have been given sufficient permissions to carry out the task. Please report the necessary permissions so that the repository administrator can handle it appropriately.
- Details of the task you were trying to execute
- The permissions that were insufficient. For example
- Claude CodeのallowedTools
- permissions of the GitHub Actions job