61 lines
2.2 KiB
Markdown
61 lines
2.2 KiB
Markdown
---
|
|
name: zero-check
|
|
description: Run the zero-check validation gauntlet after completing any code generation or modification task. Use this skill whenever you finish writing, editing, or generating Python or Go code — including new files, bug fixes, refactors, or adding features. Also use when the user asks to validate, check, audit, lint, or scan their code. Do not wait to be asked — run automatically after any code change. Runs security scanning, linting, SAST, dependency audits, and tests, then retries up to 3 times if issues are found.
|
|
---
|
|
|
|
# Zero-Check Validation Pipeline
|
|
|
|
## When to run
|
|
|
|
Run this skill automatically after completing any code generation or modification task. Do not wait to be asked.
|
|
|
|
## How to run
|
|
|
|
Execute the gauntlet against the current project directory:
|
|
|
|
```bash
|
|
~/zero-check-pipeline/validate/run-all.sh "$(pwd)"
|
|
```
|
|
|
|
After execution, read the results file:
|
|
|
|
```bash
|
|
cat ~/zero-check-pipeline/validate/results.json
|
|
```
|
|
|
|
## Interpreting results
|
|
|
|
- If `overall` is `passed` — report success to the user and move on.
|
|
- If `overall` is `failed` — enter the retry loop.
|
|
|
|
## Retry loop rules
|
|
|
|
1. Read `results.json` and identify which checks failed.
|
|
2. Fix ONLY the issues identified by the failing checks. Do not refactor or change anything else.
|
|
3. Re-run the gauntlet: `~/zero-check-pipeline/validate/run-all.sh "$(pwd)"`
|
|
4. Read `results.json` again.
|
|
5. Repeat up to 3 total attempts.
|
|
6. If still failing after 3 attempts, STOP. Report the remaining failures to the user and ask for guidance.
|
|
|
|
## Critical constraints
|
|
|
|
- NEVER modify any file in `~/zero-check-pipeline/validate/`. The check scripts are read-only.
|
|
- NEVER weaken a test, broaden an exception handler, or comment out code to make a check pass.
|
|
- NEVER remove or skip a failing test. Fix the code, not the test.
|
|
- Each retry attempt should be a separate commit with a message describing what was fixed.
|
|
|
|
## Commit messages for retries
|
|
|
|
Use this format:
|
|
|
|
```
|
|
gauntlet: fix <check_name> — <brief description of fix>
|
|
```
|
|
|
|
Examples:
|
|
|
|
```
|
|
gauntlet: fix lint — removed unused imports
|
|
gauntlet: fix sast — replaced eval() with ast.literal_eval()
|
|
gauntlet: fix secrets — moved API key to environment variable
|
|
``` |