Report Github Issues

Report GitHub Issues

Record unrelated findings in GitHub without widening the active issue or pull request.

Decide what to report

• Keep a finding in the active issue or PR when it is required for that work's acceptance criteria or is a direct consequence of the change.
• Use this skill when the finding is concrete and independent, such as an unrelated defect, regression, missing feature, documentation gap, or reproducible test gap.
• Do not file speculative ideas, subjective preferences, secrets, or long raw logs. Preserve only the minimum evidence needed to understand or reproduce the problem.
• Resolve the repository from the current issue, PR, or checkout. If the repository or the boundary between related and unrelated work is genuinely unclear, ask before writing.

Create or reuse an issue

1. Search the repository's open and closed issues using distinctive terms from the finding. Do not create a duplicate.
2. If an open issue already covers the finding, add one concise follow-up comment with the new evidence and a link to the issue or PR where it was found. Do not restate the whole issue.
3. If no issue covers it, create one with a short factual title and concise body. Include the problem, minimal evidence or reproduction, impact, and originating issue or PR when available. Omit empty sections.
4. Apply the exact autogenerated label to every issue created by this skill unless repository instructions require a different label. If it does not exist, create it when permissions allow; do not substitute a similar label silently.
5. When adding an autogenerated comment to an existing issue, preserve its labels unless the user explicitly requests a label change.
6. Create an isolated temporary review directory outside the repository. Write one clearly named Markdown file per proposed GitHub write, whether a new issue or a comment. Each file must contain the exact target repository or issue, action type, title when applicable, labels, and guarded body or comment that would be submitted. Do not combine multiple proposals in one file.
7. Show the user the directory path and a concise index of the proposal files. Ask them to approve or reject each file, or approve all, and wait for an explicit decision. The original request to report findings is not approval of these drafts. The user may edit the Markdown files before approving them.
8. Immediately before publishing, reread each approved file and submit exactly its current contents. Never publish rejected, undecided, or missing files. If the agent materially changes an approved draft or its destination, request approval again; user edits made before approval are already covered by that approval.
9. Verify every resulting URL and, for each new issue, its label before reporting success. If access, authentication, or permissions prevent a write, report the blocker and do not claim that it happened. Remove the temporary review directory after all proposals are resolved unless the user asks to retain it.

Prefer a connected GitHub integration for issue and comment operations. Use the repository's approved CLI fallback when the integration cannot perform the required operation.

Guard every generated message

Wrap every generated issue body and issue comment with this visible marker unless stricter repository instructions specify another marker:

> _Start of autogenerated message._

[concise issue or comment text]

> _End of autogenerated message._

Keep issue titles clean and searchable; put the guard in bodies and comments. Do not include a product, model, or agent name in the guard, and never post an unguarded generated issue body or comment.

Write boundaries

• This skill may create a narrowly scoped follow-up issue or add a directly relevant evidence comment when the workflow calls for it.
• Do not assign, close, reopen, delete, remove labels, or change the active issue or PR scope unless the user separately requests it.
• Link the originating issue or PR and explain why the finding is separate when creating a follow-up issue.