revfactory/harness / Chapter 1

Programming /

introduction

# The Factory That Builds Teams > A meta-skill is a skill whose output is more skills. Harness, a Claude Code plugin, is a meta-skill whose output is an entire agent team — agents, skills, orchestrator, change log — generated from one sentence. A Korean fintech developer types `하네스 구성해줘 — 핀테크 리스크 평가 팀` into Claude Code. Forty-five seconds later, the working directory contains a `.claude/agents/` folder with `risk-analyst.md`, `compliance-reviewer.md`, and `portfolio-monitor.md`, a `.claude/skills/` folder with their supporting skills, and one orchestrator skill that knows how to route a credit memo through them. The developer did not write any of those files. The plugin did. The developer typed one sentence in Korean, and got a team in return. That sentence is not a magic spell. It is a trigger that activates a meta-skill — a skill whose output is more skills — running a seven-phase pipeline codified in `skills/harness/SKILL.md` at version 1.2.0. The pipeline is the point. The plugin's name is `harness`, its repository is `revfactory/harness`, and its position in the broader Claude Code ecosystem is something the maintainers have started to call an **L3 Meta-Factory** — a layer that does not solve problems itself, but generates other layers that do. This series is about what that means in practice. Not what `harness` *claims* to do — that is one short README read away — but what its design choices reveal about how multi-agent systems are actually built, versioned, and evolved when you take the category seriously. ## What "build a harness" actually means The `revfactory/harness` README opens with a striking sentence: *"Harness is a team-architecture factory for Claude Code."* Most readers will skim past that. The phrase looks like product marketing. It is not. It is a category claim, and the rest of the repository is the evidence. A factory is not a builder. A factory is a process that produces builders — repeatedly, at known cost, against a known specification. Archon, in the same L3 layer of the Claude Code ecosystem, is a *runtime-configuration factory*: you describe a project, and Archon produces a deterministic runtime configuration you can run today. Harness is a *team-architecture factory*: you describe a domain in one sentence, and Harness produces the agents, their skills, their communication protocols, and the orchestrator that binds them. Archon and Harness are neighbors, not competitors. They sit at different sub-layers of L3, and the README is explicit about the boundary: *"Pick Archon for runtime determinism, Harness for team architecture, or combine them."* > The series-level claim I will defend across these chapters: Harness's distinctive contribution is not any single agent pattern or workflow — it is the discipline of treating team design itself as a manufactured artifact. The repo codifies that discipline across seven phases, six patterns, and three execution modes, and it does so with a strict refusal to generate anything else (no commands, no MCP servers, no shared agents — only `.claude/agents/` and `.claude/skills/` files). I came into this expecting another agent framework. After reading the source, I had to revise that framing. Frameworks give you primitives; Harness gives you a production line. The distinction matters, because primitives are something you assemble yourself, and a production line is something you specify once and then run. ## The three claims the source has to back up A team-architecture fac

Chapter 1 of 5 6m Article Learning path

The Factory That Builds Teams

A meta-skill is a skill whose output is more skills. Harness, a Claude Code plugin, is a meta-skill whose output is an entire agent team — agents, skills, orchestrator, change log — generated from one sentence.

A Korean fintech developer types 하네스 구성해줘 — 핀테크 리스크 평가 팀 into Claude Code. Forty-five seconds later, the working directory contains a .claude/agents/ folder with risk-analyst.md, compliance-reviewer.md, and portfolio-monitor.md, a .claude/skills/ folder with their supporting skills, and one orchestrator skill that knows how to route a credit memo through them. The developer did not write any of those files. The plugin did. The developer typed one sentence in Korean, and got a team in return.

That sentence is not a magic spell. It is a trigger that activates a meta-skill — a skill whose output is more skills — running a seven-phase pipeline codified in skills/harness/SKILL.md at version 1.2.0. The pipeline is the point. The plugin's name is harness, its repository is revfactory/harness, and its position in the broader Claude Code ecosystem is something the maintainers have started to call an L3 Meta-Factory — a layer that does not solve problems itself, but generates other layers that do.

This series is about what that means in practice. Not what harness *claims* to do — that is one short README read away — but what its design choices reveal about how multi-agent systems are actually built, versioned, and evolved when you take the category seriously.

What "build a harness" actually means

The revfactory/harness README opens with a striking sentence: *"Harness is a team-architecture factory for Claude Code."* Most readers will skim past that. The phrase looks like product marketing. It is not. It is a category claim, and the rest of the repository is the evidence.

A factory is not a builder. A factory is a process that produces builders — repeatedly, at known cost, against a known specification. Archon, in the same L3 layer of the Claude Code ecosystem, is a *runtime-configuration factory*: you describe a project, and Archon produces a deterministic runtime configuration you can run today. Harness is a *team-architecture factory*: you describe a domain in one sentence, and Harness produces the agents, their skills, their communication protocols, and the orchestrator that binds them. Archon and Harness are neighbors, not competitors. They sit at different sub-layers of L3, and the README is explicit about the boundary: *"Pick Archon for runtime determinism, Harness for team architecture, or combine them."*

