Case: revfactory/harness
Read revfactory/harness as a meta-harness for generating domain-specific team architectures, agents, and skills.
Key takeaways
- revfactory/harness treats the harness as a generatable, refinable object whose central unit is a team architecture, not a single agent.
- Its L3 Meta-Factory flow runs domain analysis to architecture pattern to agent/skill generation to validation to refinement.
- Domain analysis comes first, extracting vocabulary, risk boundaries, repeated workflows, validation signals, and approval points.
- Choose Agent Teams for coordinated specialized roles and Subagents for a main agent's bounded delegation.
- Generated harnesses still need validation and local ownership, and author-measured A/B results should be treated as directional until independently replicated.
revfactory/harness is useful because it treats a harness as something that can be generated and refined. The key object is not just an agent. It is a team architecture.
This page is based on the README state read on 2026-05-23.
Current Positioning
The README positions the project around L3 Meta-Factory / Team-Architecture Factory ideas: analyzing a domain, selecting architecture patterns, generating agents and skills, and validating the result.
Workflow
| Step | Meaning |
|---|---|
| Domain Analysis | Extract domain constraints, terminology, risks, and repeated tasks |
| Architecture Pattern | Choose an agent-team shape |
| Agent / Skill Generation | Produce reusable agent and skill files |
| Validation | Test the generated harness |
| Refinement | Tune the team architecture |
Agent Teams vs Subagents
| Mode | Use when |
|---|---|
| Agent Teams | The work needs coordinated specialized roles |
| Subagents | A main agent needs bounded delegation for specific subtasks |
The important part is the explicit execution model. Generated harnesses still need validation and local ownership.
Why Domain Analysis Comes First
Many teams start with "which agent should we use?" revfactory/harness starts earlier: what domain is this harness for?
Domain analysis identifies:
- vocabulary;
- risk boundaries;
- repeated workflows;
- validation signals;
- approval points.
That makes harness design closer to requirements engineering than prompt writing.
What to Borrow
| Borrow | Why |
|---|---|
| Domain-first analysis | Prevents generic harnesses from missing local risk |
| Pattern selection | Makes team architecture explicit |
| Skill/agent generation | Turns design into reusable files |
| Validation caveat | Keeps generated artifacts accountable |
| Marketplace/plugin distribution | Clarifies install and update paths |
Caveats
- Generated harnesses can be wrong if domain analysis is wrong.
- Agent-team structures can be overkill for small tasks.
- Author-measured A/B results should be treated as directional until independently replicated.
References
- revfactory/harness README, read baseline 2026-05-23 https://github.com/revfactory/harness