Qa

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

.claude/agents

.claude/skills

.github/CLAUDE.md

CLAUDE.md

apps/backend/CLAUDE.md

import { test, expect } from "../../fixtures/test-base";

apps/web/generated/licenses.json

Audit 0.4.1 · source sha 786d4817799e · 18 Oct 2026Report an issue or request a re-scan

• Publisherkdlbs GitHub organizationOwner of the repository this skill is read from
• Source folderkdlbs/kandev/.agents/skills/qaThe exact folder we audited
• LicenceAGPL-3.0As the repository states it
• Commit pinned for this verdict786d4817799eA new audit runs when the source changes
• Repository statusNot archivedPushed today
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Verify a feature works after implementation. Actively try to break it — edge cases, error paths, integration wiring, and real usage flows.

---
name: qa
description: Verify a feature works after implementation. Actively try to break it — edge cases, error paths, integration wiring, and real usage flows.
---

# 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.

Excerpt, first 4,566 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/kdlbs/kandev
git -C kandev checkout 786d4817799e

Works in

1. 2026-10-18
   !CAUTION B 89 / 100

   first audit · source 786d4817799e

Questions about Qa

• github.com/kdlbs/kandev/tree/main/.agents/skills/qa — the audited source at commit 786d4817799e and every finding aboveObserved · 18 Oct 2026

Spotted something wrong? Report a correction · Methodology