harness-engineeringv1.0.0latest

---
name: harness-engineering
version: 1.0.0
url: https://clawskills.io/api/skills/harness-engineering/releases/1.0.0/SKILL.md
artifact_sha256: ca9ed70c2c4d5786531337660828714d179faaaaca89c9101cb97abc732c147e
signature: didMNK5j93b/YnyPe4cOpECU0P7RGT3SHqgHG9TwoterVlTpchc6763PohOUxp6VNbWZbjQf33SCD5dlkKlkDg==
key_id: 625b196966442b38cf1c7188ba15fa81
verify: https://clawskills.io/docs/verification
---

Use vibe coding as freedom inside a harness:

1. Scaffold the harness first: context docs, architecture boundaries, principles, CI, lint, and test commands.
2. Let the user describe outcomes in natural language instead of implementation details.
3. Let the agent choose implementation details within documented boundaries.
4. After each change, run checks and update docs only when the change alters durable behavior.
5. When a mistake repeats, add a principle, linter, eval, or cleanup task instead of relying on memory.

The goal is not to eliminate judgment. The goal is to move judgment into reusable structures.

## Drift And Garbage Collection

Agents imitate existing patterns, including bad ones. Treat technical debt as something that compounds.

Use periodic cleanup agents or cleanup passes to:

- Find violations of golden principles.
- Detect dependency-direction drift.
- Reduce files that grew beyond local standards.
- Remove dead abstractions and stale generated docs.
- Prune stacked changes where a simpler version works equally well.
- Open small reviewable PRs instead of broad rewrites.

Cleanup agents should usually be read-only until a human asks for fixes or explicitly approves an edit loop.

## PR And Review Loop

For agent-produced changes:

```text
author agent -> local checks -> local review agent
-> fix feedback -> second independent review when risk is high
-> human review for merge/deploy/destructive approval
```

Review should prioritize:

- Behavioral regressions.
- Broken architecture boundaries.
- Missing tests or weak acceptance criteria.
- Security, privacy, cost, and irreversible actions.
- Drift away from golden principles.

Keep PRs small enough that a human can review them quickly.

## Autonomous Loop Design

Use this checklist before starting a long-running or background agent:

1. Define the objective in one sentence.
2. Define success and stop conditions.
3. Classify locked, editable, append-only, and human-controlled surfaces.
4. Create a durable log before the loop starts.
5. Choose feedback: tests, lint, scalar metric, rubric, human review, or a combination.
6. Define keep, discard, crash, timeout, and review states.
7. Preserve rejected attempts so future agents do not repeat them.
8. Define approval boundaries for merge, deploy, billing, credentials, data deletion, or external messages.
9. Validate on one known-good and one known-bad case.

Minimal loop:

```text
read locked context -> choose next attempt -> edit allowed surface
-> run feedback -> log result -> keep, discard, rollback, or route to review
```

## Output Templates

Use these compact formats when helpful.

Harness diagnosis:

```text
Objective:
Current phase:
Missing context or capability:
Locked surfaces:
Editable surfaces:
Append-only state:
Human approval boundary:
Smallest useful feedback loop:
Next action:
```

Harness change proposal:

```text
Problem observed:
Durable fix:
Why this belongs in the harness:
Files or rules to change:
How to verify:
Risk:
```

Cleanup task:

```text
Drift pattern:
Principle violated:
Candidate files:
Safe automated check:
Proposed small PR:
Human review needed:
```

## Gotchas

- Mutable evaluator: if the agent can change the rule and then score itself, the loop is unsafe.
- Chat-only memory: plans disappear across compaction; write state to files.
- No rejected-attempt log: future agents rediscover failed ideas.
- Over-broad autonomy: vague objectives create vague work.
- Principle without check: a rule nobody can observe becomes decoration.
- Cleanup without restraint: broad refactors are hard to review; prefer small PRs.
- Approval ambiguity: "prepare a PR" is not "merge it"; "draft a deploy plan" is not "spend money."
- Over-context: too many docs without indexes makes context harder, not easier.