Harness Long-Running Agent Framework
Keeps agent tasks running across sessions: automatic progress checkpointing, interruption recovery, failure rollback, and dependency-ordered task scheduling.
No red-line risks: no network exfiltration or credential access; all hooks are gated by the .harness-active marker and exit safely. Deductions: rollback via git reset --hard + git clean -fd destroys uncommitted work without explicit user confirmation; the .gitignore question in /harness init is only a post-hoc prompt; publisher identity unverified and provenance ('Synthesized from Anthropic and OpenAI engineering practices') is unverifiable. Overall scope is restrained (local files + git), yielding a mid score.
Scripts are self-consistent: lock protocol handles stale locks and PID liveness, atomic writes include .bak backups, stop hook has MAX_CONSECUTIVE_BLOCKS anti-loop valve. Deductions: no committed test suite covering key paths; the example harness-init.sh swallows errors with '|| true'; the recovery decision matrix leaves checkpoint/file-state mismatch judgment to the agent, introducing nondeterminism. Static ceiling is 10.
Trigger description is fairly clear (/harness command, multi-session persistence scenarios), concurrency/exclusive boundaries and tool dependencies (Bash/git) are declared. Deductions: non-fit ranges not stated (non-git projects fail late rather than early); deeply bound to Claude Code hooks; hooks. references self-reflect-stop.py which is absent from the evidence, a suspected missing dependency; some Chinese hook output exists but no Chinese docs.
SKILL.md is well structured with progressive disclosure (principles → protocol → error table → recovery matrix) and standardized logging. Deductions: no per-skill version or changelog; 'Synthesized from Anthropic and OpenAI engineering practices' is an unattributed secondary source; ownership/update path only implied at repo level; hooks. references self-reflect-stop.py not present in evidence.
The protocol targets real pain points (context loss, premature completion), and dual-file persistence + rollback is directly usable with clear marginal value. Deductions: no executed results verifiable in static review; the hook-forced continuation depends on faithful agent adherence to a long protocol, unproven in practice; no representative output samples to check.
Auditable primary material is solid: SKILL.md pseudocode and Python hook implementations cross-corroborate lock/atomic-write/lease logic. Deductions: no committed tests, no CI coverage evidence, no third-party execution; the 'Anthropic/OpenAI practices' provenance is untraceable; static ceiling of 5, minus for thin coverage.
- Rollback runs git reset --hard and git clean -fd, destroying uncommitted changes and untracked files; ensure your worktree is committed or backed up before use.
- Review the hook configuration before enabling; hooks block agent stops and can consume significant tokens/time — set max_tasks_per_session and max_sessions limits.
- hooks. references self-reflect-stop.py, which is absent from the reviewed materials; verify hook file completeness before installing.
- Publisher is not verified by the FollowSkills registry; the 'Anthropic/OpenAI engineering practices' provenance claim is author-supplied and unverifiable.
- Fully dependent on the Claude Code hooks ecosystem plus Bash/git; not applicable to non-git projects.
What does this skill do, and when should you use it?
Harness is a skill in the stellarlinkco/myclaude repository providing an executable protocol that lets any agent task run continuously across multiple sessions and context-window resets. It persists progress via a dual-file system — an append-only log (harness-progress.txt) and structured state (harness-tasks.) — and on session restart recovers interrupted tasks from git history plus checkpoints. Task execution follows a strict claim–execute–validate–rollback cycle, rolling back with git reset to the task's starting commit on failure. It includes a mkdir-based atomic lock supporting exclusive or opt-in concurrent modes, and automatically picks the next task by priority and dependency order. Synthesized from Anthropic and OpenAI engineering practices for long-running agents.
Provides four commands: /harness init, /harness run, /harness status, /harness add. Init creates the progress log, task JSON, optional harness-init.sh environment script, and a .harness-active marker (removed when all tasks finish). The run loop: reads the last 200 log lines and full task JSON, checks git state, acquires a file lock, detects circular dependencies and blocked propagation, claims tasks by priority, executes work with checkpoints, runs validation.command with a timeout, rolls back via git reset --hard to started_at_commit on failure (running on_failure.cleanup), and appends STATS lines. Logs use a single-line grep-friendly format (INIT/Starting/Completed/ERROR/CHECKPOINT/ROLLBACK/RECOVERY/STATS types); every JSON write is preceded by a .bak copy and applied atomically via .tmp + mv, with restore-from-backup on corruption.
- Developers running tens of subtasks in one effort who want new sessions to resume losslessly from checkpoints after a context-window reset
- Project maintainers with multi-task dependencies who want P0/P1 priority ordering and automatic blocked-propagation instead of manual scheduling
- Engineers running unattended, CI-like sessions who need failed tasks auto-rolled-back with capped retries (default 3) to avoid repeatedly damaging the codebase
- Teams running multiple agents in parallel, using concurrent mode with atomic task claims (claimed_by + lease timestamps) across isolated worktrees
- Users whose tasks frequently get interrupted mid-way, relying on the recovery decision matrix (uncommitted changes × task commits × checkpoints) to decide resume, complete, or rollback-fail
What are this skill's strengths and limitations?
- Thorough persistence design: dual-file system, .bak backups, atomic writes, and a defined JSON-corruption recovery path
- Rigorous failure handling: commit existence verified before rollback, capped retry attempts, and seven error categories each with an explicit default recovery strategy
- Concurrent mode implemented via atomic mkdir locks, task-claim leases, and stale-lock reclamation, portable across macOS/Linux
- Uniform, grep-able log format makes session history and errors easy for humans to audit
- Every task needs a non-empty validation.command or the run STOPS — costly for tasks without an obvious objective check
- Concurrent mode strictly requires isolated git worktrees or separate clones; two workers in one working tree will destroy each other's rollbacks
- Rollback uses git reset --hard and git clean -fd, which will wipe uncommitted changes and untracked files
- The README does not separately document harness's install entry, and no standalone test suite for the protocol is shown
How do you install this skill?
The skill lives in the stellarlinkco/myclaude collection at skills/harness/SKILL.md. You can list installable items with npx github:stellarlinkco/myclaude --list and install interactively via npx github:stellarlinkco/myclaude into ~/.claude. Note: the README's listed skills do not individually mention harness, so its exact install entry is undocumented; once installed, skill files should reside under the skills directory (e.g., ~/.claude/skills/) in a harness folder.
How do you use this skill?
Run /harness init <project-path> from your project root (it asks whether to gitignore the harness files); add tasks with /harness add "task description" (optionally supplying priority, depends_on, validation.command interactively — a task requires a validation command before it can be completed); then start or resume the loop with /harness run and check progress with /harness status, which shows task summaries, per-task status, and the last 5 log lines. If a session starts and finds an in_progress task, the recovery protocol runs automatically.