Assigned by the coordinator of the dependency-update skill, review the specified single pull request and post a report as a comment on the pull request. The update targets may include libraries as well as Docker images, GitHub Actions, and runtimes. Examples of commands and files are shown using Node.js libraries, so reinterpret them in light of the actual update target and the common practices of its ecosystem.
File structure
{このSKILL.mdがあるディレクトリ}/
SKILL.md ← この手順書
TEMPLATE.md ← レポートの形
Prerequisites for running this skill
- The conditions of the execution environment are the same as the model conditions independency-update skill "Execution environment confirmation". Confirm them yourself before starting the review; if they are not met, do not perform the review or post the report, report the unmet conditions, and exit
- You cannot ask the user questions. Write anything you cannot determine in the report and your report to the coordinator
- Follow the coordinator's instructions for the location of the pull request, the label names, where to read the code, the working directory, and the language of the report
- Do only the review, limited to posting comments and, when instructed, applying labels. Do not modify code, commit, push, or create new pull requests. When fixes are needed, write them in the report
- Subagents handling other pull requests in the same repository may be running concurrently. Do not change anything outside the specified working directory
Investigation
Investigate what to write for each section of the report in the following order. The description in the pull request's overview may be incorrect, so do not use it as the basis for the changes. Base your findings on the code, the diff, and official documentation. When referencing external documentation, write its URL in the report.
Overview of the update target
Read the README and the official website documentation to determine what it is meant to achieve and what purposes it is used for.
Version information
Investigate the versions before and after the change and their respective release dates. Also check whether the update target is the latest version and whether there are any major version updates beyond it. Major version updates may involve name changes or repository transfers.
Change scope
List the packages updated, added, and removed from the lock file diff. Even if the number is large, list all major change targets without omission. If changes to packages whose relationship to the update target is unclear are included, note that fact. At this point, do not conclude on safety or impact scope; treat them as points to verify in later sections.
Example: for npm package-lock.json , take the lock file diff from the pull request diff; the surroundings of individual packages can be checked with grep -C15 '<パッケージ名>' package-lock.json .
Dependencies
From the lock file, list the other packages that depend on the update target and the packages that the update target depends on.
Usage sites and version specification sites
Within the repository, list file by file the places where the update target or the runtime environment is referenced or specified. Include not only import and require statements but also places where versions are specified, such as configuration files, Dockerfiles, CI settings, and development environment settings. In addition to searching by name, also search by version number. If a file read in another section specifies a version, include it in this list. This list serves as input for checking version consistency in "Code and configuration updates".
Summary of changes
Read the official website, GitHub release notes, changelog, and migration guide, and check one by one the changes in all versions between before and after the change. Among feature additions and API specification changes, extract those that seem relevant to the features used on the application side.
Code and configuration updates
Check by distinguishing two perspectives.
- Code fixes accompanying API or specification changes. When the correct way to make the change cannot be determined from the release notes or changelog alone, also read the GitHub commit diffs and official documentation
- Version consistency. Check whether the version number changed in the pull request should also be aligned in other places in the repository
- Identify the version numbers before and after the change from the diff
- Determine the type of the update target. It may be an npm package, a runtime, a Docker base image, etc.
- Search the entire repository for places that should be aligned and updated at the same time. Check the list in "Usage sites and version specification sites". For example, when updating the Node.js runtime, the versions must be aligned between the local development environment and the production environment, so check not only the Dockerfile but also engines and packageManager in package.json and package-lock.json, .nvmrc, CI settings, etc.
- Write in the report the places where the old version remains
Do not conclude that there is no problem based only on an exact-match search for the version string. Versions may be managed with range specifications or aliases. For the correspondence between related versions, such as npm corresponding to Node.js, do not guess; base it on official documentation or actual distributions. When it cannot be confirmed due to external access restrictions, state that it is unconfirmed.
Interesting updates
Pick up anything such as implementations of new features or inventions of concepts that could be applied to the application, implementations that take advantage of new features of programming languages or runtime environments, or changes in development organization.
Past failures
Investigate whether any problems related to the update target have occurred in this repository by searching pull requests and issues with the name of the update target. Examples include cases that were closed without being merged, or merged but then reverted due to defects. If any are found, check whether they have been resolved.
Re-review of a pull request containing fix commits
When the commander gives you the SHA of a fix commit and the location of a document listing the places to be aligned, in addition to the investigation above, verify that the diff of that commit is confined to only the places listed in that document. If it is not confined, do not make the conclusion "mergeable without fixes".
Final check
Across the entire report, check for contradictions or omissions between sections, and if any are found, fix the relevant section.
- Whether the files read in other sections are included in the list of "usage sites and version specification sites"
- Whether all the reference sites in the list have been verified in the version consistency check
- Whether there are any contradictions between the information in "Dependencies" and the "Summary of changes"
- Whether, among the packages listed in "Change scope", there are any whose rationale or intent is not explained in the "Summary of changes". Changes that are not explained should be written in the notes as unexplained changes
Report output
TEMPLATE.md and create a report with that structure, then post it as a pull request comment. For the Reviewer, write your own Agent name and model name. For how to write text that will appear on GitHub, follow thekuden:github skill. For issues or pull requests in other repositories, write the full URL rather than the number. With only the number, it becomes a link to the same number in the repository under review.
When the commander gives you the label names, after posting, add the review request label, and for reports judged to be security updates, also add the security update label. When the conclusion is "judgment deferred", do not add the review request label.
Report to the commander
Write briefly. Details are in the report, so do not repeat them.
- The URL of the posted comment and the conclusion
- Labels added. Only when added
- Whether there is content in the "Interesting updates" section
- Things that could not be confirmed and things that could not be done due to lack of means
- Points that were ambiguous in the procedure