Most AI coding assistants work alone: one model, one long context window, one job at a time. Harness takes a different approach. It is an open source meta-skill for Claude Code that does not do your task directly. Instead, it designs a small team of specialized agents for your domain, writes the agent definitions and the skills they follow, and wires up how they pass work to each other. You describe the job in one sentence, and Harness builds the team that does it (GitHub, retrieved 2026-10-24).
Key Takeaways
What it is: Harness (revfactory/harness, Apache-2.0) is a meta-skill, a skill that builds other skills and agent teams, for Claude Code. It has about 9,242 stars and 1,327 forks on GitHub.
The pitch: One prompt such as "build a harness for this project" produces agent definitions in `.claude/agents/`, skills in `.claude/skills/`, and a pointer in `CLAUDE.md`.
How it chooses: It picks from six team patterns and three execution modes based on the shape of the work, not on team size, and it can mix modes per phase.
Quality loop: Built-in verification includes dry runs, trigger evals, and with-skill versus without-skill A/B tests, plus `/harness:evolve` to fold feedback into the next generation of the team.
Fine print: It is Claude Code only, its headline quality numbers come from a small author-run v1 test (15 tasks), and a generated team is only as good as the domain description you give it.
What Harness actually is
The name is doing real work here. In this project, a "harness" is not a single agent. It is the complete setup that lets a team of agents operate in one domain: who the agents are, how each one works, and how they coordinate (GitHub, retrieved 2026-10-24).
That distinction matters because the usual alternative is a library of ready-made skills. A skills library hands you generic procedures. Harness instead interviews your project first, then generates a team shaped for it. Want a deep research team? It designs agents for web search, academic sources, and community sentiment, plus a cross-validation step. Want a code review pipeline? It designs parallel agents for architecture, security, performance, and style, then merges their findings into one report (dev.to).
The current version is v2, a ground-up rebuild for the current Claude Code multi-agent runtime. Version 1 was built on an experimental `TeamCreate` API that no longer exists, so v2 targets what actually ships today, and it includes a built-in migration path if it detects v1 artifacts in your project (GitHub, retrieved 2026-10-24).
How it works: eight phases, one prompt
You trigger Harness with plain language. There is no special syntax, just a sentence like "build a harness for this project" or "design an agent team for deep research" (GitHub, retrieved 2026-10-24). Behind that sentence, it runs a phased workflow:
Phase 0, audit: Check whether a harness already exists, and whether it is new, an extension, or a maintenance job. Version 1 artifacts are detected here.
Phase 1, domain analysis: Identify the task types, the tech stack, the user expertise level, and the control-flow shape of the work.
Phase 2, architecture design: Choose an execution mode and a team pattern.
Phase 3, agent definitions: Generate one file per agent in `.claude/agents/`, each with a role, working principles, and input and output protocols.
Phase 4, skill generation: Generate context-efficient skills in `.claude/skills/`, using progressive disclosure so only the relevant detail loads at each step.
Phase 5, orchestration: Define how agents pass data (structured schemas, files, messages, or tasks) and add a minimal pointer to `CLAUDE.md`.
Phase 6, verification: Run trigger evals, dry runs, and with-skill versus without-skill A/B tests.
Phase 7, maintenance: Evolve the harness from usage feedback with `/harness:evolve`.
Everything it produces is plain text you can read and edit. Nothing is a black box, and that is a deliberate design choice: if a generated agent behaves badly, you open its file, find the instruction, and fix it (dev.to).
Six patterns, three modes
Harness separates two decisions that are easy to confuse: the team pattern (how the agents relate) and the execution mode (how they actually run).
The six architecture patterns are Pipeline, Fan-out/Fan-in, Expert Pool, Producer-Reviewer, Supervisor, and Hierarchical Delegation, each mapped to its best v2 execution mode (GitHub, retrieved 2026-10-24). A code review pipeline, for example, is a natural Fan-out/Fan-in job: several reviewers work in parallel, then one step merges their findings. A research report with a writer and a skeptical critic fits Producer-Reviewer.
Execution mode | Primitive | When it fits |
|---|---|---|
Workflow orchestration | Workflow scripts with pipeline, parallel, schemas, and budgets | Control flow is deterministic: enumerable fan-outs, verification loops, large scale, structured outputs |
Persistent agents | Named agents plus SendMessage plus shared task lists | Long-lived specialists that keep context, with iterative feedback and negotiation |
Sub-agent delegation | One-shot Agent calls | Fire-and-forget parallel work where only results come back |
The factory picks the mode from the shape of the control flow, not from team size, and it mixes modes per phase when that fits better (GitHub, retrieved 2026-10-24). That is a useful rule of thumb for anyone designing agent systems by hand, too: start from how the work branches, loops, and merges, not from how many agents sound impressive.
What it generates
After a run, your project gains a small, readable structure (GitHub, retrieved 2026-10-24):
`.claude/agents/`: one definition per agent, for example `analyst.md`, `builder.md`, and `qa.md`. Each file states the agent's role, principles, and protocols.
`.claude/skills/`: one skill per procedure, for example `analyze/SKILL.md` and `build/SKILL.md`, plus one orchestrator skill that defines who acts, when, and in what order.
`CLAUDE.md`: a minimal pointer with the trigger rule and change history, not a dump of the whole design.
Skills use progressive disclosure: metadata is always in context, the skill body loads when the skill triggers, and reference material loads only when a specific condition is met. That keeps the context window lean, which is the whole point of a skill system in the first place (DeepWiki).
Installation is straightforward. Via the plugin marketplace, run `/plugin marketplace add revfactory/harness` then `/plugin install harness@harness-marketplace`. As global skills, copy `skills/harness` and `skills/evolve` into your Claude skills directory. No environment variables or experimental flags are required in v2, a deliberate break from v1, which needed an experimental agent teams flag (GitHub, retrieved 2026-10-24).
Verification and evolution: the parts most tools skip
Two features separate Harness from a prompt that merely scaffolds files. The first is verification. Generated harnesses are checked with trigger evals (does the right skill fire at the right time?), dry runs, and A/B tests that compare output with the skill versus without it (GitHub, retrieved 2026-10-24).
The second is evolution. After you use a generated harness, `/harness:evolve` captures the delta between your initial harness and its current, edited state, generalizes your feedback, and feeds it back into the agents, skills, and orchestrators. In v1 this was only documented; in v2 it ships as a real skill (GitHub, retrieved 2026-10-24).
That loop is the honest answer to the obvious objection: a generated team will not be perfect on the first try. Harness assumes iteration, and it gives that iteration a mechanism instead of leaving it to manual file edits.
The honest limits
Harness is worth trying, but three caveats belong in any fair write-up.
First, the headline numbers are author-run and small. The README reports a controlled A/B on 15 software-engineering tasks for v1: mean quality rose from 49.5 to 79.3, a 60 percent improvement, with a 15 out of 15 win rate and 32 percent lower output variance. The README itself says to treat these as author-measured numbers and run your own pilot before adopting it (GitHub, retrieved 2026-10-24). Those are v1 numbers, not v2 benchmarks, and no independent benchmark is cited.
Second, it is Claude Code only. If your team runs on another agent platform, the generated `.claude` artifacts do not transfer directly, though the design ideas (patterns, progressive disclosure, verification loops) do.
Third, a meta-skill amplifies its input. A vague domain description produces a vague team, and a team that looks organized can still produce confident, wrong output. The verification patterns (adversarial checks, judge panels, loop-until-dry critics) exist precisely because generated harnesses need the same skepticism as any other generated code (GitHub, retrieved 2026-10-24).
Should you try it?
Try Harness if you already use Claude Code and you keep repeating a multi-step workflow: research reports, code reviews, full-stack feature builds, or migration projects. Start with one workflow, run the verification step, and keep the generated files under version control so `/harness:evolve` has a real history to learn from.
Skip it, or treat it as design inspiration only, if you are not on Claude Code, or if your workflow is a single one-off task. For a one-off job, a single good prompt beats a whole generated team.
Want the 30-second version? Watch the repo signal for this project on repomaniac.com, and read this article in Indonesian for the translated edition. If you like the idea of ready-made agent skills rather than generated teams, our Scientific Agent Skills spotlight covers a 177-skill library for scientific work.
Frequently Asked Questions
What is Harness?
Harness (revfactory/harness) is an open source meta-skill for Claude Code that designs domain-specific agent teams, defines specialized agents, and generates the skills they use. It is licensed Apache-2.0 and has about 9,242 stars on GitHub (GitHub, retrieved 2026-10-24).
How do I install Harness?
Via the Claude Code plugin marketplace with `/plugin marketplace add revfactory/harness` and `/plugin install harness@harness-marketplace`, or manually by copying `skills/harness` and `skills/evolve` into your Claude skills directory. Version 2 needs no environment variables or experimental flags (GitHub, retrieved 2026-10-24).
What is the difference between Harness and a skills library?
A skills library gives you ready-made procedures. Harness generates a team and its procedures for your specific domain, after analyzing your project, and it adds verification and an evolution loop so the team improves with use (GitHub, retrieved 2026-10-24).
Does Harness work outside Claude Code?
No. The generated artifacts live in `.claude/agents/` and `.claude/skills/` and target the Claude Code runtime. The underlying patterns (team architectures, progressive disclosure, verification loops) are transferable ideas, but the tool itself is Claude Code only.
Is the quality improvement proven?
Only in a small author-run test. The README reports a v1 A/B on 15 tasks with mean quality rising from 49.5 to 79.3, and it explicitly advises running your own pilot for adoption decisions. Treat v2 claims as promising but unproven until you test them on your own workflow (GitHub, retrieved 2026-10-24).