ai-Test-Driven Quality

Mission

Produce trustworthy evidence that approved behavior works, fails safely, and remains maintainable across the project's important environments.

Use this skill when

• A test strategy or acceptance evidence is missing.
• A feature should be developed test-first.
• Unit, integration, E2E, accessibility, localization, performance, offline, migration, or recovery behavior needs verification.
• A release requires a risk-based quality decision.

Do not use this skill when

• The primary task is diagnosing an unexplained failure; use systematic debugging first.
• Product expectations are not testable yet; route to planning.

Test design principles

• Derive tests from risks and acceptance criteria, not implementation details alone.
• Prefer deterministic, isolated, repeatable tests with clear oracles.
• Test happy paths, boundaries, invalid input, permissions, concurrency, failure, retry, recovery, and data integrity as applicable.
• Use real boundaries for integration tests where practical; do not let excessive mocks prove a system that cannot work together.
• Keep E2E journeys focused on critical user outcomes and stable selectors.
• Do not access production, spend money, send real communications, or mutate real user data without approval.
• Never weaken assertions, skip failing tests, lower thresholds, or update snapshots blindly to achieve green status.

Workflow

1. Map each acceptance criterion and important risk to one or more tests.
2. Select the cheapest test level that can prove the behavior, adding higher-level tests for critical integration and journeys.
3. Establish baseline failures or gaps.
4. In TDD mode, write a meaningful failing test, implement the minimum behavior, then refactor with the suite green.
5. Prepare isolated fixtures and safe test data. Control time, randomness, network, and concurrency where needed.
6. Run focused tests first, then the appropriate broader suite.
7. Investigate flaky or inconsistent results; do not simply retry until passing.
8. Capture command, environment, duration, result, and artifact evidence.
9. State what was not tested and why.

Load only the relevant playbook:

• references/test-matrix.md
• references/e2e-accessibility.md
• references/performance-resilience.md

Quality decision

Return PASS, CONDITIONAL PASS, or FAIL against the approved scope. Coverage is supporting information, not a substitute for behavior evidence.

Output contract

quality_result:
  decision: PASS | CONDITIONAL_PASS | FAIL
  criteria_mapped: []
  tests_added_or_changed: []
  commands_run: []
  passed: []
  failed: []
  flaky_or_blocked: []
  artifacts: []
  untested_risks: []
  recommended_next_skill: <canonical id>

Specialist boundaries added in 0.8.0

• Route screenshot and visual-regression ownership to ai-visual-quality.
• Route accessibility, localization, Arabic RTL, and assistive-technology ownership to ai-accessibility-and-localization.
• Route measurement-led optimization to ai-performance-optimizer; retain verification of performance acceptance criteria here.

Completion protocol

• Return one standardized status: completed, completed_with_warnings, partial, blocked, failed, needs_approval, or needs_user_input.
• Support every success claim with observable evidence; distinguish facts, assumptions, and unverified items.
• Record material commands, files, artifacts, approvals, and remaining risks without exposing secrets or hidden reasoning.
• Recommend one next skill only when another step is actually required.
• Stop after the defined outcome, an approval gate, a genuine blocker, or the retry budget is exhausted.

Result-strengthening protocol

Before claiming completion: (1) restate the measurable outcome, (2) execute only within the approved scope, (3) verify with observable evidence, (4) actively challenge the result for regressions, missing cases, and unsupported assumptions, and (5) report status using the shared result schema. High-risk work requires an independent challenge pass or a documented reason it could not be performed.

Quality gate

• Critical acceptance criteria and risks have appropriate evidence.
• Tests are repeatable, independent, and do not rely on real production side effects.
• Failures are investigated rather than hidden by retries or weakened assertions.
• The report clearly separates passed, failed, blocked, flaky, and untested areas.