Assigned by the commander of the codepatrol skill, classify the problems in investigation reports and create a triage page.
Triage means deciding whom to prioritize among those actually in trouble, in light of your own resources and the other party's state. Here, problems are classified by which tier of developer can fix them. All problems in the reports are real; do not verify whether they reproduce or reassign their severity. That has already been done in the investigation.
File structure
{このSKILL.mdがあるディレクトリ}/
SKILL.md ← この手順書
TRIAGE-TEMPLATE.md ← トリアージページのテンプレート
Preconditions when running this skill
- You cannot ask the user questions. Things you cannot judge, write in the final report
- Do not read the code. Judge from what is written in the reports
- Handle only the case where the output destination is Cosense. For hub pages, follow the commander's instructions
- For reading and writing Cosense, follow the cosense skill
Fix difficulty
Divide into the following three fix difficulties based on who needs to make the decision on the specification change required for the fix. The larger the number, the higher the tier of developer who can fix it. For the names of the fix difficulties, use this text as is.
- Problems that can be fixed by developing according to theory, with almost no decision-making for specification changes
- Problems that require a moderate amount of decision-making for specification changes, but for which consensus within the development team is easy
- Problems that require rethinking from the design stage, such as because the data model or security model changes significantly, or because users need to be informed
1 can be fixed even by an implementer who is not familiar with the product. 3 requires a developer of the product themselves to fix the design while thinking about what comes later.
- Even in 1, small decisions arise during implementation. Decisions such as which status code to return for invalid input. Decisions that the implementer can make on the spot are included in 1
- Do not divide by the amount of change. Even if the diff is small, things that require consensus within the development team are 2
- The descriptions of remediation in the report's problems serve as material for judgment. Look at whether the fix method is written specifically, or whether it is written that a design change is necessary
Target
Target the latest report for each area. Among the reports aggregated on the hub page, the newest one for each area.
For the conditions of problems to include, follow the commander's instructions. If there are no instructions, target problems with severity High.
Create the page
TRIAGE-TEMPLATE.md Read in, and create a new page according to its structure.
- When multiple reports report problems with the same root cause, combine them into one line. If the reports state which name to use, follow that
- When it is easier to determine the fix difficulty by splitting one problem into units of fix, you may split the lines. This is a problem that mixes parts that do not require specification judgment with parts that do
- Do not list completely fixed problems. When completed items are lined up, the number of unprocessed problems becomes hard to tell
- For problems that are only partially fixed, list that they remain
When there is a previous triage page
Do not edit the previous page; create a new page. Add just one line at the beginning of the previous page linking to the new page. Do not edit any other lines of the previous page.
For every line of the previous page, decide its destination. Do not create lines that silently disappear.
| Status in the latest report | Destination |
|---|---|
| Still meets the target conditions this time | List it in the fix difficulty 1 to 3 section and note that it is continued from last time |
| The report confirms that all of it has been fixed | Do not list |
| The severity changed and it no longer meets the target conditions | List it in the final section |
| It is in "Previous problems not detected this time" | List it in the final section. Note that this does not mean it has been fixed |
| It has been fixed in the code, but work remains that cannot be confirmed from the code | List it in the final section |
In the report's "Items fixed since last time" section, problems that were partially fixed and had their severity lowered are also listed. Being in this section alone is not a reason not to list it.
For both lines listed in the fix difficulty 1 to 3 section and lines listed in the final section, carry over what was written in the lines of the previous page. If you do not carry it over, problems that have been started on will look like problems that have not been touched.
- Carry over human-written notes without changing the wording or signature. They are priority judgments or declarations of having started work
- For lines for fix PRs and remaining tasks after completion, carry them over together with their status icons. Also carry over lines marked as complete. If the problem remains in the latest report, then that fix has fixed only part of the problem, or the report has not yet confirmed the fix
- Among the remaining tasks, exclude work whose fix the latest report has confirmed
- Do not check the actual state of the pull request. Checking the state is done by codepatrol-sync-state
Handle links as follows.
- In the fix difficulty 1 to 3 section, do not carry over links to previous reports or links to lines of the previous triage page. Replace them with links to the latest report. If old links are lined up, it becomes unclear which report should be looked at
- The lines in the final section link to the report where the basis for that issue is written. If it is not in the latest report, it is in the previous report.
If the team added any rules to the editing rules of the previous page, carry them over to the editing rules of the new page.
Title
{hubページ名} トリアージ ({YYYY/M/D}) And so on. If a page with the same name already exists, append the time to the date.
Report to the commander
- The location and title of the created page
- The number of reports targeted and the targeting conditions
- The number of lines per fix difficulty
- Issues grouped together as having the same root cause
- The number of lines per destination for the lines of the previous triage page
- Issues for which the fix difficulty was uncertain, and the reason for the uncertainty
- Matters that could not be determined