qa is an interactive QA skill for turning conversational bug reports into durable GitHub issues. It helps the agent ask a few targeted questions, explore the codebase for context and domain language, and write user-focused issues without implementation details. Use qa for Issue Tracking when you need a clear issue from a messy report.
This skill scores 74/100, which makes it acceptable for directory listing with clear cautions. It gives users a concrete QA-to-GitHub-issue workflow and enough procedural guidance that an agent can trigger and use it more reliably than a generic prompt, but it is still limited by the lack of supporting files and by being nested under a deprecated path.
- Strong triggerability: the frontmatter explicitly says to use it for bug reporting, QA, filing issues conversationally, or when the user mentions a "QA session."
- Clear operational workflow: it tells the agent to ask at most 2–3 short clarifying questions, explore the codebase in the background, and file durable, user-focused GitHub issues.
- Good agent leverage: it instructs the agent to use project domain language and avoid internal implementation details, which improves issue quality.
- The skill lives at skills/deprecated/qa, so users may want to confirm it is still actively maintained or preferred over newer alternatives.
- There are no support files, scripts, references, or install command shown, so adoption will rely mainly on the SKILL.md text itself.
Overview of qa skill
The qa skill is for interactive QA sessions where a user reports bugs, confusing behavior, or product issues conversationally and the agent turns that into a durable GitHub issue. It is best for teams that want better bug reports without forcing users to write them in issue-template language.
What qa is for
Use the qa skill when the real job is to capture a clear issue from a messy report: what the user expected, what happened, whether it reproduces, and what part of the product boundary is involved. It is especially useful for qa for Issue Tracking when you need the report to read like a product-quality issue rather than a raw chat transcript.
Why it is different
The main value of the qa skill is not fixing the bug in the moment. It helps the agent ask only a few targeted questions, explore the codebase in the background for context, and file an issue in the project’s own language. That makes it a better fit than a generic prompt when you need issue quality, not just summary quality.
Best-fit and misfit cases
This skill fits best when the user can describe a visible problem, regression, edge case, or broken workflow. It is a weaker fit if you already have a full reproduction, if you only need root-cause analysis, or if the task is not meant to become a GitHub issue.
How to Use qa skill
Install qa in the repo
Install the qa skill with npx skills add mattpocock/skills --skill qa. Treat it as a session workflow, not a library: once installed, use it when the user says they are doing QA, reporting bugs, or want help filing an issue from a conversational report.
Start with a rough user report
The qa skill works best when the first input is the user’s plain-language complaint, not a polished bug template. Good inputs usually include the symptom, the expected outcome, and any rough context. For example: “The save button sometimes does nothing after editing a draft on mobile.” That gives the agent enough to ask one or two sharp follow-ups and then proceed.
Read these files first
Start with SKILL.md, then inspect README.md, AGENTS.md, metadata.json, and any rules/, resources/, references/, or scripts/ folders. For this repo, the key file is skills/deprecated/qa/SKILL.md; there are no supporting scripts or reference folders, so the skill depends on the instructions in that file and your own repo context.
Run the session in this order
Use a simple workflow: let the user explain the issue, ask at most 2-3 clarifying questions, explore the codebase in the background for domain language and behavior boundaries, then file the issue. If the report really contains multiple failures, split it before writing so the resulting GitHub issues stay actionable.
qa skill FAQ
Is qa only for GitHub issue filing?
Mostly yes. The qa skill is optimized for turning conversational bug reports into GitHub issues with enough context to be useful later. If you need debugging, code changes, or triage decisions, you may need a different workflow.
How is qa different from a normal prompt?
A normal prompt often over-collects details or writes a vague summary. The qa skill constrains the interaction: minimal clarifying questions, background codebase exploration, and issue wording that uses the project’s domain language. That makes it stronger for qa for Issue Tracking than a one-off prompt.
Do beginners need deep repo knowledge?
No. The skill is designed to reduce guesswork. Beginners can report the symptom in their own words and let the workflow extract what matters. The main requirement is that the problem is observable enough to discuss.
When should I not use qa?
Do not use qa if the problem is purely speculative, if there is no user-facing symptom yet, or if you already know you need a fix plan rather than an issue. In those cases, a debugging or planning skill will usually be a better fit.
How to Improve qa skill
Give the clearest symptom first
The qa skill produces better issues when the first message includes the visible failure, the expected behavior, and the narrowest possible context. “Export fails” is weaker than “Export fails only after adding a second filter and clicking Download on Firefox.” Specificity improves both clarifying questions and the final issue title.
Separate one bug from many
A common failure mode is bundling several problems into one complaint. If one report mixes UI glitch, performance lag, and missing data, the resulting issue will be harder to triage. Split by user impact and reproduction path before asking the qa skill to file anything.
Add reproduction and boundaries
If you already know steps to reproduce, say them. If the bug is intermittent, mention frequency, device, browser, account state, or dataset size. Those details help the qa skill decide whether it is a single issue, a pattern, or a broader breakdown.
Iterate on the issue draft
After the first draft, check whether the wording is durable, user-facing, and free of implementation details. If it still sounds like a chat note, ask for a tighter title, clearer expected-versus-actual framing, or a cleaner split into separate issues.