Mightyharness

mightyharness

An idea is a function — input → outcome. The engineering work is not "writing software"; it is the harness around whatever executes that function: what context it sees, what tools it may touch, what stops it, how it checks its own work, and what runs the loop. This skill takes a goal and produces a design document for that harness — reviewable, diffable, amendable — that a human then builds against.

The artifact designs; it does not run. It is not the harness. It does not execute the function. Anything that claims otherwise is out of scope.

Designer and executor are different roles. The designer is the LLM invoking this skill, working with the human operator. The executor — what actually runs the loop — is decided per harness and never fixed by this skill: a single model, a multi-agent team, or a capable model driving the loop directly (worth the compute cost when the reliability is). That choice is itself a design decision this skill helps make (see Executor topology). Do not assume a target.

Scope is broader than software. Some goals are not software — analysis, retrieval, or reasoning tasks scaffolded with the same rigor also qualify.

A prior written specification of the goal, if one exists, is an input, not a requirement — reference it when present; proceed on a bare goal otherwise, leaning harder on the assumptions ledger. The finished design is meant to be adversarially reviewed before it is built against.

Laws

1. Design only — never execute, never become the system. The output is a document. If a design idea begs to be built mid-session, note it; don't build it here.
2. Every guardrail carries an Evolution Assessment tag. Each one is either a temporary patch compensating for the current executor's specific weakness (tag it deprecatedWhen: <condition>) or a durable pattern (survives model/executor upgrades). Mandatory on every guardrail regardless of chosen executor — whatever runs the loop tends to change.
3. Grounding beats self-report. Every success claim needs an execution-grounded check — validated by actual execution or evidence, not by the executor asserting it worked. A verifier that shares the executor's blind spots is not independent (see Autoimmune verification).
4. Every autonomous-action point states its blast radius. The worst irreversible thing this agent could do before a human sees it, and how that is bounded. No exceptions for "it's just a read."
5. Bounds are named, not implied. Every loop states max iterations and a divergence/oscillation detector. "Loop until success" is contraband. Every self-correction loop is interruptible by an external signal, not only self-terminating.
6. [NC: question] markers, never silent guesses. Unknowns are tagged inline and enumerable, carrying a default where one exists: [NC: question — default X]. No marker survives into the finished design.
7. Hunches enter as hypotheses. The designer's and the operator's assumptions land in the assumptions ledger as hypotheses, not hardened requirements.

Process

Run these as numbered steps, converging between each.

• Step 0 — Goal & autonomy framing. Restate the function in one sentence (input → outcome). State the autonomy level: how much may the executor do before a human sees output? Draw the human-only boundary — which decisions must remain a human's to make and must never be decided unattended, applied to the harness's autonomy boundaries. Raise scrutiny when any of these are present: the harness runs unattended or scheduled; it writes durable or shared state; it contains an irreversible action; it chains three or more side-effecting tools in one loop.
• Step 1 — Executor topology. Decide, for this goal, what runs the loop — single model, multi-agent team, or a capable model driving the loop directly — weighing reliability against compute cost. This is genuinely open per harness. One available shape: a four-role split — hypothesis → implementation → independent verification → composition — for goals where independent verification matters more than team scale. Before defaulting to any multi-agent team, answer: what new information does each added agent contribute? Absent genuinely new information entering the system, more agents cannot beat one well-designed agent (see Unjustified team topology).
• Step 2 — Core loop & tool registry. Specify the execution loop; the default is modify → run → evaluate → iterate with minimal infrastructure. Register every tool with its side-effect class and its Evolution Assessment tag. Prefer session-scoped, time-limited credentials issued per run over a static allowlist.
• Step 3 — Grounding & self-correction. Specify (a) what execution-grounded check exists versus the executor merely self-reporting; and (b) if the harness lets its executor revise its own instructions over repeated runs, a bounded self-revision mechanism: edit scope limited to the failing component (not a rewrite), a regression check against previously-passing cases before accepting a change, and a logged rejected-edit buffer ("we tried this, it broke X") so the same bad fix is not re-proposed. This is what the deprecatedWhen tag does, not just a label. State the loop bound and oscillation detector (Law 5).
• Step 4 — Guardrails & Evolution Assessment. Enumerate guardrails; tag each temporary-patch vs. durable-pattern (Law 2). Include the graduated halt: a named soft-stop (flag + pause for human review) distinct from a hard-stop (kill the run) — the first response to a detected defect is a review request, not an automatic full stop. [NC] the concrete interrupt delivery mechanism if it is unknown for the chosen executor.
• Step 5 — Anti-pattern scan. Run the checklist below; each hit is either repaired or logged as accepted risk.
• Close — gate → adversarial review → sign-off. Gate: every guardrail tagged; every autonomous action has a blast radius; every loop bounded; at least one soft-stop; no [NC] markers survive; the single-point-of-failure audit is non-empty or explicitly "none"; the human-only boundary applied. Subject the draft to adversarial review, surfacing framing failures first. Then take explicit affirmative sign-off — silence is not a signature — and write a dated changelog entry.

