60-validate-tests-150
[60] VALIDATE. Ensure new (staged and unstaged) changes are covered by tests at >70% and the full test suite is green. Use when asked to validate coverage for recent changes, add tests for modified code, or verify nothing else broke.
Best use case
60-validate-tests-150 is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
[60] VALIDATE. Ensure new (staged and unstaged) changes are covered by tests at >70% and the full test suite is green. Use when asked to validate coverage for recent changes, add tests for modified code, or verify nothing else broke.
Teams using 60-validate-tests-150 should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/60-validate-tests-150/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How 60-validate-tests-150 Compares
| Feature / Agent | 60-validate-tests-150 | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
[60] VALIDATE. Ensure new (staged and unstaged) changes are covered by tests at >70% and the full test suite is green. Use when asked to validate coverage for recent changes, add tests for modified code, or verify nothing else broke.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Validate-Tests 150 Protocol ## Goal Cover current uncommitted changes with meaningful tests at >70% coverage (including **the changed lines**) and confirm the entire test suite is green. ## Workflow 1. **Identify current changes** - Check staged and unstaged changes (`git status`). - List changed files (`git diff --name-only` and `git diff --name-only --staged`). - Focus testing on these files and their direct dependencies. 2. **Find the coverage command** - Check `package.json` scripts for `test`, `coverage`, or `ci`. - If unclear, search for Jest/Vitest config files and default coverage options. 3. **Run coverage** - Execute the project’s coverage command. - Save the exact overall percentage and per‑file coverage for changed files (lines/branches). - Passing tests ≠ coverage: verify that **the changed lines** are executed (use coverage reports to confirm). 4. **Prioritize targets** - Start with changed files that are <70% covered. - Prefer pure functions, utilities, and deterministic logic. 5. **Add tests** - Write tests that directly exercise the **changed logic/markup** and assert behavior, edge cases, and failure paths. - Prefer behavior- or structure-level assertions that map to the changed lines (e.g., DOM structure/classes for UI changes). - Avoid snapshot‑only tests unless behavior is visual and stable. 6. **Re‑run coverage** - Confirm each changed file is **> 70%** covered (lines/branches where available). - Confirm the **specific changed lines** are covered (use coverage reports or direct evidence in tests). - If coverage tooling only provides overall numbers, explain the limitation and justify how tests exercise the changed code. - If not met, repeat steps 4–6. 7. **Run full test suite** - Execute the standard full test command for the repo (not just a subset). - Ensure all tests are green. 8. **Run lint** - Execute the standard lint command for the repo. - Ensure lint is green and **fix lint errors** introduced or surfaced in the process. - Do not leave lint in a failing state. 9. **Run compile** - Execute the standard compile command for the repo `npm run compile` or `tsc --noEmit`, best way is from root directory `npm run test && npm run lint:full` - Ensure compile is green and **fix compile errors** introduced or surfaced in the process. - Do not leave compile in a failing state. 10. **Report** - Summarize added tests, coverage changes, and full test results. - Note any files intentionally excluded or skipped and why. ## Validation checklist - [ ] Staged and unstaged changes identified. - [ ] Coverage command found and recorded. - [ ] Baseline coverage captured. - [ ] Tests added for changed files and direct dependencies. - [ ] Changed files are >70% covered (lines/branches where available). - [ ] Full test suite executed. - [ ] All tests are green. - [ ] Lint executed and green. - [ ] Compile executed and green. ## Output expectations - Provide the command used to measure coverage, to run the full test suite, and to run lint. - Provide before/after coverage numbers and per‑file coverage for changed files. - Explicitly state how the **changed lines** are exercised by the tests. - List which files were targeted and why. - Confirm the final threshold is met for changed files, or report remaining gaps. - Confirm all tests and lint are green. - Confirm compile is green.
Related Skills
add-unit-tests
Guide for adding unit tests to AReaL. Use when user wants to add tests for new functionality or increase test coverage.
deployment-validation-config-validate
You are a configuration management expert specializing in validating, testing, and ensuring the correctness of application configurations. Create comprehensive validation schemas, implement configurat
android-ci-tests
Setup GitHub Actions workflow for running Android tests in CI
testcontainers-integration-tests
Use when integration tests require real infrastructure (database, message queue, cache) or when mocking infrastructure is insufficient. Defines container lifecycle, test isolation, and performance optimization for Testcontainers-based testing.
firebase-development-validate
This skill should be used when reviewing Firebase code against security model and best practices. Triggers on "review firebase", "check firebase", "validate", "audit firebase", "security review", "look at firebase code". Validates configuration, rules, architecture, and security.
Facets Modules Validate
Validate changed Facets modules: lint against all rules defined in rules.md AND run raptor dry-run. Auto-detects changed modules from git diff.
blog-smoke-tests
Run Playwright smoke tests for Denser blog application. Executes 15 tests (SMOKE-01 to SMOKE-15) against configurable environment (production, dev, or localhost) with retry support (max 3 attempts per failing test). Supports headed (visible browser) and headless modes. Collects artifacts (screenshots, trace.zip) on failures and generates HTML report. Use when testing blog functionality, verifying deployments, checking UI/API consistency, or when user requests smoke tests, playwright tests, or blog testing.
61-validate-lint-150
[61] VALIDATE. Comprehensive code quality check combining ESLint, TypeScript compilation, and unused code detection. Runs full lint suite with detailed error reporting and fix suggestions. Use before commits, after major changes, or when ensuring code quality standards.
validate-historical
Validate historical data completeness and quality over date ranges
inference-smoke-tests
Run repeatable inference smoke tests using geppetto/pinocchio example binaries (single-pass, streaming, tool-loop, OpenAI Responses thinking) including tmux-driven TUI tests. Use when refactors touch InferenceState/Session/EngineBuilder, tool calling loop, event sinks, provider request formatting, or when you need a quick 'does inference still work?' checklist.
Validate with Database
Connect to live PostgreSQL database to validate schema assumptions, compare pg_dump vs pgschema output, and query system catalogs interactively
symfony:api-platform-tests
Use when symfony api platform tests