skeeper

Executes full-project QA like a real user by discovering the repository verification and E2E contracts, running build, lint, test, and startup commands, exercising core workflows end-to-end through CLI, HTTP, and browser interfaces, requiring automated regression coverage for supported critical flows, fixing root-cause regressions, and rerunning the full gate. Uses the agent-browser companion skill for Web UI validation when a web surface exists. Use when validating a branch, release candidate, migration, refactor, or risky commit. Do not use for static code review only, one-off unit test edits, planning test cases, or architecture brainstorming without execution — use qa-report for planning and documentation.

Generate comprehensive test plans, test cases, regression test suites, automation annotations, and bug reports for QA engineers. Includes Figma MCP integration for design validation. Use when planning QA before execution, documenting test strategies, marking which flows require E2E follow-up, or creating structured bug reports. Do not use for executing tests against a live repository or running verification gates — use qa-execution for that.

Explains Compozy capabilities, CLI commands, core workflow skills, optional extension skills, configuration, artifact structure, reusable agents, and extensions. Use when the user asks how to use Compozy, what commands are available, how the workflow pipeline works, or how to configure a workspace. Do not use for executing workflow steps — use the specific cy- skills instead.

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.

Runs an optional cross-LLM peer review of a TechSpec via compozy exec --ide claude --model opus --reasoning-effort xhigh and packages findings for user-directed incorporation. Use when a TechSpec draft has already been approved by the user and they want an external review round, especially for autonomy/network/memory-impacting designs. Do not use for PRDs, automatic approval gates, code review batches, or auto-looped review cycles.

Decomposes PRDs and TechSpecs into detailed, independently implementable task files with enrichment from codebase exploration. Use when a PRD or TechSpec exists and needs to be broken down into executable tasks, or when task files need enrichment with implementation context. Do not use for PRD creation, TechSpec generation, or direct task execution.

Creates a Technical Specification by translating PRD business requirements into implementation designs through interactive technical clarification. Use when a PRD exists and needs a technical plan, or when technical architecture decisions need documentation. Do not use for PRD creation, task breakdown, or direct code implementation.

Executes one PRD task end-to-end using a provided task file, PRD directory, tracking file paths, and auto-commit mode. Use when a prompt includes a task specification that must be implemented, validated, and reflected in task tracking files. Do not use for PR review batches, generic coding tasks without a PRD task file, or standalone verification-only work.

Loads the AGH spec authoring playbook plus relevant lessons, standing directives, glossary, and active context before cy-create-prd, cy-create-techspec, or cy-create-tasks runs. Applies phase-specific checks: PRDs stay business-focused, TechSpecs carry the six quality markers, and every spec/task captures extensibility integration, agent-manageability, config lifecycle, QA tail coverage, and Web/Docs Impact. Use whenever an AGH spec authoring skill is about to run. Do not use for spec execution, review remediation, or non-spec brainstorming output.

Find and fix concurrency bugs - deadlocks, races, livelocks, await-holding-lock, database locks, LD_PRELOAD init, swarm races. Use when processes hang, tests flake, or auditing concurrency.

Intelligently handle git rebase operations and resolve merge conflicts while preserving features and maintaining code quality. Use when rebasing feature branches, resolving conflicts across commits, and ensuring clean linear history without losing changes.

Analyzes codebases to identify refactoring opportunities based on Martin Fowler's catalog of code smells and refactoring techniques. Detects duplicated code, high coupling, complex conditionals, primitive obsession, long functions, and other structural issues. Produces a structured refactoring report with prioritized findings saved to docs/_refacs/. Use when auditing code quality, preparing for a refactoring sprint, or reviewing architectural health. Don't use for style/formatting issues, performance optimization, or security audits.