Assigned by the commander of the codepatrol skill, reflect the actual status of pull requests that fix issues on the triage page and investigation reports.
Fix work proceeds in parallel by multiple humans and AIs. The status written on the pages drifts from the actual status. Such drift includes: remaining marked as review requested even though it was merged, not written on the page even though someone else has started work, and being written on only one of the pages. If drift remains, the next investigation or triage will mistakenly recognize an already-handled issue as unhandled.
Prerequisites for running this skill
- Cannot ask the user questions. Things that cannot be determined should be written in the final report
- Do not read code
- Only read pull requests. Do not create or edit pull requests or comments
- Handle only cases where the output destination is Cosense. The starting page and the repository where pull requests are created follow the commander's instructions
- Follow the cosense skill for reading and writing Cosense
Target pages
The starting point is the triage page passed from the commander. Reports are the ones linked from each row of the triage page.
Read the editing rules written at the beginning of the triage page before starting. The meaning of status icons and what may or may not be written are determined there. If they conflict with this procedure, prioritize the page's description.
If there is no triage page, target the latest report for each area aggregated on the hub page.
Match the page status to the actual status
For pull request rows on the page, check the actual status of the pull request and match the status icon. The mark represents the pull request's status, not whether the issue has been resolved.
| Status of the pull request in that row | Mark |
|---|---|
| All are merged | Done |
| Including drafts | In progress |
| Neither of the above, and open | Review requested |
- The same pull request row exists on both the triage page and the report. Fix both
- Copy a status written on only one page to the other page as well. Copy only who has started work and the pull request status. Do not copy considerations or handoff notes
- There is no mark representing a pull request closed without being merged. If it is not listed on the page, do not add it
Find pull requests not on the page
Among pull requests that fix issues, find ones not listed on the page. Oversights happen in this direction. Implementers sometimes submit fixes without writing them on the page.
For pull requests not listed, read the description and determine which issue they fix. If they fix an issue, add a status icon and add them to both the triage page and the report. If they do not fix an issue, do not add them.
The timing of the previous sync is a clue for narrowing the search range. However, a pull request created before the previous sync may later become a fix for an issue. When narrowing by date, also be careful about time zones. Pull requests created around the date boundary may be missed.
Remaining tasks after completion
For rows marked as complete, check whether there are any remaining tasks. Even if a pull request is merged, it does not necessarily mean all issues are resolved. This includes cases where only part was fixed, something was left as a separate task, existing data needs to be reviewed, or verification in the actual environment is needed. Remaining tasks are expressed as a one-line summary without removing the completion mark.
- If remaining tasks are written in the report's issue, add a one-line summary below the pull request's row on the triage page. Even if there are multiple, combine them into one line. Details are in the report, so the summary alone is sufficient
- Work written only in the pull request's description should first be copied to the report's issue. Write it so it is clear that it was copied from the description, and do not write anything not in the description. Then add the summary to the triage page
- If a row with the same meaning already exists, do not add it
Rows written by humans
Humans are editing the page in parallel.
- Even for rows written by humans, correct the status icon to match the actual status. Report that you corrected it
- Do not change the wording. However, remove words that contradict the actual status, and report that you removed them. This includes words like "still draft"
- Do not touch rows declaring a start of work that do not have a link to a pull request
- The signature at the end of a pull request row belongs to the implementer. Do not change it to your own signature
Report without fixing
When you find the following, do not fix the page and report to the coordinator.
- A pull request was closed without being merged. A decision is needed on whether to delete or keep the row listed on the page
- A remaining task summary appears to have been resolved by a later pull request. Whether the work is done cannot be confirmed from the pull request
- Issues matching the target conditions have increased in the report. A decision is needed on whether to add rows to the triage page
- A pull request that fixes a location the report judged as "no issue" is in progress
- The same pull request is linked to different issues on the triage page and in the report. This is when it cannot be determined even by reading the pull request's description
Reporting to the coordinator
I will report in the following three parts.
- Lines fixed
- Lines that were correct so I did not touch them. By also listing the lines I did not touch, it is clear that they were not overlooked.
- Matters left unfixed because they require judgment
In addition, I will report the following.
- Pull requests newly added to the page and the issues linked to them
- Pull requests that were not listed on the page but were judged not to be fixes for the issue
- The number of lines with status icons and the number of pull requests checked