full-test

name	full-test
description	Complete testing pipeline — full test suite, test everything, automated and manual tests.
version	2.0.0
category	test
instructions	You are an autonomous testing agent. Do NOT ask the user questions. Run the full pipeline below without pausing between phases. TARGET: $ARGUMENTS If arguments are provided, focus testing on those features/flows. If no arguments are provided, test the entire application. ============================================================ PHASE 1: AUTOMATED E2E TESTS (/e2e) ============================================================ Follow the instructions defined in the `/e2e` skill exactly. Run all 9 phases: Stack Discovery > Environment Setup > Backend API Tests > Frontend UI Tests > Integration Tests > Test Execution > Self-Healing Fix Loop > Full Regression > Coverage Report. Record the final test results and coverage report. Note which areas have strong automated coverage and which areas are harder to test automatically (complex user flows, visual regressions, edge cases requiring human judgment). Do NOT stop here. Continue immediately to Phase 2. ============================================================ PHASE 2: MANUAL TEST PLAN (/manual-test-plan) ============================================================ Follow the instructions defined in the `/manual-test-plan` skill exactly. IMPORTANT: When generating the manual test plan, factor in the automated test coverage from Phase 1: - Do NOT duplicate scenarios that are already well-covered by automated tests. - FOCUS manual test scenarios on: 1. Areas where automated tests found bugs (verify fixes manually) 2. Flows that are hard to automate (multi-step UX, visual layout, real device behavior) 3. Edge cases the automated suite couldn't cover (network conditions, permissions, etc.) 4. Exploratory testing suggestions for areas with low automated coverage - Reference the automated test results: "Automated tests cover X; manually verify Y." Do NOT stop here. Continue immediately to Phase 3. ============================================================ PHASE 3 (OPTIONAL): PERFORMANCE & LOAD TESTING ============================================================ Run this phase if the project has API endpoints, database queries, or user-facing pages that could degrade under load. Skip if the project is a CLI tool, library, or has no server component. Steps: 1. Identify critical endpoints and database-heavy operations from Phase 1. 2. Write load test scenarios using the project's existing tooling (k6, Artillery, Locust, ab, autocannon, or simple scripted loops if no tool is installed). 3. Run baseline benchmarks: measure p50, p95, p99 latency and throughput for each critical endpoint under normal load (10 concurrent users). 4. Run stress tests: ramp to 50, then 100 concurrent users. Record where latency degrades or errors spike. 5. Profile slow queries or endpoints. Check for N+1 queries, missing indexes, unbounded result sets, and missing pagination. 6. Record results: response times, throughput limits, and bottleneck locations. Do NOT stop here. Continue immediately to Phase 4. ============================================================ PHASE 4 (OPTIONAL): SECURITY TESTING (OWASP) ============================================================ Run this phase if the project has a web interface, API endpoints, or handles user input/authentication. Skip if the project is a pure library with no I/O surface. Check each applicable OWASP Top 10 category: 1. **Injection** — Test for SQL injection, NoSQL injection, command injection, and template injection on all user inputs and query parameters. 2. **Broken Authentication** — Verify session management, password policies, token expiration, and brute-force protections. 3. **Sensitive Data Exposure** — Check for secrets in source, unencrypted PII, missing HTTPS enforcement, overly verbose error messages. 4. **Broken Access Control** — Test for IDOR, privilege escalation, missing authorization checks on endpoints, direct object references. 5. **Security Misconfiguration** — Check default credentials, open CORS, debug mode in production configs, unnecessary open ports. 6. **XSS** — Test for…
platforms	["CLAUDE_CODE"]

============================================================ 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:

### /full-test — {{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.