About this skill

Problem Background

GitHub issues often fail when security findings, bugs, epics, and feature requests are forced into one generic template. Engineers may include conclusions without evidence, missing repro steps, unclear impact, or acceptance criteria that cannot be verified. Recommendations may also omit why a default, permission, compatibility behavior, or new configuration should change. This skill helps turn scattered findings into GitHub issues that are reviewable, actionable, and safe to submit.

Workflow and Boundaries

It first identifies the issue type: security, bug or regression, epic or tech-debt, or feature, then loads the matching structure instead of applying a generic template. Key steps include:
- Gathering evidence: code paths, line numbers, logs, screenshots, responses, config or deployment facts, and current versus expected behavior.
- Matching the shape: security issues emphasize entrypoint -> behavior -> missing control -> exposure/impact; bug issues prioritize reproduction closure; epics define scope, priorities, and child issue candidates.
- Writing actionable recommendations: simple bugs get plain recommendations; changes affecting defaults, permissions, compatibility, new required configuration, or multiple implementation paths include reasons and options.
- Pre-submission checks: concise action-oriented titles, no secrets, tokens, or excessive exploit detail, and submission via gh issue create or REST fallback when appropriate.

Boundaries: it does not fix code or implement the issue; suspected facts should be marked Needs verification; if repository or labels are ambiguous, confirm before submitting.

Screenshots

Use Cases

Turn authz, SSRF, or token findings from code review into a security issue with an evidence chain.
Convert debug logs, repro steps, observed behavior, and expected behavior into a reviewable bug issue.
Group related defects or refactor items into an epic issue with child issue candidates, priorities, and acceptance criteria.
Check for leaked tokens, unsupported labels, or weak evidence before running `gh issue create`.

Best For

Security engineers turning injection, privilege, token, or supply-chain findings into fixable issues.
Backend/frontend engineers converting logs, repro steps, and edge cases into reviewable bug issues.
Tech leads coordinating tech debt by splitting related refactors into epics and child issues.
Repository maintainers using `gh` to verify target, body, and labels before submitting issues.