id	title	sidebar_label	last_generated
overview	Skills Overview	Overview	2026-04-14

Skills Overview

The harness-skills-plugin implements a multi-agent build pipeline where each phase is a separate Claude skill. Skills communicate exclusively through files in .harness/ — no conversation context is shared between them.

---

Pipeline Flow

GREENFIELD                              EXISTING PROJECT
─────────────────────────────────────   ──────────────────────────────────────────
Phase 0: Elicit brief                   Phase 0: Elicit brief
  → .harness/PROJECT_BRIEF.md             → .harness/PROJECT_BRIEF.md
         │                                        │
Phase 1: Init .harness/                  Phase 1A: harness-auditor
  → .harness/config.yaml                   → .harness/CODEBASE_AUDIT.md
         │                                [MANUAL GATE — user reviews audit]
         │                                        │
Phase 2: harness-planner                 Phase 2: harness-planner (delta mode)
  → .harness/PRODUCT_SPEC.md               → .harness/PRODUCT_SPEC.md (delta spec)
  → .harness/CALIBRATION.md (opt)        [MANUAL GATE — user approves spec]
  [MANUAL GATE — user approves spec]              │
         │                                        │
Phase 3: harness-builder (per sprint)    Phase 3: harness-builder (per sprint)
  → write SPRINT_CONTRACT.md               Sprint 0: housekeeping (debt + upgrades)
  → implement → self-evaluate             → write SPRINT_CONTRACT.md
  → harness-evaluator → QA_REPORT.md     → implement → self-evaluate
  (fail? retry, max 2x)                  → harness-evaluator → QA_REPORT.md
  (all sprints pass → Phase 4)           (fail? retry, max 2x)
         │                               (all sprints pass → Phase 4)
         └────────────────────────────────────────┘
                                 │
Phase 4: Polish (up to 15 iterations)
  detect context: frontend | backend | fullstack
  per iteration:
    harness-builder (targeted refinements)
    → harness-evaluator (polish mode, sub-criteria)
    → append POLISH_HISTORY.md
  progressive thresholds rise every 4 iterations
  (plateau? → check pivot conditions)
  (all criteria ≥ thresholds → Phase 5)
         │
Phase 5: Final QA Gate
  full-app evaluation → QA_REPORT.md
         │
Phase 6: Completion
  [MANUAL GATE — user accepts or requests changes]
  → write HANDOFF.md
  → DONE

---

Skills Table

Skill	Role	Key Inputs	Key Outputs
harness-orchestrator	Entry point, sequencing, manual gates, context monitoring	PROJECT_BRIEF.md, HANDOFF.md (on resume)	config.yaml, HANDOFF.md, PROGRESS.md, POLISH_HISTORY.md
harness-auditor	Codebase analysis for existing projects	PROJECT_BRIEF.md, existing source code	CODEBASE_AUDIT.md
harness-planner	Brief → product spec + sprint plan	PROJECT_BRIEF.md, CODEBASE_AUDIT.md (if present)	PRODUCT_SPEC.md, CALIBRATION.md (optional)
harness-builder	Spec → working code, sprint by sprint	PRODUCT_SPEC.md, SPRINT_CONTRACT.md, QA_REPORT.md (retry)	Source code, git commits, SPRINT_CONTRACT.md
harness-evaluator	QA, grading, feedback, polish scoring	SPRINT_CONTRACT.md, PRODUCT_SPEC.md, POLISH_HISTORY.md (polish)	QA_REPORT.md, POLISH_REPORT.md (polish)
harness-docs	Documentation generation and sync	skills/*/SKILL.md, scripts/*.sh, README.md	docs-site/docs/**, DOCS_REPORT.md

---

File-Based Handoffs

All inter-agent communication happens through .harness/ files. Skills never share conversation context — they read inputs from files and write outputs to files.

Why files instead of conversation context?

• Context resets are safe. If the context window fills mid-build, the orchestrator writes HANDOFF.md and the next session picks up exactly where it left off. Resume any time with Resume the harness.
• Subagent-ready. Each phase can run as a separate Claude subagent with a fresh context window. The files contain everything the next agent needs.
• Human-steerable. Edit any .harness/ file directly to change scope, override thresholds, adjust the sprint plan, or steer the design direction mid-run. No need to re-run earlier phases.
• Auditable. PROGRESS.md is an append-only trail of every major step. POLISH_HISTORY.md records every polish iteration score. The full decision history is always on disk.

Key .harness/ Files

File	Written By	Read By	Purpose
PROJECT_BRIEF.md	Orchestrator	Auditor, Planner	User's intent, audience, stack preferences, eval mode
CODEBASE_AUDIT.md	Auditor	Planner, Builder, Evaluator	Existing project assessment and recommendations
PRODUCT_SPEC.md	Planner	Builder, Evaluator	Full product spec or delta spec for existing projects
CALIBRATION.md	Planner (optional)	Evaluator	Project-specific scoring anchors for polish phase
config.yaml	Orchestrator + Planner + Auditor	All skills	Thresholds, gates, stack, polish settings
SPRINT_CONTRACT.md	Builder	Evaluator	What each sprint delivers and how to verify it
QA_REPORT.md	Evaluator	Builder (retry), Orchestrator	Sprint pass/fail with scores and actionable feedback
POLISH_REPORT.md	Evaluator (polish)	Builder (polish), Orchestrator	Sub-criteria scores and targeted polish feedback
POLISH_HISTORY.md	Orchestrator (append)	Evaluator (drift check)	Score history across all polish iterations
HANDOFF.md	Orchestrator	Orchestrator (on resume)	Full state snapshot for context-reset recovery
PROGRESS.md	Orchestrator (append)	Orchestrator (on resume)	Append-only step trail for reconciliation