| name | good-issue |
| description | Guide the user's agent to write a high-quality, contribution-ready GitHub issue for an OSS project — with a verified minimal reproduction, environment details, and root-cause investigation. Use when the user hits a bug in a dependency, wants to file an issue upstream, or asks to report a problem to an open-source project. |
good-issue
Philosophy
The best way to support OSS is to write good issues. A shining issue does the
maintainer's triage work for them: it is actionable in one read, has a
verified minimal reproduction, and ideally points at the root cause.
Issue creators who do this well become de-facto co-contributors.
Your job as the agent: don't just transcribe the user's complaint — investigate
it. Reproduce the bug yourself, minimize it, and dig into the dependency's
source before writing a word of the issue.
Workflow
1. Understand the problem
- Get the exact failing behavior from the user: what they did, what happened,
what they expected.
- Identify the target project and collect versions: the library, the runtime
(node/python/etc.), OS, and package manager. Read the user's lockfile to get
exact resolved versions — never trust semver ranges.
2. Check for duplicates (mandatory)
- Search the project's existing issues (open AND closed) for the error message,
symptom keywords, and related function names.
- If a duplicate exists: don't file. Instead, offer to add a 👍 + a comment with
the user's repro/environment if it adds new signal.
- Also check the project's CHANGELOG/releases — the bug may already be fixed in
a newer version. Try upgrading first.
3. Build a minimal reproduction (the core of this skill)
- Start from the user's failing code and cut aggressively: remove every
dependency, config option, and line that isn't required to trigger the bug.
- Target: a single file or a tiny repo scaffold (-level) that fails
with one command.