Anti-pattern scan

Repair or log as accepted risk.

• Autoimmune verification — the verifier shares blind spots with the executor it grades even when nominally a separate pass or role: same model family, same prompt author, same training-data gaps. The doc must state what makes the verifier's failure modes independent of the executor's — not merely that a separate call exists.
• Fail-open on tooling/infra error — fail-closed must cover the permission machinery itself failing: classifier error, approval-service timeout, policy-lookup failure, audit-log write failure → default to block, never silent-permit. Distinct from fail-closed on a policy violation.
• Cockpit chatter — letting the executor perform unrelated or exploratory actions mid-critical-task instead of within a scoped, single-purpose action window.
• Unjustified team topology — multi-agent by default without answering what new information each agent adds. Watch cascade amplification, topological sensitivity, consensus inertia.
• Unbounded / self-terminating-only loop — no iteration cap, no oscillation detector, or no external interrupt (Law 5).
• Ungrounded success — correctness rests on the executor's self-report (Law 3).
• Untagged guardrail — any guardrail missing its Evolution Assessment tag (Law 2).

Output template

A living document, revised in place, with a dated changelog at the bottom.

1. §Goal — one sentence, input → outcome.
2. §Autonomy & risk level — how much runs before a human sees output; the human-only boundary.
3. §Core loop — the execution loop (modify → run → evaluate → iterate by default).
4. §Grounding & self-correction — execution-grounded check; bounded self-revision mechanism if self-revising; loop bound + oscillation detector.
5. §Guardrails — each with its Evolution Assessment tag; graduated halt (soft-stop vs. hard-stop).
6. §Blast radius — per autonomous-action point: worst irreversible outcome
   • how bounded.
7. §Tool registry — tools, side-effect class, Evolution tag, session-scoped credential note.
8. §Evolution assessment — the roll-up of temporary-patch vs. durable-pattern tags.
9. §Scope & assumptions ledger — hypothesis vs. established fact; what's cut.
10. §Executor topology — chosen executor + the reasoning (single / team / model-driven); the team-justification answer.
11. §Single-point-of-failure audit — every point where a single unverified LLM judgment is load-bearing; each gets a second independent path or an explicit accepted-risk sign-off.
12. §Context compaction / recovery cadence — for long loops: how the trajectory is periodically compacted and the original task intent reinjected into a clean window.
13. §Cost governance — three sub-limits, not one global cap: per-action, per-agent/session, and fleet/spawn throttling.
14. §Instruction architecture — instruction / auto / session-extraction memory layering; progressive disclosure.
15. §Context / memory — externalized memory as a virtualized scratch/filesystem the executor reads and writes, not in-context accretion.
16. §Skills / connectors — lazy-loaded capabilities.
17. §Safety & approvals — fail-closed policy including the checker itself; each entry Evolution-tagged; session-scoped credentials.
18. §Observability — logging/tracing; claim lineage (source, timestamp, execution/evidence anchor) mandatory for any goal producing a deliverable document or analysis.
19. §Evals + harness eval protocol — eval cases, plus how to test the scaffold itself with the model held as a controlled variable, so the harness can be evaluated independent of which model fills the executor slot.
20. §Sign-off & changelog — explicit affirmative sign-off; dated changelog.

Out of scope

• Executing the function, or becoming the running system.
• Wrapping and adopting an existing third-party harness framework as-is — this produces a design, not an adoption.
• Recursive self-governance — a harness that edits its own governing rules — is out of scope to build in. If a design surfaces the temptation, flag it as a risk to discuss inside the design, not a feature to ship.