/hayden Skill  ·  Boyan Balev

Two agents. One brief. Nothing lost in translation.

Hayden is a Staff+ orchestration skill for coding agents. He does the recon himself, writes two briefs, reads two handoffs, and closes. Hashi plans the change and then tries to break his own plan. Ahsoka builds it and then reviews it as the person who must sign it off. The result is the smallest complete change, consistent with the codebase, in about thirty minutes rather than an afternoon.

1 orchestrator 2 subagents, strictly sequential 15 laws 5-point bar for every finding 0 lines of production code written by Hayden
A young commander in blue armour stands in front of a starship window overlooking a cloud-covered planet, flanked by two armoured troopers.
One commander who never touches the code. Two specialists who own every line of it. Hayden · recon & closeHashi · planAhsoka · build

The sentence nobody wrote

The bug was never in the code. It was in the brief.

Hayden used to be the fastest engineer in every room. The incidents that followed him were never in his code. They were in a sentence he didn't write. He once handed a ticket to someone brilliant and left out one line: the orders table also had a nightly job writing to it. The code that came back was correct for the world he had described. That world was wrong.

Agents have the same failure, only faster. An agent knows exactly what you wrote and nothing else. When a model "hallucinates an architecture", half the time it was simply handed a description of a simpler system than the one in the repo, and it built faithfully for that simpler system. So the skill treats recon as the real work, compressed into forty lines someone else can act on.

That belief shapes everything else on this page: who is allowed to talk to whom, how many agents exist at all, what goes into a brief and what is forbidden from it, and why the orchestrator is the one character who never edits a line of production code.

An agent knows exactly what you wrote, and nothing else.The first line of every brief Hayden writes is the one the ticket forgot.

Why not five agents

Five agents in a row is a game of telephone.

The tempting design gives every responsibility its own agent: an analyst, an architect, a planner, a builder, a reviewer. It looks rigorous on a diagram. In practice each handoff is a lossy summary of a summary, and the agent at the end of the chain is building for a world described five times over by agents who each saw a little less of it.

The relay: five specialists, four handoffs

Context decays every hop

Analyst

Reads the repo, writes findings.

100%

Architect

Reads findings, not the code.

90%

Planner

Reads the design, not the findings.

81%

Builder

Executes a plan it can't question.

73%

Reviewer

Judges a diff without the "why".

66%

Hayden: one recon, two owners, each re-reads the code

The code is the source of truth

Hayden · recon

Facts marked verified or unverified, with path#symbol.

100%

Hashi · plan + attack

Re-verifies recon against the code, then breaks his plan.

re-grounded

Ahsoka · build + review

Checks the plan against the code before the first edit.

re-grounded

Hayden · close

Fresh shell. Every claim needs evidence he can see.

verified

Illustrative: if each handoff keeps 90% of what matters, five agents in a chain keep 0.9⁴ ≈ 66% by the last one. The fix isn't a better summary; it's fewer summaries, and agents that re-read the code instead of trusting the agent before them.

  1. 01

    Every handoff is a compression.

    A subagent replies in thirty lines, and thirty lines cannot carry everything it saw. The nightly job, the second caller, the flag defaulting to off: each hop drops the detail that looked minor to that agent. With five hops, the dropped details compound.

  2. 02

    Nobody owns the plan, so nobody defends it or fixes it.

    An architect designs, a planner sequences, a builder executes. When the code disagrees with the plan, the builder has no authority to change it and the planner is gone. In Hayden, Hashi owns the plan end to end and is the one paid to attack it. Ahsoka can deviate, but must log why.

  3. 03

    A reviewer who never built it only checks the surface.

    A separate review agent reads a diff with no idea why each line exists, so it checks style and misses intent. Ahsoka reviews her own build after a deliberate change of hats: she knows every reason, and her job is to argue each one against itself, mutation-test the lines that carry the change, and fix what survives.

  4. 04

    Cold starts repeat the expensive part.

    Every fresh agent re-explores the repo to orient itself. Five agents means five rounds of reading the same files. Hayden does recon once, in the main session, and points the subagents to exact symbols instead of pasting files, so the thirty-minute target comes from context discipline, not from skipping proof.

  5. 05

    More voices produce averages, not verdicts.

    Five opinions turn into negotiation, and the result is the midpoint between them, which usually fits nobody's problem. Two agents with the same Law and the same objective, each independently re-checking against the code, give a verdict. Disagreement grounded in code is welcome, and it gets logged.

The cast

Three roles. Each attacks its own work.

The pairing is the design. Author and critic share one context, so nothing is lost between them, and a forced change of hats keeps the critic honest. Each subagent is spawned fresh, strictly one at a time, and carries the Law and Field sense verbatim.

Orchestrator · main session

Hayden

Does the recon, sizes the task, writes both briefs, gates the plan and closes in a fresh shell. Never edits production code, so his judgement is never clouded by attachment to a diff.

  • INthe task
  • OUT00-recon.md · the report
  • NEVERedits code

