47 lines
2.2 KiB
Markdown
47 lines
2.2 KiB
Markdown
---
|
|
name: triage-findings
|
|
description: Merge code-review findings, sort and renumber them by severity, resolve real issues, and move false positives into exclusions.
|
|
---
|
|
|
|
# Triage Findings
|
|
|
|
## When To Use
|
|
|
|
Use this skill when you receive multiple review findings, screenshots, comments, or issue lists that need to become one final triaged list.
|
|
It is also used when some findings are false positives and should be moved into the exclusions list.
|
|
|
|
## Workflow
|
|
|
|
1. Collect all findings into one list.
|
|
2. Merge duplicates into a single finding when they describe the same issue.
|
|
3. Sort the final list by severity:
|
|
- critical
|
|
- warning
|
|
- info
|
|
4. Renumber the sorted list from 1 upward.
|
|
5. Rewrite each finding concisely so the final list reads cleanly and consistently.
|
|
6. If a finding is a false positive, do not keep it in the final list.
|
|
7. Add false positives to the exclusions list as a top-level JSON array in `.gitea/ai-review/exclusions.json`, and preserve the original finding wording as much as possible, including language and semantics. Do not wrap the array in `exclusions` or `excluded_findings`.
|
|
|
|
## Resolution Flow
|
|
|
|
After the list is merged and ordered, resolve the remaining findings one by one.
|
|
|
|
1. Start from the highest severity item.
|
|
2. Identify the root cause in the relevant file or context.
|
|
3. Apply the smallest safe change that fixes the issue.
|
|
4. Add or update tests when behavior changes.
|
|
5. Re-check the issue after the change.
|
|
6. If the item is confirmed false positive, move it to exclusions instead of changing code.
|
|
7. Continue until the list is either fixed or explicitly excluded.
|
|
|
|
## Output Rules
|
|
|
|
- Keep the final findings list in severity order, then by any stable secondary order needed to make it readable.
|
|
- Keep numbering contiguous after filtering and merging.
|
|
- Preserve useful details like file path, location, and suggested fix.
|
|
- Keep exclusions entries minimal and consistent with the project schema.
|
|
- When writing exclusions, always output a top-level JSON array.
|
|
- When writing exclusions, prefer the original issue text and language; only paraphrase if needed to fit the schema.
|
|
- If the source already provides a severity or title, keep it unless it conflicts with the final ordering.
|