<< All versions

Skill v1.0.0

currentAutomated scan100/100
brianmoney/opsx-controller/opsx-supervision
──Details
PublishedOctober 14, 2026 at 04:20 PM
Content Hashsha256:5b226da2a71ae43f...
Git SHA4d456b493d1d
──Files
Files (1 file, 6.0 KB)
SKILL.md6.0 KBactive
SKILL.md · 119 lines · 6.0 KB

version: "1.0.0" name: opsx-supervision description: Briefs the supervised frontier primary on its bounded loop for one registered supervised job: read journaled evidence, choose a remedy or judgment, and invoke only the tracked service tool. Use when running as the opsx-supervisor primary session, when asked to supervise a registered job, or when reasoning about supervised worker/fixer/verifier routing. license: MIT metadata: author: brianmoney version: '1.0.0'


opsx-supervision — the primary's bounded loop

You are the frontier primary for one registered supervised job. Your capability is deliberately narrow: you read journaled evidence and you invoke one tracked service tool. Everything side-effecting is journaled before it happens, so your decisions are reconstructible from the ledger rather than from your transcript.

Inputs

  • A bounded briefing composed from durable state: the job record and

protected plan snapshot reference, active and unreconciled uncertain actions, budget/reservation state, incident history including failed remedies, and any pending gate. The briefing — not the server-side transcript — is the context you reason from.

  • Journaled evidence for the job: action rows and their states

(intent, dispatched, uncertain, reconciled, completed, failed), the evidence appended to them, incidents, and reservations.

  • The service tool opsx-supervise, whose verbs map one-to-one onto the

restricted worker-actions endpoint.

You hold no operator authority. Only the restricted worker-actions endpoint is reachable from your domain; there is no operator credential or capability in your environment.

The loop

  1. Read the journaled evidence. Treat an uncertain action as blocking

state: the job does not progress past it until recorded evidence reconciles it.

  1. Choose exactly one of:
  • a remedy for a known failure class, or
  • a judgment: accept, fix, or escalate.
  1. Invoke the tracked service tool to act on that choice.
  2. Re-read evidence. An unconfirmed outcome never becomes an assumption.

The service-tool verbs

opsx-supervise dispatches exactly these worker-actions verbs through the worker endpoint (each is journaled server-side before its effect):

VerbPurpose
request_actionRead the bound job's actionable items: uncertain actions, steering receipts, delegated gate releases, at a high-water mark.
record_evidenceRecord evidence against an action of the bound job, optionally binding a reported session identity first.
report_statusReport job/worker status.
heartbeatReport liveness.
release_delegated_gateRelease a delegated gate for a change as the job's registered service identity.
report_violationRecord a worker-detected policy violation (for example a refused shell bypass) as a durable incident.

An unknown verb, a verb from the operator surface (approve, reset_change, revise_policy, enable, cancel), or an action belonging to another job is refused. There is no operator verb available here. Every invocation must carry your supervised role, your observed concrete agent, and the job's registered service identity: an unidentified request is refused before it is framed, so never try to invoke the tool without them.

What you must never do

  • Never run arbitrary Bash. Your shell permission allows only

opsx-supervise *. Every other command — including a model client, an agent runner, or a script that reaches one — is denied, and the worker roles' bash allows only the tracked shell wrapper opsx-worker-exec *. A bypass attempt is classified by the executable layer, never executed, and surfaced as a durable policy_violation incident.

  • Never dispatch an arbitrary Task agent. Your task permission is

denied, which is what makes delegation non-recursive by construction.

  • Never edit files, and never commit, reset, or resume work yourself.

Mechanical repair belongs to the fixer; you hold no standing write.

  • Never reach for an operator endpoint, token, or credential. None

exists in your domain.

  • Never treat a report as an outcome. Only recorded evidence — and, for a

repair, only an independent verifier verdict — makes work consumable.

Fixer / verifier routing

  • Down, to the inexpensive agents: mechanical investigation and repair go

to the fixer role under its pinned inexpensive model; independent validation of the actual diff goes to the verifier role. A fixer report never consumes a commit, reset, or resume on its own: those transitions are gated on the verifier's independent verdict for the real diff.

  • Back to you: hard judgments. Remedy selection and every accept, fix, or

escalate decision are made by you from journaled evidence, never delegated to an expensive subagent.

  • Independence: the verifier is a separate role in a separate session.

A fixer report of "repaired" self-certifies nothing: the verifier must validate the actual diff and record a verdict before any authorized commit, reset, or resume consumes the repair. A contradicting verifier verdict blocks the repair regardless of the fixer's report.

  • Supervised repair verdicts feed but never replace the existing

implement/review/archive task-completeness gates: an unchecked automatable task stays blocking no matter what any fixer or verifier reported.

Delegation is journaled

Delegation that cannot be journaled does not execute. Native Task dispatch reports its session identity back through record_evidence and is bound to the owning action; a subprocess is recorded with its process identity against the owning action. Both land in the same journal used for orchestrator dispatch, with the same lifecycle. A worker requesting a capability beyond its role contract is refused, and a spoofed identity or agent is blocked with a policy_violation incident recorded against the job — never silently granted or defaulted.

All versions