Repository Validation
This is the general-purpose fallback for deciding how to validate a change when nothing else has specified it. Repository instructions and documented validation commands take precedence over these defaults.
Proportionate means matching the checks' scope and cost to the blast radius of
the change. Run the smallest sufficient set that covers the changed artifact
and behavior, widening to integration or end-to-end checks as the change's
reach grows.
Discover the Checks
- Read applicable
AGENTS.md, README, contributor guidance, and nearby automation before choosing commands.
- Inspect changed file types and available configuration such as
.editorconfig, package manifests, CI workflows, task runners, and formatter or linter settings.
- Prefer an existing documented check over inventing a new one.
Choose Proportionate Validation
- Documentation: review readability and run
git diff --check; run an available Markdown check when the repository uses one.
- Source code: when edits are authorized, format only changed files. Run focused tests, static analysis, or builds that exercise the change. For read-only review, report formatting differences without changing files.
- Configuration, templates, and scripts: render, parse, or dry-run the affected artifact, and run a syntax check when applicable.
- Broad or risky changes: add the relevant integration or end-to-end check when available.
Start with read-only checks. Do not install dependencies, apply configuration, migrate data, publish artifacts, or otherwise change external state merely to validate unless the task authorizes those effects.
Report Results
- Review failures against the changed behavior before declaring them regressions.
- Report each exact command or named check and classify its result as passed,
change-related failure, pre-existing failure, environment blocker, or skipped.
- For skipped checks, state why they were unavailable or disproportionate and
identify the remaining risk.
1---2name: jww-repository-validation3description: Select, run, and report proportionate validation for repository changes when no more specific validation workflow applies. Use after editing code, configuration, templates, documentation, or automation; do not use when a language-specific skill already covers the change.4---56# Repository Validation78This is the general-purpose fallback for deciding how to validate a change when nothing else has specified it. Repository instructions and documented validation commands take precedence over these defaults.910Proportionate means matching the checks' scope and cost to the blast radius of11the change. Run the smallest sufficient set that covers the changed artifact12and behavior, widening to integration or end-to-end checks as the change's13reach grows.1415## Discover the Checks16171. Read applicable `AGENTS.md`, `README`, contributor guidance, and nearby automation before choosing commands.182. Inspect changed file types and available configuration such as `.editorconfig`, package manifests, CI workflows, task runners, and formatter or linter settings.193. Prefer an existing documented check over inventing a new one.2021## Choose Proportionate Validation2223- Documentation: review readability and run `git diff --check`; run an available Markdown check when the repository uses one.24- Source code: when edits are authorized, format only changed files. Run focused tests, static analysis, or builds that exercise the change. For read-only review, report formatting differences without changing files.25- Configuration, templates, and scripts: render, parse, or dry-run the affected artifact, and run a syntax check when applicable.26- Broad or risky changes: add the relevant integration or end-to-end check when available.2728Start with read-only checks. Do not install dependencies, apply configuration, migrate data, publish artifacts, or otherwise change external state merely to validate unless the task authorizes those effects.2930## Report Results31321. Review failures against the changed behavior before declaring them regressions.332. Report each exact command or named check and classify its result as passed,34 change-related failure, pre-existing failure, environment blocker, or skipped.353. For skipped checks, state why they were unavailable or disproportionate and36 identify the remaining risk.
Justin