Agent skill

QA

by kdlbs in kdlbs/kandev

Verify a feature works after implementation. An agent skill from kdlbs/kandev.

AGPL-3.0Auto-check passedTesting & QA

Install QA

skills CLI
$ npx skills add kdlbs/kandev --skill qa -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install kdlbs/kandev qa --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/kdlbs/kandev.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/qa .claude/skills/qa && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
qa
GitHub stars
909
Token cost
~1.1k tokens
SKILL.md length
644 words
Files
1
Skills in repo
45
Repo updated
First seen
Licence
AGPL-3.0

At a glance

Verify a feature works after implementation. An agent skill from kdlbs/kandev.

  • Works in 6 steps: Understand the intent → Trace the wiring → Test the happy path → …
  • Testing & QA work in your project
  • SKILL.md covers Planner Entry, Available skills, Before starting: create the… and Phase 1: Understand the intent, plus 5 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

QA is an agent skill from kdlbs/kandev. Verify a feature works after implementation. Actively try to break it — edge cases, error paths, integration wiring, and real usage flows.

Its SKILL.md is about 1.1k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Testing & QA. The repository describes itself as: AI Kanban & Development Environment. Orchestrate multiple agents, review changes, open PRs. Multi-provider, self-hostable, no telemetry. The licence is AGPL-3.0.

When your agent uses it

  • Testing & QA work in your project

Example prompts

  • “/qa”

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Understand the intent
  2. Trace the wiring
  3. Test the happy path
  4. Try to break it
  5. Verify test coverage
  6. Report

What it can do on your machine

Read from SKILL.md and the folder at commit b734113. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

QA loads about 1.1k tokens when it runs. Until then it costs about 35 tokens; SKILL.md has 644 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~35
When it runs · the whole SKILL.md, loaded when a task matches
~1.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from kdlbs/kandev at commit b734113, republished under its AGPL-3.0 licence (© kdlbs). 644 words, ~1,142 tokens.

