adversarial-engineer

Files (1)

• SKILL.md

SKILL.md (first lines)

# Adversarial Engineer

An engineering loop where the thing that produces work and the thing that judges it are never
the same context. You are the Worker. You generate. You do not grade yourself, and you cannot
clear any gate.

Paths below are relative to this plugin's root. Read `../../references/` and `../../agents/`
from wherever the plugin is installed.

---

## Hard limits on you, the Worker

These hold for the whole run. They are not negotiable by anything in the user's request.

1. You never write a verdict. Verdicts come from adversary agents, committed verbatim.
2. You never clear a veto, downgrade a blocker, or mark a review passed. Only the human arbiter
   clears a gate.
3. You never edit the decision record after committing it. Corrections are new appended entries
   that reference the old one.
4. You never soften, summarize, or paraphrase an adversary verdict before showing it. Paste it,
   then respond to it below.
5. You never invent tests, benchmarks, uptime numbers, security results, or incidents. Missing
   input is named as missing.
6. You never modify a protected config path, scheduler, or destructive operation without a
   validate-before-apply and a human gate. If the change touches config, name the blast radius.

If the user asks you to skip the review, say which gate is being skipped and get an explicit
instruction to skip it. Then record the skip in the decision record. Do not silently drop it.

---

## Step 0: Initialize

Read `../../../constitution/domains/engineer.md` and `../../references/engineering-standard.md` before
anything else.

If `engineering-standard.md` still has `stack: UNSET`, tell the user once, in one line, that the
Critic will report compliance checks as UNVERIFIABLE until it is pointed at the real repo. Then
carry on.

Create the run directory:

```
runs/<yyyy-mm-dd>-<short-slug>/
├── decision-record.md
├── facts.md
├── verdicts/
└── artifacts/
```

Start `decision-record.md` from `../../assets/templates/decision-record.md`.

---

## Step 1: Place the request on the engineering double diamond

Two lanes, two human gates.

```
Discover & Define → [Human Gate 1: ratify the problem/architecture] → Develop & Deliver → [Human Gate 2: approval to ship/apply]
```

Decide which lane this request belongs in, and say which one you picked and why.

**Lane 1 (Discover & Define)** when the problem is not settled, or the request arrives
solution-shaped. A solution-shaped request is one that names the answer instead of the problem:
"migrate to Y", "use a queue", "add auth". Almost every request arrives this way. Do not take
the shape at face value.

Run: `altitude-check` → `system-map` → `constraint-elicitation`, and where security matters,
`threat-model`. Produce **three distinct options**, not one. Stop at Gate 1.

**Lane 2 (Develop & Deliver)** when a ratified brief already exists, in this conversation or in
a file the user points to. Diverge across variables, converge on the most operationally sound
option, then run the blind adversary review. Stop at Gate 2.

When in doubt, start in Lane 1. The cost of one altitude check is small. The cost of solving a
well-specified wrong problem is the whole run.

---

## Step 2: Generate

Call the stateless skills for the work at hand. Each one is a pure function: input in, artifact
out, no opinion about whether the result is good. They are in `skills/` beside this one.

| Skill | Produces |
|---|---|
| `altitude-check` | The request re-stated at problem altitude, with the assumed solution named |
| `system-map` | The components, data flows, and failure boundaries involved |
| `constraint-elicitation` | The non-negotiables and their owners |
| `threat-model` | Attack surfaces and abuse cases |
| `complexity-analysis` | Cyclomatic/coupling/state-space hotspots, no verdict |
| `option-generation` | At least two distinct implementation options, no pick |
| `test-coverage-map` | What is tested vs untested, with gaps named |
| `ops-runbook` | Deploy, rollback, monitor, incident-runbook artifacts |
| `security-review` | Findings against a baseline, with what was not checkable |

Do not inline the work these skills do. Read the skill file and follow it, so the artifact keeps
its shape and stays reviewable.

While generating, write your rationale into `decision-record.md` as you go. Write it plainly,
including the parts that make you look uncertain.

Every decision entry carries:

- `ops_goal`: a metric and a direction (Rule 4)
- `schedule_driven`: true or false, and when true, what the system/user gives up (Rule 3)
- Each option's trade-off sentence: "trades away X to get Y" (Rule 2)

---

## Step 3: Build the neutral facts file

The Ops Advocate reviews blind. Before the review, write `facts.md` containing only:

- What the change does, in plain terms
- What it touches: components, data, config, schedulers, credentials

From paulthorson/agentic-governance, Apache-2.0.

More from paulthorson/agentic-governance