Subagent · plan, then attack

Hashi

Re-verifies recon, weighs two or three approaches, and picks the smallest complete one. Then he attacks the plan as if a respected colleague wrote it, deletes what isn't needed, and returns a verdict.

  • INbrief · recon
  • OUT01-plan.md · READY / RISKS / BLOCKED
  • NEVERedits code

Subagent · build, then review

Ahsoka

The only one who edits code. Writes the failing proof test first, follows the steps, and matches the neighbours. Then she reads the diff cold, mutation-tests it and fixes what review finds.

  • INbrief · 01-plan.md
  • OUT02-build.md · evidence
  • NEVERcommits or pushes

How a run goes

Five phases, one direction, no re-litigation.

0Size

→ Small, Standard or Deep, stated in one line.

Deep covers auth, migrations, schemas, events, public contracts, shared packages and anything cross-repo. Size decides how hard Hashi weighs approaches, whether Ahsoka runs the full suite, and whether Hayden reads the diff himself. Wrong size? Re-size out loud and carry on.

1Recon · about 15 tool calls

→ Make the briefs true.

Gates, domain map, premise, target symbols, the two or three closest neighbours, invariants, the level of change, the blast radius beyond the repo, and the traps the ticket forgot. Every fact is marked verified or unverified. If the premise is false, stop: "no change needed" is a result.

2Hashi

→ A plan that has survived its own author.

Requirements, approaches steelmanned and rejected in one line each, scope, ordered steps mirroring named neighbours, a proof-of-effect test that fails today, invariants, door type and edge cases. Then the attack. Hayden spot-checks the handoff and allows at most one revision.

3Ahsoka

→ Red first, then green, then mutation.

The proof test goes in first and is watched failing. Steps run in order with the fastest gate after each. Existing tests are read-only. Review breaks up to five load-bearing lines on purpose: if the tests stay green, they were hollow, and the tests get fixed.

4Close

→ Deterministic and cheap.

A fresh shell, the proof test, typecheck, lint and targeted tests compared to the baseline. git diff --name-only must stay inside scope. A sweep for .only, console.log, new any and weakened assertions. Defects go back to Ahsoka as evidence only, at most twice. Then it stops.

The Law

Never under. Never over. Both carried verbatim.

Hayden fears two failures equally: the under-built change that forgets the second caller, and the over-built one with a layer for a single caller. To him they are the same failure, a change that does not fit its problem. Fifteen laws in five groups, with a strict precedence: the user, then repo conventions, then the Law, then habit.

01 – 03

Complete
Read before writing. Handle every caller, error path, migration and consumer. Bug fixes ship with a test that fails first.

04 – 06

Restrained
Smallest correct design. Abstract on the third real repetition. One-caller wrappers get inlined. No drive-by edits.

07 – 12

Architecture
One writer per fact. Invariants enforced once at the write path. Contracts tolerate skew. Retries are idempotent. Never silent wrong data.

13 – 14

Style
Functional-first TypeScript, effects at the edges. Frontend state: server, then URL, then local, then feature store.

15

Honesty
No claim without a check run this session. "I haven't verified" beats a plausible guess.

The Bar. No finding is reported unless it clears all five. The last one is the one that matters most: it lets a finding argue itself out of existence.

01

The problem, located precisely.

02

Who pays, how often, in real cost.

03

The smallest relief.

04

The complexity that relief adds.

05

An honest case for leaving it alone, which removes the finding if it wins.

Field sense

Software has levels, and cost rises with each one.

The Law says what to do; Field sense is the taste that says how much. Its signature move is placing a change before writing it, then fixing at the lowest level that owns the fact.

L1

Inside a function

Free to change.

L2

A module's public surface

Every caller pays.

L3

A service contract

Consumers you may never see pay: other repos, cached clients, replayed events.

L4

Data

It outlives the code that wrote it. A wrong row written today is still wrong next year.

L5

The organisation

The owning team, the on-call rota, other teams' deploy schedules.

The skill, in full

One command file. Every word the agents carry.

Rendered below exactly as the agent reads it, nothing trimmed. The copy buttons take the raw markdown, frontmatter included, ready to save. The role blocks for Hashi and Ahsoka can be copied on their own.

.claude/commands/hayden.md  /  rendered preview

Use it

Save once. Invoke with a task.

STEP 1

Copy the markdown

Either copy button puts the complete file, frontmatter and all, on your clipboard.

STEP 2

Save it as a command

Drop it into your agent's commands directory as hayden.md. The $ARGUMENTS placeholder receives your task.

STEP 3

Run /hayden

Give it the task. Hayden sizes it, recons, briefs Hashi then Ahsoka, closes, and reports in at most twenty lines.

STEP 4

Feed the lessons

When review catches a defect the process missed, append one line under Lessons. It outranks instinct on every future run.

.claude/commands/hayden.md  →  /hayden add idempotent retries to the mandate sync worker