qa-report
QA Test Planner
Plan and document QA deliverables — test plans, test cases, regression suites, Figma validations, and bug reports — in a structured format compatible with qa-execution execution.
Required Inputs
- qa-output-path (optional): Directory where all QA artifacts are stored. When provided, create the directory if it does not exist. When omitted, use the current working directory. This path must match the same argument passed to
qa-executionwhen both skills are used together.
Shared Output Structure
All artifacts follow this directory layout, shared with qa-execution:
<qa-output-path>/qa/
├── test-plans/ # Test plan documents
├── test-cases/ # Individual test case files (TC-*.md)
├── issues/ # Bug reports (BUG-*.md)
├── screenshots/ # Visual evidence and Figma comparisons
└── verification-report.md # Generated by qa-execution
More from compozy/skeeper
skeeper
Explains how to use skeeper to keep spec artifacts (SPEC.md, ADRs, RFCs, plan/PRD/TechSpec markdown, custom globs) next to the code they describe without polluting main-repo history. Covers strict hooks, the tracked skeeper.lock file, namespaces, sync/verify/fsck, safe drift workflows with diff/hydrate/reconcile/rescue/update, adopt/untrack/pattern, repair, SKEEPER_SKIP, and the GitHub Action. Use when setting up skeeper, configuring a sidecar, syncing/verifying a lockfile, recovering drift or failed syncs, auditing bypasses, or wiring CI. Do not use for general Git hook questions, repos with no .skeeper.yml and no intent to add one, or editing skeeper internals.
11agent-md-refactor
Refactor bloated AGENTS.md, CLAUDE.md, or similar agent instruction files to follow progressive disclosure principles. Splits monolithic files into organized, linked documentation.
2cy-create-prd
Creates a Product Requirements Document through interactive brainstorming with parallel codebase and web research. Use when starting a new feature or product, building a PRD, or brainstorming requirements. Do not use for technical specifications, task breakdowns, or code implementation.
2verification-before-completion
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
2deadlock-finder-and-fixer
>-
2cy-review-round
Performs a comprehensive code review of a PRD implementation and generates a review round directory with issue files compatible with cy-fix-reviews. Use when reviewing implemented PRD tasks, creating a manual review round without an external provider, or performing a quality audit of code changes. Do not use for fetching reviews from external providers, fixing existing review issues, executing PRD tasks, or editing source code.
2