Harness · GAN 对抗式工程框架

---
name: harness
description: |
  GAN-inspired Harness Engineering Skill. Three-agent adversarial architecture:
  Planner (direction) → Generator (build) → Evaluator (strict scoring).
  Turns a single prompt into production-grade applications through iterative adversarial refinement.

  Trigger: /harness, harness build, harness stop
metadata:
  version: 4.0.1
---

# Harness Engineering

GAN-inspired three-agent architecture for building production-grade applications from a single prompt.
Based on Anthropic's Harness Engineering methodology (March 2026).

## Core Principle

**Agent performance ceiling is determined not by model capability, but by the system around it.**

Single Agent → quick but fragile (core features often broken).
Harness → slower and costlier, but produces genuinely functional, feature-rich applications.

**Prime principle: originality and quality outrank speed, cost, and minimalism.** Simplicity rules constrain the *implementation* (plainest code that works); they never constrain the *product experience* (the most intentional, distinctive experience the spec allows). Every artifact this harness generates — rubric, contract, fix brief — carries this hierarchy.

## Commands

```bash
/harness build [description]                # Autonomous mode (default): one-shot end-to-end delivery
/harness build --supervised [description]   # Supervised mode (v2.4): user approves each phase
/harness build --requirements <file.md>     # Load requirements from a structured doc instead of one-line prompt
/harness stop                               # Shut down the harness, clean up resources
/harness resume                             # Resume from .harness/checkpoint.md if interrupted
```

Examples:
```bash
# Autonomous (default — runs to completion, ships a finished artifact)
/harness build "Create a browser-based music production DAW"
/harness build --requirements ./spec.md

# Supervised (interactive — user is gatekeeper at every phase boundary)
/harness build --supervised "Build a 2D retro game maker with sprite editor"
```

## Operating Modes

### Autonomous Mode (default in v3.0)
Designed for **one-shot end-to-end delivery**. Given a single requirements doc:
1. Decisions are made by the **Decision Engine** using deterministic rules.
2. Ambiguities are resolved using documented defaults (logged to `ambiguities.md` for audit).
3. Budget enforces stop conditions; build either ships or escalates with `BLOCKED.md`.
4. Final delivery includes README, CHANGELOG, KNOWN_LIMITATIONS, fresh-clone smoke test, aesthetic review.

Realistic coverage: **~70% of "standard" requirements** (CRUD apps, internal tools, prototypes, demos) ship cleanly. Specialized domains, ambiguous specs, or aesthetic-critical projects may degrade to PARTIAL_SHIP and surface escalation points.

### Supervised Mode (--supervised flag)
The v2.4 flow. User reviews and approves: product-spec, rubric, sprint contract, and Continue/Ship at every iteration. Use when:
- Requirements are vague or evolving