harness-loom

harness-loom

English | 한국어 | 日本語 | 简体中文 | Español

Tune a production-specific harness on top of the generic harness shipped by modern coding assistants.

What It Does

harness-loom is a factory plugin that installs a runtime harness into a target repository and grows it pair by pair. The factory ships four user-facing slash commands (/harness-init, /harness-auto-setup, /harness-pair-dev, /harness-goal-interview) plus a sync.ts script. Once installed, your target gets a planner, an orchestrator, a shared control plane under .harness/, and a place to add project-specific producer-reviewer pairs over time.

This is harness fine-tuning, not model fine-tuning — you encode your repo's review standards, task shapes, and definition of done into versioned infrastructure instead of re-prompting it every session. harness-loom is for teams that already see production-quality potential in their assistant stack and now want it to behave like a system rather than a session.

Quick Start

Install the factory into Claude Code. Codex and Gemini have similar flows — see Install The Factory for those.

/plugin marketplace add KingGyuSuh/harness-loom
/plugin install harness-loom@harness-loom-marketplace

Inside your target repository:

# 1. seed or migrate .harness/
/harness-auto-setup --setup

# 2. derive the assistant runtime tree
node .harness/loom/sync.ts --provider claude
#   (add codex,gemini for multi-platform)

That gets the foundation in place. To add project-specific producer-reviewer pairs and run your first cycle, see Start A Target Project.

How It Works

flowchart LR
    subgraph Factory [harness-loom factory plugin]
        AS["/harness-auto-setup"]
        PD["/harness-pair-dev"]
        GI["/harness-goal-interview"]
        OR["/harness-orchestrate"]
    end
    subgraph Target [target repository]
        L[".harness/loom/<br/>canonical staging"]
        C[".harness/cycle/<br/>runtime state"]
        P[".claude / .codex / .gemini<br/>derived provider trees"]
    end
    AS -->|seed or migrate| L
    PD -->|author pairs| L
    GI -->|writes goal file| Target
    L -->|node sync.ts --provider| P
    OR -->|reads| L
    OR -->|writes| C

The factory plugin lives in your assistant CLI; running its slash commands inside a target repository writes to .harness/loom/ (canonical staging owned by setup and pair authoring) and .harness/cycle/ (runtime state owned by the orchestrator). Provider trees (.claude/, .codex/, .gemini/) are derived artifacts you regenerate with sync.ts whenever canonical staging changes — never edit them directly. The cycle-end Finalizer turn writes target-root output (docs, audits, release notes) directly into the target, not inside .harness/.

Why This Shape

• Skill-first, agent-second. Shared methodology lives in one SKILL.md per pair, so production rules and review rules stay aligned.
• Producer plus reviewers. A pair can fan out to one or many reviewers, each grading on a separate axis.
• Canonical once, derive outward. Author the harness in .harness/loom/; derive .claude/, .codex/, and .gemini/ only when you want them.
• Hook-driven execution. The orchestrator writes the next dispatch into .harness/cycle/state.md, and hooks re-enter the cycle without manual bookkeeping.
• Repo-anchored authoring. Pair generation reads the actual target codebase so it can cite real files and patterns instead of generating abstract boilerplate.

What Gets Installed

target project
└── .harness/
    ├── loom/                    # canonical staging (setup + pair authoring own; sync reads)
    │   ├── skills/{harness-orchestrate, harness-planning, harness-context}/
    │   ├── agents/{harness-planner, harness-finalizer}.md
    │   ├── hook.sh
    │   └── sync.ts
    ├── cycle/                   # runtime state (orchestrator owns)
    │   ├── state.md, events.md
    │   └── epics/, finalizer/tasks/
    ├── _snapshots/              # auto-setup provenance (when migration runs)
    └── _archive/                # past cycles (created on goal-different reset)