Use when reporting bugs, doing QA, or filing GitHub issues conversationally
Scanned 9/10/2026
Install to Claude Code
npx -y skills add LoopyLuci/Skills --skill qa --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Qa?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/loopyluci-skills)More formats (shields.io, HTML) on the badges page.
---
name: qa
description: Use when reporting bugs, doing QA, or filing GitHub issues conversationally
tags: [testing, QA, bugs, GitHub, issues]
related_skills: [triage, diagnosing-bugs, to-tickets]
---
# Qa
Run an interactive QA session. The user describes problems they're encountering. You clarify, explore the codebase for context, and file GitHub issues that are durable, user-focused, and use the project's domain language.
## For each issue the user raises
### 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:
- What they expected vs what actually happened
- Steps to reproduce (if not obvious)
- Whether it's consistent or intermittent
Do NOT over-interview. If the description is clear enough to file, move on.
### 2. Explore the codebase in the background
While talking to the user, understand the relevant area to:
- Learn the domain language used in that area
- Understand what the feature is supposed to do
- Identify the user-facing behavior boundary
### 3. Assess scope: single issue or breakdown?
Break down when the fix spans multiple independent areas or there are clearly separable concerns.
### 4. File the issue(s)
Write issues that describe the problem from the user's perspective, not implementation details.
## Common Pitfalls
- **Over-interviewing the user**: Asking too many clarifying questions wastes user time. Limit to 2-3 questions. If the description is clear enough, file the issue.
- **Including implementation details in issues**: Issues should describe user-facing behavior, not internal file paths or line numbers. Keep the focus on what is broken from the user's perspective.
- **Not breaking down compound issues**: A single report that spans multiple independent areas should be split into separate issues for parallel work.
## Code Examples
```bash
# QA Session Workflow
# 1. User reports: "The form doesn't validate on submit"
# 2. Explore the codebase to understand form handling
# 3. File a GitHub issue:
## Summary
Form validation does not trigger on submit button click
## Expected behavior
Invalid fields show error messages and red border on submit
## Actual behavior
Form submits successfully with invalid/empty data
## Steps to reproduce
1. Navigate to /settings/profile
2. Leave required field "email" empty
3. Click "Save Changes"
4. Observe: form submits without validation feedback
```
## Verification Checklist
- [ ] User described the problem in their own words
- [ ] At most 2-3 clarifying questions asked
- [ ] Codebase explored for domain context
- [ ] Compound issues broken into separate issues
- [ ] Issues filed without implementation details
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!