# Mightyharness

> mightyharness

- Skill: `mightykevster/mightyharness` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add mightykevster/mightyharness`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mightykevster/mightyharness/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: mightykevster (https://skillmd.com/u/mightykevster)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mightykevster/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.