Guide · Agent skill
How to use the Agent Harness Fault Injection agent skill
Updated · written with AI from the project's own documentation and checked against our catalogue data
The Agent Harness Fault Injection skill tells an AI agent how to break parts of a workflow on purpose, in a controlled and repeatable way, and then check whether the workflow recovers. It is written for engineers and QA or reliability teams who build multi-step or multi-agent workflows and need evidence that retry, resume and checkpoint logic works before release. After this guide you will know what the skill does, how to install it, how to trigger it with a plain request, and how to read the verdict it produces.
Agent Harness Fault Injectionsickn33/agentic-awesome-skills · MIT Download the skill Quick start
- 1Download and unzip the skill. Download the ZIP from this page and unzip it into ~/.claude/skills/ or the project's .claude/skills/ folder, or upload it under Settings → Capabilities → Skills in the Claude apps.
- 2Describe the workflow to test. Explain the agent workflow, its states and the recovery path you added, and point the agent at it.
- 3Freeze the test inputs. Record the workflow revision, seed, input fixture, timeout, retry budget and deadline so the run can be repeated.
- 4Request a specific failure. Ask for a named fault such as a tool timeout or worker restart, and specify that you want a repeatable schedule.
- 5Run the schedule twice. Execute the same deterministic schedule two times and compare the normalized timeline before trying other schedules.
- 6Review the matrix and timeline. Check the fault matrix, event timeline and budget tracking for each event.
- 7Act on the verdict. Treat recovered as a pass, investigate unrecoverable, treat contained_failure separately from success, and fix missing fixtures for any inconclusive result.
What does the skill make the agent do?
The skill makes the agent design and run a small set of deterministic faults against a non-production copy of an agent workflow. Typical faults include a tool call timing out, a worker restarting after a checkpoint, a sandbox denying a tool before it starts, or ephemeral memory being cleared. The point is to see whether the workflow keeps its state, stays within its retry and deadline budgets, and avoids repeating side effects.
The agent then reports a fault matrix, an event timeline and one verdict: recovered, contained_failure, unrecoverable or inconclusive. The skill is meant for testing only and says explicitly not to target production systems, real user data or live credentials.
- Fault matrix: which faults were injected, where, and what was expected.
- Event timeline: ordered events with run id, sequence number, state changes and remaining budgets.
- Verdict: one of recovered, contained_failure, unrecoverable or inconclusive, with the reason.
How do you install the skill?
The skill is distributed as a ZIP from the item page on this site. Download the ZIP and unzip it into one of two places. For a personal setup, use ~/.claude/skills/. For a single project, use the .claude/skills/ folder inside that project.
If you use the Claude apps instead of the file system, you can upload the skill under Settings → Capabilities → Skills.
- Personal: unzip into ~/.claude/skills/
- Project only: unzip into .claude/skills/ in the project root
- Claude apps: Settings → Capabilities → Skills, then upload
What does the skill need before you start?
The listing does not require any separate tools or accounts. The skill itself ships as a single file, SKILL.md, and it does not run scripts or use the network. The workflow you test does need to exist, though, and the skill assumes you have a harness, fixtures and a state machine to work with.
Before running a test, the skill asks you to freeze the workflow revision, model and prompt configuration, tool schemas, seed, input fixture, timeout, retry budget, deadline and expected terminal states. A missing scope, fixture or recovery contract makes the verdict inconclusive.
- An agent workflow you can run locally with stubbed tools
- Synthetic input fixtures instead of real user data
- A written recovery contract describing what must survive a failure
- A disposable sandbox with network disabled unless a local test server is needed
How do you trigger the skill with a natural request?
You do not need special syntax. Describe the recovery behaviour you want to test and point the agent at the workflow. The skill's description says it applies when a workflow needs deterministic recovery evidence for sandbox, MCP/tool, worker, checkpoint, memory or orchestration failures, so use wording close to that.
Name the failure you care about and say it should be repeatable. Mention that you want a verdict, not a random chaos run.
- "Use fault injection to check whether my checkpoint resume works after a worker restart."
- "Test what happens when the search tool times out on the second call, and give me a fault matrix and verdict."
- "I added a retry path to my multi-agent workflow. Produce deterministic recovery evidence before I release it."
- "Clear the ephemeral memory mid-run and check the agent does not invent missing user approval."
What does a deterministic schedule look like?
The skill uses event numbers rather than wall-clock timing, so a schedule can be replayed. Each fault names an event, an ordinal, a kind and, where relevant, the tool or branch it targets. The harness should emit the full schedule, not only a seed, and the same schedule should be run twice with the normalized timeline compared before any other schedule is tried.
- Keep the fault identity separate from the observed error, so a timeout is never reported as a generic failure.
- Run the same schedule twice and compare results before randomizing.
- Start with the smallest set of faults that covers the new recovery logic.
{"seed": "harness-fixture-07", "faults": [{"event": "tool.call", "ordinal": 2, "kind": "timeout", "tool": "search"}, {"event": "worker.start", "ordinal": 2, "kind": "restart"}]}How do you read the verdict?
The verdict tells you whether the invariants held. recovered means the declared invariant held and the workflow completed within budget. contained_failure means the fault was isolated and the workflow stopped safely as designed; the skill says this is not autonomous success and should be reported separately from completed work. unrecoverable means an invariant was violated, a side effect repeated, a boundary was crossed or a budget was exceeded. inconclusive means the evidence was not sufficient to judge.
- recovered: invariant held, completed within budget
- contained_failure: isolated and stopped safely, not a success
- unrecoverable: invariant broken, side effect repeated, or budget exceeded
- inconclusive: fixture, checkpoint, contract or evidence was missing
What people use it for
- Checking that a multi-step agent resumes from its latest checkpoint after a worker restart without replaying a committed effect.
- Confirming that a tool call timeout is retried only when the tool contract declares the retry safe.
- Verifying that a parallel branch failure is kept in the final ledger and handled by the declared join policy.
- Testing whether an agent with cleared memory rebuilds from durable evidence or stops and asks for clarification.
- Producing reproducible failure evidence for a reliability review before a release.
Frequently asked questions
How do I install the agent harness fault injection skill?
Download the ZIP from the item page and unzip it into ~/.claude/skills/ for personal use, or into .claude/skills/ inside a project. You can also upload it in the Claude apps under Settings → Capabilities → Skills.
Does this skill require any tools or accounts?
The listing does not list any required tools, and the skill does not run scripts or use the network. You do need an agent workflow to test, along with fixtures and a harness, because the output assumes those exist.
Is the skill free to use and what is the licence?
The skill is listed under the MIT licence. The source does not mention any pricing, so this page makes no claim beyond that.
Can I use it to test my production system?
No. The skill says not to target production systems, real user data or live credentials, because injected failures could cause real damage. Use a local simulator or an authorised staging harness instead.
What is the difference between contained_failure and recovered?
recovered means the workflow completed within budget with its invariants intact. contained_failure means the fault was isolated and the workflow stopped safely as designed, which the skill reports separately from completed work.
Why does my test come back inconclusive?
The skill returns inconclusive when the fixture, checkpoint, recovery contract or evidence is insufficient. Check that you froze the seed, input fixture, budgets and expected terminal states, and that the checkpoint is valid.
New agent skills, repos and AI tools — every week
The best new skills and open-source projects, the fastest-growing repos, and one free prompt. Five minutes to read. Unsubscribe anytime.
Our verdict
This skill suits engineers and reliability teams who are building multi-step or multi-agent workflows and need repeatable proof that retry, resume and checkpoint logic works before release. It is a poor fit for anyone wanting to test a live system, or for non-technical users who have no agent workflow to test. Choose a different tool if you need chaos testing against production infrastructure.
Download the skill