validating-in-realitylisted

Validate a bugfix or feature against the REAL running system — execute the user's cURL, assert actual responses, check persisted database state, and drive the UI end-to-end — instead of assuming the code change works. Use whenever the user provides a cURL command, a localhost/endpoint URL, or asks to "validate", "test it for real", "check the database", "no assumptions", or when finishing a bugfix/feature in a project with a running server. The user's cURL IS the acceptance test. Not a substitute for writing-tests (automated coverage) or /verify (static gates) — this is live-system proof on top of them.
Cristhianzl/claude-skills-czl · ★ 5 · AI & Automation · score 80

Install: claude install-skill Cristhianzl/claude-skills-czl

# Validating in reality A change isn't done because the code looks right — it's done when the **running system proves it**. This skill turns a user-provided cURL (or endpoint, or repro) into the acceptance test, and replaces "should work" with pasted evidence. ## Read first (always) List `learnings/` and read anything relevant — how this project starts its server, seeds data, connects to the DB, and authenticates test requests lives there and overrides the defaults here. ## The principle: evidence over inference Reading the diff tells you what the code *should* do. Only the running system tells you what it *does*. When the user supplies a cURL, an endpoint, or a repro, that artifact is the **definition of done** — the task is complete when it behaves correctly against the live system, and you have the output to show it. ## Workflow 1. **Confirm the system is running.** Find the server (the project's run command, `docker compose ps`, the port in the cURL). If nothing is running and you can't start it with the project's documented command, **say so explicitly and stop** — never simulate a validation you didn't run. 2. **Run the acceptance test BEFORE the change** (bug: prove it reproduces — the live RED, mirroring `fixing-bugs`; feature: prove the behavior is missing). Paste the actual response. 3. **Implement** (per `fixing-bugs` / `developing-features` — tests included as usual). 4. **Run the acceptance test AFTER.** Paste the actual response and diff it against the BE