Skip to content
Back to skills

Qa

ASecurity

Use when reporting bugs, doing QA, or filing GitHub issues conversationally

  • 2 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 10, 2026
ai-agentsbashtestinggit

Works with

  • cli

Security analysis

A100/100

Scanned September 10, 2026

npx -y skills add LoopyLuci/Skills --skill qa --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Qa?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Qa
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/loopyluci-skills/badge)](https://www.skillsdirectory.com/skills/loopyluci-skills)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.