JP's signature red-team pass — "how would I break this?" Argue against your own approach before proceeding. Trigger on any high-stakes decision, architecture choice, or before marking work complete.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Coined by Jaroslav Pantsjoha (#HarnessEngineering). The Adversarial Gate is the practice of forcing an agent — or a human — to argue against their own design before proceeding. It pre-empts bad reasoning before bad output exists.
The gate has one question: "How would I break this?"
Answer it honestly. If you cannot name at least two plausible failure modes, you do not understand the system well enough to ship it.
| Excuse the agent makes | Counter |
|---|---|
| "This is a low-risk change" | All production incidents started as low-risk changes. Name the failure mode or accept you cannot assess risk. |
| "We can fix it after if something breaks" | Blast radius unknown = not low risk. Run the gate. |
| "The tests cover this" | Tests cover happy paths. The gate looks for the paths tests miss. |
| "We've done this before" | Prior success is not a guarantee. Conditions change. Run the gate. |
| "The deadline is today" | A production incident will cost more time than the gate. Run the gate. |
| "I'm confident in this design" | Confidence is the leading indicator of skipped gates. Run it anyway. |
This pattern converges with “doubt-driven development” in Addy Osmani's
agent-skills. The Adversarial Gate name
and “how would I break this?” framing are JP's #HarnessEngineering contribution. The
anti-rationalisation table format was adopted after reviewing that MIT-licensed project;
this repository does not claim the table format originated here.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Google ADK (Agent Development Kit) orchestration patterns — boundaries, agent composition, and tool seams. Trigger when designing or reviewing multi-agent systems built on ADK. Authoritative source: adk.dev.
The English summary is being prepared. Showing the original description.
Read-only SRE checkup of any GCP project: deterministic probes of the edge, Cloud Run services, 7-day error logs, Cloud Scheduler, alert policies and uptime checks, Secret Manager and IAM, the data stores and the machine's own scheduled jobs, audited into one fixed status table (LIVE / WARNING / RED / INCONCLUSIVE) with evidence, findings by severity, what could not be checked, and a single OVERALL line delivered as one notification. Parametrised by a per-project manifest, so the same routine runs on every project. Use when the operator says "cloud checkup", "SRE check", "is everything live", "what's healthy / warning / red", "any errors this week", "audit the infra", "weekly checkup", "set up the weekly checkup", before a deploy or demo, or after an incident. Cloud Run first; App Engine and GKE differ only in the serving probes.
The English summary is being prepared. Showing the original description.
Cloud guardrails for any vendor workload — Google Cloud (GCP, Vertex AI, GKE), AWS (IAM, EKS, Bedrock), Azure (Entra ID, Policy, AKS), Alibaba Cloud (RAM, mainland/international residency). Enforces identity least-privilege, mechanical policy, data boundaries, residency, cost caps, network egress and observability, with official-source validation before any claim. Trigger on any cloud infrastructure design, review, Terraform plan, or LLM/agent deployment; the-architect routes here.
The English summary is being prepared. Showing the original description.
LLM and cloud cost awareness — model tiering, token budgets, right-sizing, and when a cheaper model suffices. Trigger before finalising any architecture that calls LLMs, before scaling a workload, or when a cost estimate is needed.
The English summary is being prepared. Showing the original description.
Challenge vision alignment, value, cost, risk and operating ownership at material scope or release decisions.
The English summary is being prepared. Showing the original description.
Decompose an epic into atomic parallelizable tasks, route each to the right skill, and keep the four delivery records straight — issues, STATUS, ROADMAP, CHANGELOG. Use as a meta-router when several skills could apply, and as the baseline for how delivery state is recorded. Trigger at the start of any multi-track epic, when the skill count exceeds ~12, or when the records have drifted from reality.
The English summary is being prepared. Showing the original description.