| name | list-issues |
| description | Organize and update code-related issues in a consistent table with stable issue IDs, type, concise file-and-line-aware descriptions, and current status. Use when code review findings, bugs, risks, or suggestions need to be listed, summarized, tracked, or updated during a conversation. |
List Issues
Present code issues as a table using the representation supported by the active agent or interface. Use exactly these columns in order: Issue ID, Type, Description, and Status.
Build the Table
- Assign IDs in discovery order as
I1, I2, I3, and so on.
- Keep each ID bound to the same underlying issue across every table update. Match by the concern and location, not by exact wording or row position.
- Never renumber or reuse an ID. Assign each new issue the number after the highest ID already used in the conversation.
- Keep addressed issues in full-table updates and change only their status. If the user requests a filtered view, omit excluded rows but reserve their IDs.
- Order rows by the numeric part of the issue ID to minimize churn between updates.
Fill the Columns
- Issue ID: Use the issue's stable
I<number> identifier.
- Type: Use
Critical, Important, Minor, or Suggestion.
Critical: Security, data loss, severe correctness, or release-blocking risk.Important: A meaningful defect or risk that should be addressed.Minor: A limited-impact problem or maintainability concern.Suggestion: An optional improvement with no current defect.
- Description: Write one short, clear sentence that explains the problem and its impact. Include a known source location as
`path/to/file.ext:line`; omit the location rather than guessing it. Keep the description on one line.
- Status: Use
Open, Fixed, Won't Fix, or False Positive. Default new issues to Open, and preserve an explicit status supplied by the user.
Update Existing Issues
- Update the existing row when its wording, type, location, or status changes without changing the underlying issue.
- Create a new ID when a finding has a materially different cause or impact, even if it is near an existing issue.
- Keep the earliest ID when duplicate findings are consolidated, and mark the later duplicate as
False Positive rather than removing or reusing its ID.
- Do not add a separate file or line column; keep source references in the description.
