An Archon workflow that hosts Matt Pocock’s diagnosing-bugs Method (v1.1.0, skills/engineering/diagnosing-bugs): reproduce → minimise → hypothesise → instrument, ending in a committed failing test.
Why
There is a real gap in the box set. A bug issue reaches /build today without usable acceptance criteria, because for a bug the criteria are the output of diagnosis, not its input. /triage → /tickets → /build assumes the criteria already exist.
The handoff is unusually clean. ADR-0012 splits a slice into a fresh RED node that commits a failing test and a fresh GREEN node that only ever sees the committed test. A diagnosis run produces precisely that artefact, so /build’s GREEN node consumes it unchanged:
bug arrives → /triage → issue (type: bug, no repro)
↓
/diagnose (AFK) reproduce · minimise · hypothesise · instrument
↓
committed failing test + findings ──▶ /build GREEN ──▶ /pr-review
Diagnosis is also work that is losing its claim on human time — it is mechanical, verifiable, and slow.
Scope
- New
unic-dlc-diagnose workflow + command stub, key-discriminated schema (ADR-0011).
- Hosts the
diagnosing-bugs Method by path from .archon/methods/ — never registered as a skill.
- New ADR covering: the handoff contract to
/build (what the committed test must look like for GREEN to accept it), behaviour when no reproduction can be found, and gates.diagnose.
- Config:
gates.diagnose (HITL default, AFK opt-in), per ADR-0017.
Open questions for the ADR
- When no repro is found, does the box file a
needs-info comment on the issue, or halt?
- Does
/diagnose own the branch, or does it write the failing test onto the branch /build will use?
- Is
/diagnose dispatched from /triage automatically for bug-typed issues, or invoked explicitly?
Blocked by
The migration of unic-archon-dlc onto Matt Pocock skills v1.1.0.
Context
Locked in a grilling session on 2026-07-31. Deferred deliberately: the box set was frozen at nine for the migration so it would not turn into a second redesign. This box needs its own ADR and should not be rushed alongside a Method-bundle migration.
An Archon workflow that hosts Matt Pocock’s
diagnosing-bugsMethod (v1.1.0,skills/engineering/diagnosing-bugs): reproduce → minimise → hypothesise → instrument, ending in a committed failing test.Why
There is a real gap in the box set. A
bugissue reaches/buildtoday without usable acceptance criteria, because for a bug the criteria are the output of diagnosis, not its input./triage→/tickets→/buildassumes the criteria already exist.The handoff is unusually clean. ADR-0012 splits a slice into a fresh RED node that commits a failing test and a fresh GREEN node that only ever sees the committed test. A diagnosis run produces precisely that artefact, so
/build’s GREEN node consumes it unchanged:Diagnosis is also work that is losing its claim on human time — it is mechanical, verifiable, and slow.
Scope
unic-dlc-diagnoseworkflow + command stub, key-discriminated schema (ADR-0011).diagnosing-bugsMethod by path from.archon/methods/— never registered as a skill./build(what the committed test must look like for GREEN to accept it), behaviour when no reproduction can be found, andgates.diagnose.gates.diagnose(HITL default, AFK opt-in), per ADR-0017.Open questions for the ADR
needs-infocomment on the issue, or halt?/diagnoseown the branch, or does it write the failing test onto the branch/buildwill use?/diagnosedispatched from/triageautomatically forbug-typed issues, or invoked explicitly?Blocked by
The migration of
unic-archon-dlconto Matt Pocock skills v1.1.0.Context
Locked in a grilling session on 2026-07-31. Deferred deliberately: the box set was frozen at nine for the migration so it would not turn into a second redesign. This box needs its own ADR and should not be rushed alongside a Method-bundle migration.