Harness preflight
Five executable Claude Code skills for building autonomous agent harnesses that don't silently fail — failure-mode auditing, constraint-first CLAUDE.md, sub-agent briefing, context handoff, pre-flight checks.
npx -y skills add aimasteracc/harness-kit --skill harness-preflightAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Run an interactive pre-flight checklist before launching a long autonomous agent run, so the harness is sound before you hand it hours of work. Use when the user says "pre-flight", "ready to run autonomously?", "harness check", or right before kicking off an unattended/overnight task.
SKILL.md
3.1 KB, 751 tokens by cl100k_base, as published. Nobody here has run it
harness-preflight — Don't launch a long run on a harness you haven't checked
Purpose
A long autonomous run amplifies whatever you start it with. A missing "done" condition, an ungated plan, or no checkpoint mechanism turns into hours of confidently-wrong work. This skill walks the seven pre-conditions a sound harness needs and refuses to green-light until the gaps are named. It's the seatbelt check before the autonomous drive.
How to run
Walk each item. For each: OK (with the evidence) or GAP (with what's missing and the
quickest fix). End with a single go/no-go verdict. Don't rubber-stamp — a GAP on items 1, 2,
or 4 is a no-go.
The checklist
- Observable definition of done. Is "done" a command that passes or a state you can see — not a vibe? → If no: define it now (delegate to thinking about the user-visible success state).
- Decomposition exists. Is the work broken into discrete, independently verifiable units — not one giant "implement it" step? → If no: decompose first (guards against one-shot impulse).
- Generation ≠ certification. Is there an independent grader — tests, a type-checker, a separate review pass — so the agent isn't certifying its own output? → If no: wire one in.
- Upstream gate. Is the high-leverage upstream artifact (plan/spec/schema) validated before dependent work fans out? → If no: add a checkpoint right after it (guards against spec cascade).
- Checkpoint / handoff mechanism. Can state survive a context reset — is there a place the
agent writes progress, so nearing the limit triggers a save, not a panic? → If no: set up a
.handoff/convention (see thecontext-handoffskill). - Constraints are loaded. Does a CLAUDE.md (or equivalent) state the NEVERs — the actions
that cause real damage? → If no: generate one (see
claude-md-architect). - Blast radius is bounded. If the run goes wrong, what's the worst it can touch? Is it on a branch / sandbox / with no deploy or destructive perms? → If no: bound it before launching.
Verdict format
## Harness Pre-Flight — <task>
1. Done condition ........ OK | GAP: <fix>
2. Decomposition ......... OK | GAP: <fix>
3. Independent grader .... OK | GAP: <fix>
4. Upstream gate ......... OK | GAP: <fix>
5. Checkpoint/handoff .... OK | GAP: <fix>
6. Constraints loaded .... OK | GAP: <fix>
7. Blast radius bounded .. OK | GAP: <fix>
VERDICT: GO | NO-GO — <one line. NO-GO if any of 1, 2, 4, 7 is a GAP.>
Notes
- This skill composes the rest of the kit: gaps route to
claude-md-architect(item 6),context-handoff(item 5), and the fixes infailure-mode-audit(items 1–4). - A 60-second pre-flight routinely saves hours of an autonomous run spent building the wrong thing soundly.