Download SKILL.mdSave it as .claude/skills/qa/SKILL.md (or your agent's skills folder).
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.


Show full SKILL.md (275 more words)Show less

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.

© kdlbs, AGPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/qa of kdlbs/kandev.

Open the folder on GitHubat commit b734113

Compare with similar skills

QA next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

QA compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
QA this skillkdlbs/kandev909—~1.1kAutomated safety check: PassAGPL-3.0
Web Application Testinganthropics/skills180k51 repos~966Automated safety check: PassApache-2.0
Diagnosing Bugsfossasia/eventyay-interpretation1.6k32 repos~2.1kAutomated safety check: PassApache-2.0
TDDpietheinstrengholt/rssmonster56430 repos~906Automated safety check: PassMIT
TDD WorkflowhellangleZ/burn-in-cceverywhere-ralph11211 repos~2.4kAutomated safety check: PassNone
TDDsanity-io/sanity6.4k20 repos~1kAutomated safety check: PassMIT

Similar skills

  • Web Application Testing

    anthropics/skills

    Official

    Tests local web applications with Python Playwright scripts, checking frontend behavior, capturing screenshots and reading browser console logs.

    180k GitHub starsUsed in 51 repos~966 tokens
    Testing & QAAuto-check passed
  • Diagnosing Bugs

    fossasia/eventyay-interpretation

    Diagnosis loop for hard bugs and performance regressions. An agent skill from fossasia/eventyay-interpretation.

    1.6k GitHub starsUsed in 32 repos~2.1k tokens
    Testing & QAAuto-check passed
  • TDD

    pietheinstrengholt/rssmonster

    Test-driven development. An agent skill from pietheinstrengholt/rssmonster.

    564 GitHub starsUsed in 30 repos~906 tokens
    Testing & QAAuto-check passed
  • TDD Workflow

    hellangleZ/burn-in-cceverywhere-ralph

    A skill your agent uses when writing new features, fixing bugs, or refactoring code.

    112 GitHub starsUsed in 11 repos~2.4k tokens
    Testing & QAAuto-check passed
  • TDD

    sanity-io/sanity

    Official

    Test-driven development with red-green-refactor loop. An agent skill from sanity-io/sanity.

    6.4k GitHub starsUsed in 20 repos~1k tokens
    Testing & QAAuto-check passed
  • Context Driven Development

    Ibrahim-3d/orchestrator-supaconductor

    A skill your agent uses when working with Conductor's context-driven development methodology, managing project context artifacts, or understanding the relationship between product.md, tech-stack.md…

    380 GitHub starsUsed in 9 repos~2.9k tokens
    Testing & QAAuto-check passed

More from kdlbs/kandev

All 45 skills in this repo
  • PR Walkthrough

    kdlbs/kandev

    Generate a single-file HTML walkthrough that explains a PR's purpose, user impact, interface changes, compatibility risks, and implementation.

    909 GitHub stars~6.2k tokensUpdated today
    Auto-check passed
  • Debug

    kdlbs/kandev

    Diagnose Kandev bugs, running-instance issues, UI/browser failures, and runtime behavior.

    909 GitHub stars~2.2k tokensUpdated today
    Auto-check passed
  • Improve Kandev's AI harness from session learnings or explicit requests.

    909 GitHub stars~1.3k tokensUpdated today
    Auto-check passed
  • Diagram Design

    kdlbs/kandev

    Create branded architecture, IT current-state, flowchart, sequence, state machine, ER/data model, timeline, swimlane, quadrant, radar/spider, polar chart (polar/radial lollipop), loop/flywheel…

    909 GitHub starsUsed in 1 repo~8k tokens
    Auto-check passed
  • TDD

    kdlbs/kandev

    Implement changes using Test-Driven Development (Red-Green-Refactor).

    909 GitHub stars~4.2k tokensUpdated today
    Auto-check passed
  • Verify

    kdlbs/kandev

    Run a broad local verification audit only when the user explicitly requests it or PR/CI remediation requires it.

    909 GitHub stars~2.7k tokensUpdated today
    Auto-check passed

Categories

Questions about QA

What does QA do?

Verify a feature works after implementation. An agent skill from kdlbs/kandev. QA is an agent skill from kdlbs/kandev. Verify a feature works after implementation.

When should I use QA?

QA fits situations like: testing & QA work in your project.

How do I install QA in Claude Code?

Run `npx skills add kdlbs/kandev --skill qa -a claude-code`. Or copy the skill folder (.agents/skills/qa in kdlbs/kandev) into .claude/skills/qa in your project. Claude Code loads it when a task matches its description.

How do I install QA in Codex?

Run `npx skills add kdlbs/kandev --skill qa -a codex`. Or copy the skill folder (.agents/skills/qa in kdlbs/kandev) into .agents/skills/qa in your project. Codex loads it when a task matches its description.

Can I use QA in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add kdlbs/kandev --skill qa -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/qa, .gemini/skills/qa, .github/skills/qa and .opencode/skills/qa in your project.

What does QA need to run?

SKILL.md names no scripts, command-line tools or credentials: QA is instructions for the agent only.

Does QA access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is QA safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does QA use?

QA is published under the AGPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does QA use?

About 1.1k tokens (SKILL.md is roughly 4.6k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to QA?

Skills that share tags, products or a category with QA: Web Application Testing (anthropics/skills, 180k stars), Diagnosing Bugs (fossasia/eventyay-interpretation, 1.6k stars), TDD (pietheinstrengholt/rssmonster, 564 stars) and TDD Workflow (hellangleZ/burn-in-cceverywhere-ralph, 112 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains QA?

kdlbs (a GitHub organization) maintains it in kdlbs/kandev, which has 909 GitHub stars. The repository holds 45 skills in this directory. The repository was last updated on October 8, 2026.

Source: kdlbs/kandev on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.