القائمة
Use when about to call any integration, deployment, or hard guarantee "done" — prove it live end-to-end and capture the run as evidence.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when wiring a project's dev workflow (local stack, test tiers, gates, docs), or when naming make targets in a repo that has siblings — build a thin self-documenting Makefile facade over real scripts, name targets from the shared cross-repo vocabulary, and split env files by owner so targets consume them but never write them.
Use when you need to prove a feature actually delivers its intended outcome to a user or caller, not just that its code paths run — write executable acceptance tests against real, observable outcomes, derived from the spec before or independent of the implementation.
Use when adding any new capability to a working system — ship it behind a flag or optional collaborator that defaults to prior behavior.
Use when a spec, plan, or implementation must be independently reviewed before it is trusted, committed, or advanced to the next phase — dispatch a fresh reviewer per named lens whose job is to refute the artifact, not confirm it.
Use when building automation that edits, tests, or deploys itself — an agent that regenerates its own code, a self-updating pipeline, any loop that modifies the thing running it.
Use when a value (project id, model, threshold, rubric) would be duplicated across Makefile, scripts, docs, and code — collapse to one source.
| name | battle-testing-on-real-infra |
| description | Use when about to call any integration, deployment, or hard guarantee "done" — prove it live end-to-end and capture the run as evidence. |
Nothing involving an external system, a deployment, or a durability/resume guarantee is "done" until it has run against real infrastructure, end-to-end, with the result captured as evidence. Mocks prove your wiring; only a live run proves reality.
Reach for this skill whenever you are about to mark complete: an integration with a third-party API or provider, a deployment to a real environment, or any hard guarantee (durability, idempotency, cross-process resume, exactly-once, failover).
Red-flag thoughts — if you catch yourself thinking any of these, STOP and apply this skill:
live test marker, a make test-live target, a tagged CI stage, or a dedicated script. The default suite stays fast; the live gate is explicit and on-demand. On-demand must never decay into optional: when the live gate cannot run in CI, wire it into a required checkpoint — a mandatory release/merge checklist step, with the evidence artifact traveling on the claiming commit (an Evidence: trailer, a committed results file). An optional gate is not a gate.Mocks encode your assumptions, so they can only ever confirm them. Real systems fail in ways you did not think to mock: a provider silently consumes a budget you assumed was yours, an endpoint returns a status the docs never list, a "durable" store loses a write across a process boundary, a deployment IAM permission propagates too slowly. Each of these passes every mock and breaks in production. The cost of skipping the live gate is paid later and larger — in an incident, a customer-visible data loss, or a wrong architectural commitment that is expensive to unwind. A captured evidence artifact also converts "trust me" into something a reviewer, a future you, or another agent can verify without rerunning anything.
On the project this was distilled from — a hexagonal, human-in-the-loop AI agent shipped to a cloud runtime — the riskiest claim was that a paused run could resume after the original process was gone. Rather than assert it from the checkpointer's design, a dedicated live test (tests/live/test_checkpointer_live.py) paused a run on one saver instance and resumed it on a brand-new saver pointed at the same real managed document database; the resume write surviving that process boundary is what proved the guarantee, and the run was captured as a machine-readable artifact — docs/evidence/serverless-live.json pins the test path, the managed document database, a per-resource PASS, and the teardown. Separately, probing the real model provider revealed that an output-token budget set to 2048 was being silently consumed by reasoning tokens before any answer was produced (the evaluation write-up) — a provider-specific defect no mock could reproduce. The live finding directly changed engineering: max_output_tokens was raised from 2048 to 8192. The portable lesson: pick your single hardest guarantee, build one live test that can only pass if it is actually true, run it against real backends, and keep the captured result.
A second build the pack draws on — a REST API client covering an external system's entire surface, verified against a containerized live server — reinforced the same rules at scale. Its published spec and the running server disagreed on roughly twenty points — for example, a method the spec typed as GET with a JSON body that the server served as POST multipart; a field the spec marked writable that the server refused to update; an endpoint whose documented request path the server rejected for another — and each was found by probing live, implemented as the server behaved, and recorded in the calling method's own code rather than a side report. Endpoints whose happy path needed infrastructure the rig lacked — an enrolled device, a paid account, a peer cluster — were still driven live and asserted against the server's exact rejection, so a routing typo could not pass as "skipped." The two model-backed features were round-tripped through a small local model behind a standard HTTP API rather than a mock. Same lesson, wider surface: the running system, not the document, is the authority, and "no infra" is a reason to assert the real error, not to stop testing.
A third field test found the inverse failure: a client repo whose live integration suite existed but was wired into no gate at all — CI never ran it, and the release checklist listed it as "optional, if client logic changed." A commit claiming complete API coverage shipped nine integration tests that had never run green against the live server (they exercised features the server gates behind flags the tests never enabled). The gap was not missing tests; it was a live gate nothing required. The fix was as much process as code: the suite became a named, required pre-release step, and the tests were fixed against the live server the same day.
The only real way to know something works is to go live with it with a real test. Battle-test it.
What a machine can check: that the live gate exists, runs, and leaves evidence. A named, required checkpoint — a release-checklist step, a make test-live target distinct from the unit run — because an optional gate is not a gate; the Evidence: trailer required on commits touching live-surface paths (check-evidence-trailer.sh in git-controls-starter); evidence artifacts committed as files a reviewer can open, with the runner recorded by role — check-no-private-identifiers.sh blocks the identity from entering at all.