generate-backpressure

# Generate BACKPRESSURE.md This skill generates a `BACKPRESSURE.md` file for a software project. The file defines deterministic checks that AI coding agents run to verify their own work without human intervention. ## When to Use - Starting a new project and want to set up agent self-verification - Existing project has no formalized checks for agent workflows - User says "generate backpressure", "create checks for agents", "set up back pressure" - After a failed agent session where wrong assumptions leaked into implementation ## Process ### 1. Discover Existing Checks Read these files to find what the project already has: **Package managers** (find build/test/lint scripts): - `package.json` scripts - `pyproject.toml` [tool.*] sections and [project.scripts] - `Cargo.toml` [profile.*] and Makefile targets - `go.mod` and Makefile targets **CI/CD** (find checks the team already runs): - `.github/workflows/*.yml` - `Jenkinsfile`, `.gitlab-ci.yml` **Static analysis config** (find configured tools): - `tsconfig.json`, `.eslintrc*`, `biome.json` - `mypy.ini`, `pyproject.toml [tool.ruff]`, `pyproject.toml [tool.mypy]` - `clippy.toml`, `rustfmt.toml` **Test directories** (confirm tests exist): - `tests/`, `__tests__/`, `spec/`, `test/`, `*_test.go` **Agent config** (find existing check references): - `CLAUDE.md`, `AGENTS.md`, `.cursorrules`, `.cursor/rules/` ### 2. Extract from PRD (if provided) If the user provides a PRD or requirements doc: - Extract acceptance criteria that can be expressed as CLI commands - Map performance requirements to budget checks - Map API contracts to learning test candidates - Map architectural constraints to import/dependency checks ### 3. Generate the File Write `BACKPRESSURE.md` at the project root using this format: ```markdown # BACKPRESSURE.md > Deterministic verification checks for [project-name]. > Agents: run these checks after every code change. Do not proceed if blocking checks fail. ## Build - `<command>` — <expected result> - severity: blocking - when: after-every-change ## Types - `<command>` — <expected result> - severity: blocking - when: after-every-change ## Tests - `<command>` — <expected result> - severity: blocking - when: after-every-change ## Lint - `<command>` — <expected result> - severity: blocking - when: before-commit ``` Additional sections as needed: Architecture, Contracts, Performance, Custom. ### Check Format ```markdown - `<shell command>` — <what "pass" looks like> - severity: blocking | warning - when: after-every-change | before-commit | on-demand - notes: <why this check exists> ``` **Rules:** - Commands must be copy-paste runnable from project root - Default severity: `blocking` - Default when: `after-every-change` - Slow checks (>30s): set to `before-commit` or `on-demand` - Section order: Build > Types > Lint > Tests > Architecture > Contracts > Performance > Custom - No LLM-as-judge checks. No human-in-the-loop checks. Deterministic only. ### 4. Validate Before writing the file: - [ ] Every command exists in the project (not fabricated) - [ ] Every command runs from project root - [ ] At least 3 sections have real checks - [ ] No checks require LLM judgment - [ ] No checks require human interaction - [ ] Max 15-20 checks total ### 5. Integrate After generating, add a reference to the project's agent config: **If CLAUDE.md exists**, append: ```markdown ## Verification Read BACKPRESSURE.md. Run all blocking checks after code changes. Do not proceed on failure. ``` **If .cursorrules exists**, append: ``` Read BACKPRESSURE.md for verification checks. Run blocking checks after every code change. ``` ## Output The generated `BACKPRESSURE.md` file, written to the project root. Report to the user: - How many checks were generated - Which sections were populated - Any sections that were skipped and why - Suggested checks to add manually (if there are gaps)