Skip to content

About

A portable Claude skill: give it a goal, get back a reviewable design document for the harness around whatever LLM executes it — context, tools, guardrails, verification loop, and executor topology. It designs the scaffold; it never becomes the running system.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Latest commit

 

History

2 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

mightyharness

Give it a goal. Get back a reviewable design document for the harness around whatever LLM executes it — the context, tools, guardrails, verification loop, and executor topology that make it run. It designs the scaffold; it never becomes the running system.

mightyharness is a portable Claude skill (SKILL.md).

The idea

An idea is a function — input → outcome. The engineering work is rarely "writing software." It is the harness around whatever executes the 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. It has one job and does it at full depth: output the best possible harness design.

The scope is not limited to software. Analysis, retrieval, and reasoning tasks that deserve the same rigor qualify too.

What it produces

A single design document covering, in order: the goal as a function; autonomy and risk level; the core loop; grounding and self-correction; guardrails (each tagged for how long it should survive); blast radius per autonomous action; the tool registry; executor topology; a single-point-of-failure audit; cost governance; memory and context handling; safety and approvals; observability with claim lineage; and an eval protocol that treats the harness — not the model — as the thing under test.

It is governed by seven laws, the sharpest of which are:

  • Design only — the output is a document, never the running system.
  • Grounding beats self-report — every success claim needs an execution-grounded check, and a verifier that shares the executor's blind spots does not count as independent.
  • Every autonomous action states its blast radius — the worst irreversible thing the agent could do before a human sees it, and how that is bounded.
  • Bounds are named, not implied — every loop declares a hard iteration cap and an oscillation detector; "loop until success" is contraband.

See SKILL.md for the full specification.

Install

mightyharness is a single self-contained SKILL.md. Drop the folder into your Claude skills directory:

Personal (all projects):

git clone https://github.com/mightykevster/mightyharness.git ~/.claude/skills/mightyharness

Single project:

git clone https://github.com/mightykevster/mightyharness.git .claude/skills/mightyharness

Use

Invoke it with /harness, or ask in plain language — "design a harness for this," "scaffold this for an LLM to run." Point it at a goal (a bare goal is fine; a written spec, if you have one, is an input, not a requirement) and it produces the design document. Review it, then build against it.

Design principle: self-contained by intent

The skill body carries no citations, attributions, or references. That is deliberate. A skill is an instruction set for the model executing it, not a literature review — it should state each mechanism as plain design guidance the model can act on without stopping to research what a name means. The scholarship behind every mechanism lives here, in ATTRIBUTION.md, where it belongs.

Credits & license

Built by synthesizing prior work across agent-harness engineering, recursive self-improvement research, and several unrelated engineering disciplines. Full sourcing — including third-party skills whose ideas are reworded here under their licenses — is in ATTRIBUTION.md.

Released under the MIT License.

About

A portable Claude skill: give it a goal, get back a reviewable design document for the harness around whatever LLM executes it — context, tools, guardrails, verification loop, and executor topology. It designs the scaffold; it never becomes the running system.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors