Research one agent harness's release (docs, source, runtime) and fill its capability cells in scripts/harness_capabilities.py with cited evidence. Use after a harness version bump, when just harness-probe reports re-research, or when capability cells read unknown.
89%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Low
Low-risk findings worth noting
Turn one harness release into filled-in, cited capability cells. One run
covers one (harness, version) pair. The output is an edit to
scripts/harness_capabilities.py plus regenerated docs — never a prose
report that rots outside the registry.
Whitespace-split $ARGUMENTS, order-independent:
{claude, codex, opencode, pi, omp, antigravity, crush}
selects the harness. Required; if absent, read
docs/harness/versions.json and pick the harness whose version differs
from its previous, then say which one you chose.<domain> or <domain>.<name> narrows the run to those
capabilities. None given means every cell that reads unknown.--help/CLI output. Never infer a cell from a sibling harness, from this
repository's adapters, or from what "should" be true.scripts/agent-harnesses.py. It is control plane and
human-only ([control_plane] in ~/.config/ness/policy.toml).
Registry edits land in scripts/harness_capabilities.py; renderer
changes in scripts/harness_docs.py; probe kinds in
scripts/harness_drift.py. A change that truly needs the control-plane
module is reported as a hand-patch for the user.hooks.safety for crush. Its next_action
still says "Install crush and verify it blocks a denied shell command
through the generated crushrc PreToolUse hook", but the crush binary is
now on PATH. Verify the live block, then either mark the cell aligned
with runtime evidence or record what actually happened.docs/harness/versions.json for the version
delta, and just harness-drift --harness <slug> for the recorded
changes. A field: "version" record with no capability records means
nothing was re-verified after that bump.jq -r '.capabilities[] | select(.cells["<slug>"].parity == "unknown") | .id' \
docs/agent-harnesses.jsonp0 first, then p1, then p2. Read each capability's contract
on its domain page under docs/harness/ before looking anything up: the
contract, not the vendor's feature name, is what the cell answers.--help. Pin
permalinks to a tag or commit, never to a branch — the convention in
.agents/skills/optimize-harness/references/session-usage-evidence.md is
the pattern to copy.CAPABILITIES. Set parity, mode,
surface, note, and evidence=Evidence(kind=..., ref=..., version=..., date=...) where date is the day you checked it. Add a probe whenever
a deterministic local check exists: file_exists, file_contains,
cli_help_contains, or cli_exit_zero. parity in
{partial, blocked} requires a next_action naming the next concrete
step.Divergence with its
reason and coping, and set the cell parity="divergent" with that
id — never a next_action. A divergence is not owed work.HOME pointed at the
checkout so the generator reads and writes this tree rather than your
real home:
HOME="$PWD" just harness-probe --harness <slug>
HOME="$PWD" just harness-generate
HOME="$PWD" just harness-checkharness-check runs validate_registry(), so a cell that violates an
invariant fails there with the offending <capability>[<slug>] named.unknown with no evidence is
honest; aligned with invented evidence is a lie the ledger will carry
forward.surface string to satisfy a rule. Those strings are
recorded research and predate the parity vocabulary.docs/harness/drift.jsonl records you produced by
perturbing state to test the pipeline.phatblat/dotfiles
4d65cab
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.