Assigned by the commander of the codepatrol skill, comment a "Release PR deploy note" on the release pull request, which has accumulated fixes before going to production, summarizing what humans need to do before and after deployment.
With automated fixes, fix pull requests pile up quickly. Notes such as creating a DB index or adding an environment variable get scattered across the description fields of individual pull requests, and the person deploying cannot notice them. Gather them in one place so they can be noticed. It also becomes a place for humans to check the contents of the accumulated fixes all together.
File structure
{このSKILL.mdがあるディレクトリ}/
SKILL.md ← この手順書
DEPLOY-NOTE-TEMPLATE.md ← noteのテンプレート
Prerequisites for running this skill
- Cannot ask the user questions. Things that cannot be judged are written in the final report
- Do not read the code. Create it from the pull request description fields and comments
- The only thing to write is the note comment. It may be posted without getting confirmation of the draft. Do not edit other comments or description fields
- For how to write text that appears on GitHub, follow the
kuden:githubskill - For the target release pull request, follow the instructions of the commander
The note keeps rewriting a single comment
Place only one note on the same pull request. If a note already exists, rewrite it. Do not post a second one or add a follow-up comment. If there are multiple summaries, it becomes unclear which one to read.
At the beginning of the note, write up to which point and how many items were read. When updating next time, learn the previous range from there, read the increased pull requests, and add them to the existing items. For pull requests already listed, if the description field has been rewritten after the previous update, reread it and fix the item. Delete items for pull requests that have fallen out of the accumulated fixes. Then rewrite the whole thing. If nothing has changed and there is no confirmation from the person reflecting it, do nothing.
- The included pull requests are determined from the commits of the target pull request. The list in the description field is auto-generated and may have omissions
- Do not read pull requests created by the dependency update bot. The description field contains an external release note, and the deployment work is not written there
- Immediately before posting, check whether the target pull request and the existing note have changed since the draft was created. If the pull request has progressed, read the increased portion. If the note has been rewritten, reapply your changes to the latest note. Another person in charge may be updating the same note
- Lines that humans have added to the note are left without deleting, and reported
Write the note
DEPLOY-NOTE-TEMPLATE.md Read in and follow its chapter structure.
- Always output all sections every time, in the same order. Do not delete sections even if there is nothing to write; write "none". When the order is fixed, the reader gets used to it
- Each item starts with the number of the original pull request
- Commands and definitions written in the description are quoted as-is without summarizing. Do not copy them by hand; extract them from the retrieved description
- For work stated in the description as already done, add "done"
- Among the verification items in the description, list those that were merged without being performed. For fixes merged without human verification, this is the last chance for a human to check before it goes to production
- Do not use checkboxes; write in prose. Do not create a memo field for humans either
Reflect human verification
After a human checks an item in the note, they comment on the individual pull request about it. Each time the note is updated, reflect that and remove what is done. Rather than lining up completion marks, leave only what remains.
- Read all pull requests listed in the note, and among the comments on the target pull request, those written after the previous reflection and those that were edited. If a verification has been withdrawn, restore the item. Write up to what time it was reflected at the end of the note, and use that as the basis for next time. For pull requests newly listed in the note this time, read all comments. Some things are verified before they are listed in the note
- Mark as verified only the scope written in the comment. Leave items not written, even if they seem obvious. The note writer does not judge whether it was an oversight or an omission
- For items partially verified, write who verified what and a link to the comment, and write the remainder. For items fully verified, make it one line with the fact that it is verified and the link
- What counts are comments stating that a human checked something. Comments posted by AI during automated fix work do not count, even if posted from a human account. Conversely, do not exclude merely because there is an AI signature. There are cases where a developer has AI write what they checked themselves
Report to the commander
Write within 5 lines.
- The target pull request, the point in time the note targeted, the count, and the increase from last time
- Whether it was newly posted or an existing note was rewritten. The location of the note
- The key points of added items and the human verification reflected
- Pull requests where verification items in the description were merged without being performed
- Things you were unsure how to judge and things humans added