The series-level claim I will defend across these chapters: Harness's distinctive contribution is not any single agent pattern or workflow — it is the discipline of treating team design itself as a manufactured artifact. The repo codifies that discipline across seven phases, six patterns, and three execution modes, and it does so with a strict refusal to generate anything else (no commands, no MCP servers, no shared agents — only .claude/agents/ and .claude/skills/ files).

I came into this expecting another agent framework. After reading the source, I had to revise that framing. Frameworks give you primitives; Harness gives you a production line. The distinction matters, because primitives are something you assemble yourself, and a production line is something you specify once and then run.

The three claims the source has to back up

A team-architecture factory has to clear three bars before the metaphor is earned. Looking at the repository, the source material commits to each of them in turn:

1. The factory must codify its process. skills/harness/SKILL.md is 458 lines of phase-by-phase specification. The work is not implicit in prompts; it is explicit in numbered phases, decision tables, and template files. The factory ships its own operating manual. 2. The factory must produce artifacts that survive across sessions. Every agent Harness generates becomes a file under .claude/agents/. Every skill becomes a file under .claude/skills/. Files persist. Files can be diffed, reviewed, rolled back, and shared. The team is no longer a one-shot prompt output; it is a directory. 3. The factory must evolve. Phase 7 of the workflow is titled "Evolution" and it is not optional. After every execution, the plugin expects to collect feedback, route it to the correct artifact, and record the change in a CLAUDE.md change-log table. The team is treated as a living system, not a build artifact.

If any of those three legs were missing, the factory metaphor would collapse. The repository enforces all three.

Where Harness sits in the layer cake

The README carves out a four-row layer model for Claude Code tooling. The diagram below shows where Harness lives, and what is adjacent.

graph TD
    L0["L0 — Domain / Project<br/>(your codebase, your domain)"]
    L1["L1 — Harness<br/>(agent definitions + skills for one project)"]
    L2["L2 — Cross-Harness Workflow<br/>(e.g., affaan-m/ECC)"]
    L3a["L3 — Meta-Factory<br/>── Team-Architecture Factory<br/>(this repo: revfactory/harness)"]
    L3b["L3 — Meta-Factory<br/>── Runtime-Configuration Factory<br/>(e.g., coleam00/Archon)"]
    L3c["L3 — Meta-Factory<br/>── Codex Runtime Port<br/>(e.g., SaehwanPark/meta-harness)"]

    L0 --> L1
    L1 --> L2
    L2 --> L3a
    L2 --> L3b
    L1 -.uses.-> L3a
    L1 -.uses.-> L3b
    L3a -.sibling.-> L3c

    classDef ours fill:#fde68a,stroke:#b45309,color:#000;
    classDef neighbor fill:#e0f2fe,stroke:#0369a1,color:#000;
    class L3a ours;
    class L3b,L3c neighbor;

Harness occupies a thin horizontal band — it does not own your agents (L1) and it does not orchestrate multiple harnesses (L2). It is the thing that *creates* L1 from one sentence, and it does so alongside two siblings: Archon (for runtime determinism) and meta-harness (for the Codex runtime). The trio shares L3 but splits the work. Harness's claim is the team-architecture sub-layer, and the surrounding FAQ in the README is unusually explicit about not overreaching.

Imagine you have a domain sentence and thirty minutes. You can run claude "build a harness for X", get a directory of agents and skills, and execute a sample task against the new team. The 5-minute quickstart in docs/quickstart.md is built around that promise, and it includes failure-FAQ entries for the most common ways the promise breaks (missing flag, missing plugin, locale misrouting). The plugin is engineered to be reachable in five minutes and reliable in fifteen.

What this series will argue

Across the next four chapters I will defend four narrower claims, each one a layer of the factory metaphor:

  • Chapter 1 — The seven-phase pipeline is the factory's core. Most of its phases are about writing files, not running agents. That is the point.
  • Chapter 2 — The six architecture patterns are not interchangeable shapes. Each pattern encodes a specific failure mode it is good at preventing, and the wrong pattern choice is the single most expensive error a Harness user can make.
  • Chapter 3 — Agent teams are the default. Sub-agents are the override. Hybrid is not a power-user feature; it is the answer to one specific data-flow problem. The SKILL.md's decision tree forces you to override the default in exactly two cases.
  • Chapter 4 — The seven boundary-mismatch bugs in the QA agent guide reveal the one failure class the factory has not yet built a smoke test for: bugs that live between skills rather than within them. The next chapter of Harness's evolution is going to be cross-component QA, and the source code is already pointing at it.

The series is built on one red thread: *the hardest problem in multi-agent AI is not making agents smarter, it is making the team a team*. Harness's argument is that this is a meta-problem — the team itself must be designed, codified, version-controlled, and evolved — and that a factory is the right shape for that work.

Whether Harness succeeds at the argument is what the remaining chapters will decide. The evidence is in the source. The judgment is in the chapters that follow.

---

References:

---