Should SKILL.md define explicit escalation / failure conditions? #5

Open
opened 2026-06-17 20:10:37 +00:00 by mathias · 0 comments
Owner

Question

Does the SKILL.md format need first-class fields for failure criteria and escalation / hand-back rules — i.e. "when should this capability stop and hand control back"?

Prompt

Allie K. Miller's "How I built my AI agent workforce" (2026-06-17) frames agent roles as job descriptions with four required fields: goals, success criteria, failure criteria, and escalation rules. Our SKILL.md files cover capability/purpose (≈ goals) and implicitly success, but do not define explicit stop/handback conditions. The routing pod decides which model; nothing defines when an agent role should escalate or abort.

Why it might matter

  • Maps onto the assessor-loop return path / conditional-approval shape (residual + re_attest_by): an escalation rule is the same structural object as a conditional approval — "proceed unless X, in which case hand back."
  • Currently these conditions are implicit per role across hyperguild / agentsquad / Crush. Implicit = unauditable.

Scope of this issue

  1. Audit: do current skills have implicit-only escalation/abort conditions, or none?
  2. Decide: should SKILL.md gain optional failure_criteria / escalation fields (Agent Skills standard permitting)?
  3. If yes: define the field semantics and how a harness is expected to honour them.

Refs

  • brain: wiki/homelab/decisions/no-centralized-cross-harness-observer-2026-06-17.md (sibling decision from same source read)
  • Related: hyperguild brain-injection verification (issue #32) for the hyperguild-side check.

Not blocking anything; sharpening question raised during an architecture read.

## Question Does the SKILL.md format need first-class fields for **failure criteria** and **escalation / hand-back rules** — i.e. "when should this capability stop and hand control back"? ## Prompt Allie K. Miller's "How I built my AI agent workforce" (2026-06-17) frames agent roles as job descriptions with four required fields: goals, success criteria, **failure criteria**, and **escalation rules**. Our SKILL.md files cover capability/purpose (≈ goals) and implicitly success, but do **not** define explicit stop/handback conditions. The routing pod decides *which model*; nothing defines *when an agent role should escalate or abort*. ## Why it might matter - Maps onto the assessor-loop return path / conditional-approval shape (`residual` + `re_attest_by`): an escalation rule is the same structural object as a conditional approval — "proceed unless X, in which case hand back." - Currently these conditions are implicit per role across hyperguild / agentsquad / Crush. Implicit = unauditable. ## Scope of this issue 1. Audit: do current skills have implicit-only escalation/abort conditions, or none? 2. Decide: should SKILL.md gain optional `failure_criteria` / `escalation` fields (Agent Skills standard permitting)? 3. If yes: define the field semantics and how a harness is expected to honour them. ## Refs - brain: `wiki/homelab/decisions/no-centralized-cross-harness-observer-2026-06-17.md` (sibling decision from same source read) - Related: hyperguild brain-injection verification (issue #32) for the hyperguild-side check. _Not blocking anything; sharpening question raised during an architecture read._
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mathias/skills#5