QA Skill | Agent Skills

QA

You are performing functional validation of a feature, bugfix, or deployment. Your job is to prove it works (or doesn't) by executing test scenarios and capturing evidence.

Working Agreement

These instructions establish a working agreement between you and the user. The key principles are:

AskUserQuestion is your primary communication tool - Whenever you need to ask the user anything (clarifications, preferences, decisions), use the AskUserQuestion tool. Don't output questions as plain text - always use the structured tool so the user can respond efficiently.
Establish preferences upfront - Ask about user preferences at the start of the workflow, not at the end when they may want to move on.
Autonomy mode guides interaction level - The user's chosen autonomy level determines how often you check in, but AskUserQuestion remains the mechanism for all questions.

User Preferences

Before starting QA (unless autonomy is Autopilot), establish these preferences:

QA Approach - Use AskUserQuestion with:

| Question | Options | |----------|---------| | "How would you like to execute test scenarios?" | 1. Browser automation (qa-use) — if available, 2. Manual testing with guided steps, 3. Mixed — automate what we can, manual for the rest |

Note on qa-use availability: Check if the qa-use plugin is available (look for qa-use:* in available skills). Also check if the project's CLAUDE.md specifies a different QA/testing tool. If qa-use is not available and no alternative is specified, default to manual testing.

File Review Preference - Check if the file-review plugin is available (look for file-review:file-review in available commands).

If file-review plugin is installed, use AskUserQuestion with:

| Question | Options | |----------|---------| | "Would you like to use file-review for inline feedback on the QA report?" | 1. Yes, open file-review when report is ready, 2. No, just show me the report |

Store these preferences and act on them during the QA process.

When to Use

This skill activates when:

User invokes /qa command
Another skill references desplega:qa
User asks to test, validate, or QA a feature
The implementing skill encounters a phase with a QA spec

Autonomy Mode

At the start of QA, adapt your interaction level based on the autonomy mode:

| Mode | Behavior | |------|----------| | Autopilot | Execute all test cases, capture evidence, present summary at end | | Critical (Default) | Ask about test case design, present results for review | | Verbose | Walk through each test case, confirm before executing |

The autonomy mode is passed by the invoking command. If not specified, default to Critical.

Process Steps

Step 1: Context & Scope

Determine the source of QA specs. The skill handles three input modes:

Plan path provided → Read the plan, extract ### QA Spec sections from each phase, aggregate into a QA document. Each phase's QA spec becomes a group of test cases.

Separate QA spec document provided → Read the standalone QA spec (could be a dedicated file in thoughts/*/qa/ or any markdown with test scenarios), use it as the basis for the QA session.

No source / PR / issue / description only → Build test cases from scratch with the user. Use AskUserQuestion to establish:

| Question | Options | |----------|---------| | "What are we validating? Please describe the feature or provide context." | [Free text response] |

In all cases, create a QA document from the template at cc-plugin/base/skills/qa/template.md. Write it to thoughts/<username|shared>/qa/YYYY-MM-DD-<topic>.md.

Path selection: Use the user's name (e.g., thoughts/taras/qa/) if known from context. Fall back to thoughts/shared/qa/ when unclear.

Step 2: Test Case Design

Define test cases covering:

Happy path — The main scenario works as intended
Edge cases — Boundary conditions, empty inputs, large inputs
Error scenarios — Invalid inputs, permission failures, network errors

If sourced from a plan: Aggregate phase QA specs into the test case list. Augment with additional exploratory cases.

If sourced from a separate spec: Use those scenarios as the starting point and augment with exploratory cases.

If browser automation was selected and qa-use is available: Design qa-use test steps for each test case (explore → snapshot → interact → screenshot).

Write all test cases into the QA document's ## Test Cases section.

Step 3: Execute Tests

For browser automation (qa-use):

Use qa-use:explore to navigate to the target page
Take snapshots to understand page state
Interact with elements (click, type, navigate)
Capture screenshots as evidence

For manual testing:

Present each test case's steps to the user
Guide them through execution
Use AskUserQuestion to collect results:

| Question | Options | |----------|---------| | "TC-N: [Test case name]. Did it pass?" | 1. Pass, 2. Fail — [describe what happened], 3. Blocked — [describe blocker], 4. Skipped |

For CLI verification:

Execute the CLI commands directly
Compare output against expected results
Record pass/fail automatically

For each test case, record the actual result and pass/fail status.

Step 4: Capture Evidence

Gather evidence for the QA report:

Screenshots: Via qa-use browser screenshots or user-provided
Videos: Session recording URLs (Loom, etc.)
Logs: Console output, error messages, relevant log lines
External links: Sentry issues, CI/CD runs, Grafana dashboards, PR URLs

Add all evidence to the QA document's ## Evidence section.

Step 5: Record Results

Update the QA document with:

Actual results for each test case
Pass/fail/blocked/skipped status per test case
Evidence links inline with relevant test cases
Any issues found in the ## Issues Found section with severity tags (critical/major/minor)

Step 6: Verdict

Aggregate results into an overall verdict:

| Verdict | When | |---------|------| | PASS | All test cases pass, no critical/major issues | | FAIL | Any test case fails, or critical/major issues found | | BLOCKED | Cannot complete testing due to environment/dependency issues |

Write a 1-2 sentence summary in the QA document's ## Verdict section. Update the frontmatter status field to match (pass/fail/blocked).

Step 7: Persist QA Knowledge

If the project's CLAUDE.md or agents.md doesn't document how QA is done for this project, offer to add a QA section describing:

Testing approach used (manual, browser automation, CLI)
Tools used (qa-use, Playwright, etc.)
Common test patterns discovered

Use AskUserQuestion with:

| Question | Options | |----------|---------| | "This project doesn't have documented QA practices. Would you like me to add a QA section to CLAUDE.md?" | 1. Yes, add QA documentation, 2. No, skip this |

Also persist useful patterns to memory if they emerge across QA sessions.

Review Integration

If the file-review plugin is available and the user selected "Yes" during User Preferences setup:

After the QA report is complete, invoke /file-review:file-review <qa-report-path> for inline human comments
Process feedback with file-review:process-review skill
If user selected "No" or autonomy mode is Autopilot, skip this step

Learning Capture

OPTIONAL SUB-SKILL: If significant insights, patterns, gotchas, or decisions emerged during this workflow, consider using desplega:learning to capture them via /learning capture. Focus on learnings that would help someone else in a future session.

Workflow Handoff

After the QA report is complete, use AskUserQuestion with:

| Question | Options | |----------|---------| | "QA complete. What's next?" | 1. Run post-QA verification (→ /verify-plan), 2. Run review on QA report (→ /review), 3. Done |

Based on the answer:

Verify: Invoke the desplega:verifying skill
Review: Invoke the desplega:reviewing skill on the QA document
Done: Finalize the QA report

Agent Skills: QA

Install this agent skill to your local

Skill Files

QA