Test Suite

You are in AUTONOMOUS MODE. Do NOT ask questions. Analyze the project's test coverage across all testing dimensions, identify gaps, and produce an actionable health report.

INPUT: $ARGUMENTS

If arguments are provided, focus analysis on those specific areas or modules. If no arguments are provided, analyze the ENTIRE project.

============================================================ PHASE 1: PROJECT DISCOVERY

Step 1.1 -- Tech Stack Detection

Auto-detect the project's technology stack by scanning for configuration files:

Detect the application type:

• BACKEND_ONLY: API/service with no frontend
• FRONTEND_ONLY: Frontend app with external API
• FULLSTACK: Both backend and frontend
• MOBILE: Mobile app (Flutter, React Native, SwiftUI)
• LIBRARY: Reusable package or SDK

Record: language, framework, application type, entry points, source directories.

Step 1.2 -- Test Infrastructure Inventory

Scan the project for ALL existing test-related files and configuration:

DIRECTORIES to check:

• test/, tests/, tests/, spec/, e2e/, cypress/, integration_test/
• playwright/, .storybook/, k6/, locust/, artillery/, load-test/
• contract/, pact/, snapshots/, snapshots/

CONFIG FILES to check:

• jest.config., vitest.config., pytest.ini, pyproject.toml [tool.pytest]
• playwright.config., cypress.config., .mocharc.*
• .nycrc, .coveragerc, codecov.yml, lcov.info, coverage/
• backstop.json, .percy.yml, chromatic.config.*
• pact-config.*, dredd.yml, .spectral.yaml
• lighthouserc.*, .axe.json, pa11y.json

TEST SCRIPTS in package.json (or equivalent):

• test, test:unit, test:integration, test:e2e, test:load, test:visual, test:a11y
• coverage, lint, typecheck

Build a complete inventory table:

Step 1.3 -- Source Code Analysis

Count source files and estimate testable surface area:

• Total source files (exclude node_modules, vendor, build, dist)
• Total functions/methods exported or public
• Total API endpoints (routes, controllers)
• Total UI components or screens
• Total data models or entities

============================================================ PHASE 2: TEST COVERAGE ANALYSIS

Step 2.1 -- Run Existing Coverage Tools

If coverage tools are configured, run them:

Parse the coverage output to extract:

• Line coverage percentage
• Branch coverage percentage
• Function coverage percentage
• Files with 0% coverage
• Files with < 50% coverage

Step 2.2 -- Categorize Existing Tests

Read every test file and classify each test into a category:

Build the categorized test count:

Step 2.3 -- Gap Identification

For each testing category, assess whether coverage exists and rate it:

UNIT TESTS:

• Are business logic functions covered?
• Are utility/helper functions covered?
• Are edge cases tested (null, empty, boundary values)?
• Are error paths tested?

INTEGRATION TESTS:

• Are API endpoints tested end-to-end?
• Are database operations tested (CRUD, transactions)?
• Are external service integrations tested (with mocks)?
• Are authentication/authorization flows tested?

E2E TESTS:

• Are critical user flows covered?
• Are form submissions tested?
• Are navigation flows tested?
• Are error states tested?

LOAD TESTS:

• Are performance baselines established?
• Are critical endpoints load-tested?
• Are spike/stress scenarios defined?

VISUAL REGRESSION TESTS:

• Are critical pages captured at multiple breakpoints?
• Is there a baseline for comparison?
• Are dynamic content areas handled?

CONTRACT TESTS:

• Are API schemas validated?
• Is backward compatibility verified?
• Are consumer-driven contracts in place?

ACCESSIBILITY TESTS:

• Are WCAG 2.1 AA standards checked?
• Is keyboard navigation tested?
• Are all routes/pages scanned?
• Is Lighthouse CI configured?

============================================================ PHASE 3: SCORING AND HEALTH REPORT

Step 3.1 -- Score Each Category

Rate each testing category on a 0-10 scale:

Calculate an overall health score as a weighted average:

• Unit tests: 30% weight
• Integration tests: 25% weight
• E2E tests: 20% weight
• Load tests: 5% weight
• Visual regression: 5% weight
• Contract tests: 5% weight
• Accessibility: 10% weight

Step 3.2 -- Priority Ranking

Rank gaps by impact. Consider:

• What breaks production most often? (usually integration + unit gaps)
• What blocks releases? (usually E2E + contract gaps)
• What causes user complaints? (usually a11y + visual gaps)
• What causes incidents? (usually load + integration gaps)

============================================================ PHASE 4: REMEDIATION ROUTING

For each identified gap, recommend which sub-skill to run:

============================================================ SELF-HEALING VALIDATION (max 3 iterations)

After generating and running tests, validate:

1. All generated test files compile/parse without syntax errors.
2. Run the generated tests — capture pass/fail results.
3. If tests fail due to test code bugs (not application bugs), fix the test code.
4. Re-run to confirm tests pass or legitimately fail on application issues.
5. Repeat up to 3 iterations.

IF STILL FAILING after 3 iterations:

• Separate test failures into: test bugs vs application bugs
• Fix test bugs, document application bugs

============================================================ OUTPUT

Print the full health report:

Test Coverage Health Report

Project Summary

• Project: [name from package.json, pubspec.yaml, etc.]
• Stack: [language + framework]
• Type: [BACKEND_ONLY / FRONTEND_ONLY / FULLSTACK / MOBILE / LIBRARY]
• Source files: [count]
• Testable surface: [endpoints, components, functions count]

Coverage Scores

Line Coverage (if available)

• Overall: X%
• Files with 0% coverage: [list top 10]

Critical Gaps (prioritized)

1. [Gap] -- [why it matters] -- Run: /[skill]
2. [Gap] -- [why it matters] -- Run: /[skill]
3. ...

Existing Test Quality Notes

• [observations about test quality, naming, organization, flakiness]

Recommended Test Plan

Run these skills in order to achieve comprehensive coverage:

1. /[skill] -- [what it will add]
2. /[skill] -- [what it will add]
3. ...

Estimated improvement: current N/10 -> projected N/10 after remediation.

NEXT STEPS:

• "Critical unit test gaps? Run /unit-test to generate missing unit tests."
• "No integration tests? Run /integration-test to cover API and database operations."
• "Frontend with no visual regression? Run /visual-regression to set up baseline screenshots."
• "API without contract tests? Run /contract-test to validate schemas."
• "Accessibility gaps? Run /accessibility-test to check WCAG 2.1 AA compliance."
• "Need load testing? Run /load-test to establish performance baselines."
• "Want full E2E coverage? Run /e2e for comprehensive end-to-end testing."

DO NOT:

• Do NOT generate or run tests in this skill. This is analysis and routing only.
• Do NOT modify any source code or test files.
• Do NOT install any packages or frameworks.
• Do NOT skip any testing category in the analysis, even if it seems irrelevant.
• Do NOT inflate scores. A category with zero tests gets a zero score.
• Do NOT recommend skills that are irrelevant to the project type (e.g., no visual regression for a CLI tool, no load tests for a static library).

============================================================ SELF-EVOLUTION TELEMETRY

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:

• Look for the project path in ~/.claude/projects/
• If found, append to skill-telemetry.md in that memory directory

Entry format:

### /test-suite — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}

Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.