bug-capture
Capture a user-reported defect as a durable GitHub issue written in the project's own domain language. Explores the codebase in parallel for context but never leaks file paths or line numbers into the issue. Use when the user reports a bug conversationally, runs a QA pass, or says "file an issue", "log this as a bug", "capture this".
Best for Maintainers receiving bug r…Works with GitHubLow risk
⌘source
- author
@rohitg00- language
- JavaScript
★1.9kstars
173forks
Apr 18, 2026
✦overview.md
Key Features
- ·Captures conversational bug reports as structured GitHub issues
- ·Explores codebase to adopt project's domain language
- ·Checks for duplicate issues before filing
- ·Avoids leaking file paths or line numbers into issues
- ·Minimizes clarifying questions to reduce reporter burden
Use Cases
- →Converting a user's verbal bug description into a formal GitHub issue
- →Running QA passes and automatically logging discovered defects
- →When team members say 'file an issue' or 'log this as a bug' during discussions
- →Creating durable issues that remain understandable after code refactoring
Best for
- ✓Maintainers receiving bug reports from users
- ✓QA teams documenting test failures
- ✓Development teams during bug triage sessions
Not ideal for
- !Creating feature requests or enhancement tickets
- !Situations requiring immediate code fixes rather than documentation
- !Projects not using GitHub for issue tracking
FAQs
name
bug-capture
description
Capture a user-reported defect as a durable GitHub issue written in the project's own domain language. Explores the codebase in parallel for context but never leaks file paths or line numbers into the issue. Use when the user reports a bug conversationally, runs a QA pass, or says "file an issue", "log this as a bug", "capture this".
bug-capture
Turn a conversation into an issue that still reads correctly after a major refactor.
Flow
1. Listen, then clarify minimally
Let the user describe the problem in their own words. Ask at most two short clarifying questions, drawn from:
- Expected behavior vs. actual behavior.
- Concrete reproduction steps if not already implied.
- Frequency: deterministic, intermittent, or one-off.
If the description already answers these, skip straight to filing. Over- interviewing is a tax the reporter pays for your uncertainty.
2. Explore in parallel
While the user is answering, start a background exploration of the relevant area. The goal is not to propose a fix. The goal is to absorb the project's own vocabulary — the nouns and verbs the codebase uses for this feature — so the issue reads like it was written by a maintainer.
If the repo has a glossary file (common names: GLOSSARY.md, UBIQUITOUS_LANGUAGE.md, docs/domain.md), read it first.
3. Check for duplicates before filing
Run gh issue list --search "<key phrase>" --state all --limit 10. If a
live or recently closed issue matches, surface it to the user and ask
$install
1-click copynpx skills add rohitg00/pro-workflow --skill bug-captureSafety assessment
★
Clarity score
How clear and easy to understand the SKILL.md instructions are, rated from 1 to 5.
4/ 5
very goodClear and well structured, with only minor parts that might need a second read.
◎
Actionability score
How directly an agent can act on the SKILL.md instructions, rated from 1 to 5.
4/ 5
highMostly actionable with clear steps; only a few small gaps remain.