For the repositories written in the launch prompt, advance dependency update pull requests created by dependabot or renovate, in the order of review, fix, and merge, up to the automation stage determined per repository. Dependencies include, in addition to libraries, Docker images, GitHub Actions, and runtimes.
This session becomes the commander. The behavior as the commander is tokuden:orchestrator load the skill and follow its criteria. The commander does not read pull request diffs or repository code.
The work is left to subagents that execute the following skills.
| skill | Work | What to read |
|---|---|---|
| dependency-update-report | Review one pull request and post a report as a comment | The pull request diff and the repository code |
| dependency-update-fix | Fix one pull request within the scope stated in the repository's documents and push | Review comments, the repository's documents, and code |
For subagents, specify a model of Opus tier or higher, and if the launch prompt contains a label name, convey that as well. Only the commander performs merging, and subagents must not merge.
Instructions in the launch prompt take precedence over the descriptions in this skill.
In this skill, "review comment" refers to a comment posted in the form of dependency-update-report's TEMPLATE.md. It is identified by the title on the first line # Dependency update report and by the Reviewer line and the conclusion line. Human reviews and comments in other formats are not included.
How far a pull request has progressed is determined from review comments and comments posted by the fix subagent. Comments by the fix subagent are identified by the first-line title defined by dependency-update-fix, distinguishing what was fixed from what was out of scope. Labels are not used for determination. Labels are marks to show status to humans, and are applied only when a name is specified in the launch prompt.
Values received from the launch prompt
The values received from the launch prompt are the following three: the target repositories and the notification destination are required, and the label name is optional. The launch prompt is created by the dependency-update-setup-routine skill.
- The list of target repositories and the automation stage for each repository. The automation stage is a value indicating how far to advance automatically, and is one of "up to review," "up to fix," or "up to merge." For pull requests in repositories not in the list, do not perform reviews, CI re-runs, or rebase requests
- Label name. It may not be written. For the three items review request, merge approval, and security update, when they differ per repository, it is written on that repository's row. Used when the repository uses labels to indicate state
- Notification destination. A place to inform humans of merge plans and results and interesting updates, where replies can be consolidated into one thread. For example, a Slack channel
When a required value is missing, in an environment where the user can be interacted with, ask and fill it in. When running unattended, report the missing value and exit.
Checking the execution environment
Check before starting the process. If not satisfied, do nothing, report the unsatisfied conditions, and exit.
- Your own model is of a tier equal to or above Opus (Opus, Fable, Mythos, etc.). Lower tiers such as Sonnet and Haiku do not satisfy this even in newer generations
- Can launch subagents of a tier equal to or above Opus
- Have a means to read GitHub pull requests and post comments. Find and use the integration means available in this session yourself
Fixes require a means to push to a branch, and merges require a means to merge and a means to post to the notification destination. Do not perform steps for which no means exists, and write that fact in the completion report.
CI required for merge
Among the protection rules applied to the base branch of a pull request, the checks specified as required for merge are treated as the CI required for merge. This is the same whether specified via branch protection or rulesets. The list of required checks can be read from the base branch information even without permission to read the protection rule settings. Checks that are not required do not block merge even if they fail, and are not re-run. For repositories where no required checks are specified, and when the specification could not be read, treat all CI as required. When the specification could not be read, write the reason in the completion report.
1. Review
Target
Among the open pull requests created by dependabot or renovate in the repositories in the list, those that fall under any of the following. If there are 0 targets, proceed to 2. Fix.
- There are no review comments
- The conclusion of the latest review comment is "pending decision"
- The dependency and version being updated differ from what is stated in the latest review comment. This applies when the bot has updated to a new version. Since the bot's rebase does not change the version, do not re-review
- The commit written in the latest comment of the subagent for the fix in 2 is included in the pull request, and that comment is later than the latest review comment. This is one that was carried over because CI could not be waited for after the fix. From that comment, read the location of the document listing the points to align with the commit SHA, and have it re-reviewed with the same CI waiting method as "2. Fix > After the fix"
- The latest review comment presupposes a fix commit (the SHA is in section 7-3), but that commit is not included in the pull request. This is the case when the bot has recreated it. Since a conclusion based on the fix cannot be used, review it again as a normal review.
Delegate to a subagent
Launch a new subagent for each pull request and have it run dependency-update-report. When handling multiple pull requests from the same repository in parallel, use a separate working directory for each subagent.
Things to include in the instructions:
- The location of the pull request. Repository name and number
- The label name. Only when it is in the launch prompt
- Where to read the code, and the working directory
- The language of the report. If specified in the launch prompt, use that; otherwise, the language of the launch prompt
- When re-reviewing a pull request that contains a fix commit, the SHA of the fix commit and the location of the document listing the places to align. Both are in the fix subagent's comment
Verify the report
Verify that the report has been posted as a comment on the pull request. When there is a label name, also verify that the label is attached, excluding those whose conclusion is "decision pending". The report's conclusion term, the security update line, and whether the "Interesting updates" section has content will be used in later steps.
2. Fix
Only fix pull requests in repositories whose automation stage is "up to fix" or "up to merge". Start after the review in 1 is finished. If there is a review subagent that does not finish, defer that pull request to the next run and proceed to fixing other pull requests.
Targets
Fix pull requests that satisfy all of the following. Search not only those reviewed in this run, but all pull requests with review comments in the repositories in the list.
- Created by dependabot
- The conclusion of the latest review comment is "fix needed"
- The dependency and version to update match those stated in the latest review comment
- All commits are by the bot
- There is no comment written by dependency-update-fix stating it is out of scope after the latest review comment
- There are no unretracted changes requested, objections to merge, or requests to hold by humans
Conditions that cannot be determined without reading the repository's documents are checked by dependency-update-fix before it starts work. For pull requests that do not satisfy them, the subagent changes nothing and reports by commenting on the pull request that it is out of scope and the reason. From the next run onward, it will not be a fix target until it is reviewed again.
Delegate to a subagent
Launch a new subagent for each pull request and have it run dependency-update-fix.
Things to include in the instructions:
- The location of the pull request. Repository name and number
- The label name. Only when it is in the launch prompt
- Location of the clone and the working directory
After the fix
After CI for the commit pushed by the subagent finishes, have it re-review in the same way as in 1. If a CI job required for merge fails, rerun that job once before the re-review. If CI does not finish after waiting 10 minutes, have it re-review on the next run.
3. merge
Merge only pull requests from repositories whose automation stage is "up to merge". After all subagent reviews and fixes are done,merge.md read and the commander merges accordingly. If any subagent has not finished, carry that pull request over to the next run and proceed with the other merges.
Notifications
Consolidate the posts from this run into a single thread at the notification destination. Make the first post the parent and post the rest as replies to it. Posts about merge plans and results are governed by merge.md.
When all merges are done, among the pull requests reviewed in step 1 of this run, compile the ones that have content in the "Interesting updates" section of the report into a single post and post it. Pull requests that contain fix commits and are re-reviewed, and those whose conclusion is "judgment deferred", are excluded. For each pull request, write the repository name, the name of the update target and its versions before and after the update, 2–3 lines summarizing the interesting updates, and the URL of the report comment. Also post pull requests from repositories whose automation stage is "up to review".
Next, compile the pull requests that were found in this run to require human judgment into a single post and post it. The following fall under this.
- Those whose review conclusion in this run was "fix needed" and which were not fixed in step 2. These are those from repositories whose automation stage is "up to review" and those that do not meet the conditions for step 2.
- Those that dependency-update-fix reported as out of scope in this run
- Those whose re-review conclusion after the fix in step 2 of this run is still "fix needed". No further fix commits are added.
- Those whose review conclusion in this run was "cannot merge"
For each pull request, write the repository name, the name of the update target and its versions before and after the update, a summary of what the report requested, the reason it was not proceeded with automatically, and the URL of the report comment. This serves as material for humans to decide whether to fix or close.
Do not post when there are no merge targets, no deferred pull requests as defined by merge.md, no interesting updates, and no pull requests requiring human judgment.
Things to observe
- Do not commit or push to the branches of dependabot and renovate pull requests, other than pushing one fix commit made by the step 2 fix subagent
- Process each pull request independently; if one fails, continue with the others
- For comments posted to GitHub, write the name and model name of the Agent that wrote it. Have subagents do the same.
Completion report
Briefly report the pull requests you posted reviews on, the pull requests you fixed, the ones you skipped because they were already reviewed, the ones you merged, and the ones that were merge candidates but you did not merge, along with the reasons. If there is anything you could not do because you could not access GitHub or the notification destination, etc., clearly state the cause.
Related skills
- dependency-update-report: A skill to review one dependency-update pull request and post a report as a comment. Executed by a subagent
- dependency-update-fix: A skill to fix one pull request that was found to need corrections in review and push it. Executed by a subagent
- dependency-update-setup-routine: A skill to create the launch prompt for this skill and register it in a Claude Code on the web routine. Launched by the user
- kuden:orchestrator: Guidance for the commander who delegates work to subagents. Followed by the commander
- kuden:github: Guidance for creating pull requests on GitHub and writing text. Followed by the commander when merging and by subagents when writing comments