---
name: QA
slug: qa
category: Quality
description: QA verifies a feature after implementation by tracing the wiring, running the happy path, and trying to break it with edge cases and failure modes. Use it when you need an actionable finding or explicit adversarial validation.
github: "https://github.com/kdlbs/kandev/tree/main/.agents/skills/qa"
language: Go
stars: 679
forks: 95
install: "npx degit https://github.com/kdlbs/kandev/tree/main/.agents/skills/qa ~/.claude/skills/qa"
installs_to: ~/.claude/skills/qa
source_path: .agents/skills/qa/SKILL.md
collection_size: 25
category_size: 1354
collection_url: "https://dirskills.com/collections/kdlbs/kandev"
added: 2026-08-23T05:21:11.288Z
last_synced: 2026-08-23T05:21:11.288Z
canonical_url: "https://dirskills.com/skills/qa"
---

# QA

QA verifies a feature after implementation by tracing the wiring, running the happy path, and trying to break it with edge cases and failure modes. Use it when you need an actionable finding or explicit adversarial validation.

**Install:**

```bash
npx degit https://github.com/kdlbs/kandev/tree/main/.agents/skills/qa ~/.claude/skills/qa
```

## README

# QA

## Planner Entry

Run `/qa` only when the user explicitly requests adversarial validation or an
actionable PR/CI finding needs it. Do not add QA as a pre-PR quality gate:
task-defined tests and the two PR AI reviewers are the default evidence.

Verify that a feature works as intended after implementation. Assume bugs exist and hunt for them.

Mindset: you are not confirming it works — you are discovering where it breaks.

## Available skills

- **`/tdd`** — Use when unit or integration coverage is missing.
- **`/e2e`** — Use when a user-facing flow lacks browser coverage.

---

## Before starting: create the pipeline

Create these tasks immediately (use your task/todo tracking tool if available):

1. **Understand the intent** — Read task/PR/commits to understand what was built
2. **Trace the wiring** — Verify the feature is actually connected end-to-end
3. **Test the happy path** — Run the feature as a user would
4. **Try to break it** — Boundary values, error paths, concurrency, auth
5. **Verify test coverage** — Check for missing tests and report gaps
6. **Report** — Summarize findings with verdict

Mark each task in_progress when you begin it and completed when you finish it.

---

## Phase 1: Understand the intent

Mark task 1 as in_progress.

Read the task description, PR, or recent commits to understand what was built and what it should do. Identify:
- The expected behavior (happy path)
- System boundaries (user input, API endpoints, external data)
- Integration points (what calls what, data flow end-to-end)

Mark task 1 as completed.

---

## Phase 2: Trace the wiring

Mark task 2 as in_progress.

Before testing behavior, verify the feature is actually connected:
- Exports are imported and used (not just defined)
- API routes have consumers (frontend calls them, or tests exercise them)
- Data flows end-to-end: input -> handler -> storage -> response -> display
- New config/env vars are documented and have defaults

If something is orphaned or unwired, stop and report it — no point testing disconnected code.

Mark task 2 as completed.

---

## Phase 3: Test the happy path

Mark task 3 as in_progress.

Run the feature as a user would. For backend changes, call the API. For frontend changes, trace the UI flow. For both, follow the full path:
- Does the basic use case work?
- Does the response/output match expectations?
- Is the data persisted correctly?

Mark task 3 as completed.

---

## Phase 4: Try to break it

Mark task 4 as in_progress.

Systematically test these categories (skip what doesn't apply):

**Boundary values:**
- Empty input, nil/null, zero, negative numbers, max values
- Empty arrays/maps, single element, very large collections
- Strings: empty, whitespace-only, special characters, very long

**Error paths:**
- What happens when dependencies fail (DB down, API timeout, invalid response)?
- Are errors surfaced clearly or silently swallowed?
- Does the system recover or get stuck in a bad state?

**Concurrency:**
- What happens with simultaneous requests to the same resource?
- Race conditions: create/update/delete at the same time
- Does it handle duplicate submissions?

**Authorization:**
- Can the feature be accessed without proper auth?
- Does it respect permission boundaries?

Mark task 4 as completed.

---

## Phase 5: Verify test coverage

Mark task 5 as in_progress.

Check that the implementation has tests covering the behaviors you just verified:
- Are the happy path and key error paths tested?
- Are edge cases from Phase 4 covered?
- Are tests at the right level: unit for pure logic, integration for boundaries, E2E for critical browser flows?
- Do tests assert behavior/state/output rather than implementation details or mock behavior?
- If tests are missing, report the exact behavior and recommended test level so
  add the focused test in the same conversation.
- Avoid snapshot tests unless the snapshot change will be deliberately reviewed.

Mark task 5 as completed.

---

## Phase 6: Report

Mark task 6 as in_progress.

Summarize what was tested and what was found:

**Verified working:**
- List of behaviors confirmed working

**Issues found:**
- file:line - description, how to reproduce, severity (blocker/suggestion)

**Missing test coverage:**
- Behaviors that work but have no automated test

**Verdict:** Feature complete / Has issues — fix before merge

Mark task 6 as completed.