home / skills / vadimcomanescu / codex-skills / senior-qa
This skill helps you design risk-based QA plans, optimize test layer choices, and triage flaky tests to ensure reliable releases.
npx playbooks add skill vadimcomanescu/codex-skills --skill senior-qaReview the files below or copy the command above to add this skill to your agents.
---
name: senior-qa
description: "QA workflow for building test strategies and validating releases: risk-based testing, test pyramid decisions, E2E/integration/unit coverage, exploratory testing, and regression planning. Use when creating test plans, reviewing test coverage, triaging flaky tests, or preparing release sign-off criteria."
---
# Senior QA
Optimize for confidence per unit effort.
## Quick Start
1) Identify the risky user journeys (money, auth, data loss, critical flows).
2) Choose the right test layer:
- unit for logic, integration for boundaries, E2E for key paths
3) Define a release test plan:
- must-pass automated tests + focused manual checklist
4) Treat flakiness as a product bug: root-cause it and fix it.
## Optional tool: scaffold a test plan doc
```bash
python ~/.codex/skills/senior-qa/scripts/scaffold_test_plan.py . --out docs/qa --force
```
## References
- Test plan template: `references/test-plan.md`
This skill codifies a senior QA workflow to maximize confidence per unit effort when planning and validating releases. It guides risk-based testing, layer selection (unit/integration/E2E), exploratory testing, and regression planning. Use it to create focused test plans, reduce flakiness, and define clear release sign-off criteria.
The skill inspects product risk areas and recommends test layer decisions: unit tests for logic, integration tests for boundaries, and E2E for critical user journeys. It helps produce a release test plan that separates must-pass automated checks from targeted manual checks and includes strategies for exploratory testing and regression scope. It also surfaces flaky-test triage steps, treating recurrent flakiness as actionable product debt.
How do I pick which journeys are 'risky'?
Prioritize flows that impact revenue, account access, data integrity, or core user retention. Use usage metrics and business impact to rank them.
When should I add a new E2E test?
Add an E2E when a journey cannot be reliably validated by unit or integration tests and its failure has high user or business impact.
What if tests keep flaking after fixes?
Quarantine the test to avoid noise, add instrumentation to capture failure context, and track flakiness as technical debt until root cause is eliminated.