| name | qa |
| version | 1.0.0 |
| description | Run an interactive QA session — the user describes bugs and issues conversationally, you
ask brief clarifying questions, explore the codebase for domain context, decide whether
to file one issue or break it down, and create durable user-focused GitHub issues via
`gh issue create` — without referencing internal file paths or line numbers. Use this
skill whenever the user wants to do QA, report bugs, file issues, walk through a list of
problems, or hits you with phrases like "let's do a QA session", "I found a bug", "this
is broken", "file this as an issue", "I have a few things to report", or "let's go
through these one by one". Also use when the user is reviewing a deployed feature and
wants to track defects.
|
| license | MIT |
| compatibility | claude-code opencode |
| allowed-tools | ["Read","Write","Grep","Glob","Bash","Agent","AskUserQuestion"] |
| metadata | {"author":"MKAbuMattar","requirements":"Requires `gh` CLI authenticated for the target repo. Designed for Claude Code (or any agent that supports a background `Explore` subagent)."} |
QA
Interactive QA: capture bugs into durable, user-focused GitHub issues — fast, parallel-friendly, and free of internal file/line references.
When to use
- The user wants to report bugs, do a QA pass, or walk through a list of defects.
- The user opens with phrases like "let's do a QA session", "I found a bug", "this is broken", "file this", "a few things to report", or "let's go through these".
- The user is reviewing a deployed feature and wants the issues tracked.
The session loop
For each issue the user raises, run these steps. Each issue is independent — don't batch.
1. Listen and lightly clarify
Let the user describe the problem in their own words. Ask at most 2–3 short clarifying questions, focused on:
- Expected vs actual behavior
- Steps to reproduce (if not obvious)
- Consistent vs intermittent
If the description is already clear enough to file, move on without asking. Don't over-interview.
2. Explore the codebase in the background
While talking to the user, spawn a background Explore subagent (subagent_type=Explore) for the relevant area. The goal is context for the issue body, not a fix:
- Learn the domain language used in that area. Read
UBIQUITOUS_LANGUAGE.md if present.
- Understand what the feature is supposed to do.
- Identify the user-facing behavior boundary.
The issue itself must not reference specific files, line numbers, or internal implementation details — that exploration only sharpens your wording.
3. Decide: single issue or breakdown
Break down when:
- The fix spans multiple independent areas (
form validation is wrong AND success message is missing AND redirect is broken).
- There are clearly separable concerns different people could work on in parallel.
- The user describes multiple distinct failure modes or symptoms.
Keep as a single issue when:
- It's one behavior that's wrong in one place.
- All the symptoms are caused by the same root behavior.
When breaking down: prefer many thin issues over few thick ones, mark blocking relationships honestly, create issues in dependency order so Blocked by #N can use real numbers, and maximize parallelism.
4. File the issue(s) with
