/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
One skill from pro-workflow.
shell
$ npx -y skills add rohitg00/pro-workflow --skill bug-capture --agent claude-codeInstalls just this skill. Get the whole plugin for auto-invocation.
How it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/bug-capture
Context preview
The summary Claude sees to decide when to auto-load this skill.
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
Stats
Stars2,638
Forks255
LanguageJavaScript
SKILL.md
bug-capture.SKILL.md
--- 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.