harness-engineering

Name: harness-engineering
Author: muratcankoylan

38installs1.4kforks

How to install harness-engineering?

muratcankoylan/agent-skills-for-context-engineering/harness-engineering

$npx -y skills add muratcankoylan/Agent-Skills-for-Context-Engineering --skill harness-engineering

Installs into the current project.

Summary

This skill should be used when designing autonomous agent harnesses: research loops, evaluation scaffolds, locked and editable surfaces, durable logs, novelty gates, pruning, rollback, PR preparation, and human approval boundaries.

Files · 1

View on GitHub

SKILL.md

1	# Harness Engineering
2
3	Harness engineering designs the control system around an agent: what it may edit, how it receives feedback, where it writes state, how failures recover, and who can approve irreversible actions. The harness is the difference between a helpful agent session and an autonomous loop that can run for days without corrupting its objective.
4
5	## When to Activate
6
7	Activate this skill when:
8
9	- Building autonomous research or experimentation loops
10	- Designing an agent environment with locked metrics and editable code or content
11	- Creating PR-producing or background agents
12	- Evaluating whether an agent can safely run without frequent human prompts
13	- Adding novelty, ablation, pruning, rollback, or durable logging to an agent workflow
14	- Preventing agents from gaming benchmarks, weakening rubrics, or losing state across compaction
15
16	Do not activate this skill for adjacent work owned by other skills:
17	- General quality gates, regression suites, or outcome metrics without autonomous control surfaces: `evaluation`.
18	- Tool schemas, response formats, and recovery errors for harness tools: `tool-design`.
19	- Project-level task-model fit, pipeline shape, and cost planning: `project-development`.
20	- Remote sandbox, warm-pool, and hosted session infrastructure: `hosted-agents`.
21
22	## Core Concepts
23
24	### Harness Boundary
25
26	Separate the agent from the environment it operates inside. The agent proposes actions; the harness defines allowed surfaces, feedback, persistence, and promotion rules.
27
28	Use four surface classes:
29
30	\| Surface \| Examples \| Rule \|
31	\| --- \| --- \| --- \|
32	\| Locked \| Eval metric, rubric, validation script, merge policy \| Agent may read and propose changes, but cannot score itself with modified rules \|
33	\| Editable \| Skill draft, experiment file, prompt, config under test \| Agent may mutate during the loop \|
34	\| Append-only \| Results log, research thread, rejected ideas \| Agent may append, not rewrite \|
35	\| Human-controlled \| Merge, production deploy, credentials, destructive operations \| Requires explicit human approval \|
36
37	### Tight Feedback Loops
38
39	Autonomy works when feedback is fast, unambiguous, and hard to game. Karpathy's `autoresearch` is the minimal pattern: one editable file, one locked evaluation file, fixed wall-clock budget, one scalar metric, git rollback, and a durable results log. The lesson is not that every harness needs one metric; it is that ambiguous feedback creates ambiguous autonomy.
40
41	For open-ended research-to-skill work, replace the scalar metric with locked rubrics, deterministic structure checks, source traceability, and human review thresholds.
42
43	### Durable State
44
45	Long-running agents must externalize state. Store plans, source queues, results, failures, and handoffs in files so future agents can resume without relying on chat history. Prime Intellect's autonomous nanoGPT work showed the value of durable scratchpads and `THREAD.md`-style logs for recovery, monitoring, and audit.
46
47	Use append-only logs for:
48
49	- What was tried
50	- What improved or failed
51	- Why a candidate was kept, discarded, or routed to review
52	- Which upstream sources were checked
53	- What the next agent should do
54
55	### Search Discipline
56
57	Agents tend to exploit the nearest surface, stack complexity, and under-run pruning. Add explicit search rules:
58
59	1. Refresh upstream sources on a schedule.
60	2. Require novelty checks before spending large budgets.
61	3. Preserve rejected attempts to avoid rediscovery.
62	4. Run leave-one-out pruning when a stack has multiple additions.
63	5. Reward simplification when quality is equal.
64	6. Use separate verification before promotion.
65
66	### Mechanism Registry
67
68	For research-to-skill systems, track accepted mechanisms separately from prose. A mechanism record should include a stable `mechanism_id`, `owning_skill`, `status`, activation scenario, behavior change, evidence, and failure modes. Novelty gates should compare against this registry before using broader corpus overlap, because keyword overlap catches stale phrasing while mechanism comparison catches real duplication.
69
70	### Governance
71
72	Autonomous agents may prepare PRs, but governance must be explicit. They can draft changes, run checks, and write PR summaries. They should not merge, deploy, or push without human approval unless the user has explicitly granted that permission for the specific action.
73
74	## Detailed Topics
75
76	### Autoresearch-Style Loop
77
78	Use this pattern when optimizing an artifact against a stable evaluator:
79
80	```text
81	read locked context -> choose hypothesis -> edit allowed surface -> commit/checkpoint
82	-> run evaluator -> log result -> keep if better -> discard or rollback if worse
83	-> repeat
84	```
85
86	Required properties:
87
88	- The evaluator is outside the editable surface.

People who liked this also viewed

6 picks

Type

harness-engineering

38installs1.4kforks

View on GitHub

How to install harness-engineering?

muratcankoylan/agent-skills-for-context-engineering/harness-engineering

$npx -y skills add muratcankoylan/Agent-Skills-for-Context-Engineering --skill harness-engineering

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Harness Engineering
2
3	Harness engineering designs the control system around an agent: what it may edit, how it receives feedback, where it writes state, how failures recover, and who can approve irreversible actions. The harness is the difference between a helpful agent session and an autonomous loop that can run for days without corrupting its objective.
4
5	## When to Activate
6
7	Activate this skill when:
8
9	- Building autonomous research or experimentation loops
10	- Designing an agent environment with locked metrics and editable code or content
11	- Creating PR-producing or background agents
12	- Evaluating whether an agent can safely run without frequent human prompts
13	- Adding novelty, ablation, pruning, rollback, or durable logging to an agent workflow
14	- Preventing agents from gaming benchmarks, weakening rubrics, or losing state across compaction
15
16	Do not activate this skill for adjacent work owned by other skills:
17	- General quality gates, regression suites, or outcome metrics without autonomous control surfaces: `evaluation`.
18	- Tool schemas, response formats, and recovery errors for harness tools: `tool-design`.
19	- Project-level task-model fit, pipeline shape, and cost planning: `project-development`.
20	- Remote sandbox, warm-pool, and hosted session infrastructure: `hosted-agents`.
21
22	## Core Concepts
23
24	### Harness Boundary
25
26	Separate the agent from the environment it operates inside. The agent proposes actions; the harness defines allowed surfaces, feedback, persistence, and promotion rules.
27
28	Use four surface classes:
29
30	\| Surface \| Examples \| Rule \|
31	\| --- \| --- \| --- \|
32	\| Locked \| Eval metric, rubric, validation script, merge policy \| Agent may read and propose changes, but cannot score itself with modified rules \|
33	\| Editable \| Skill draft, experiment file, prompt, config under test \| Agent may mutate during the loop \|
34	\| Append-only \| Results log, research thread, rejected ideas \| Agent may append, not rewrite \|
35	\| Human-controlled \| Merge, production deploy, credentials, destructive operations \| Requires explicit human approval \|
36
37	### Tight Feedback Loops
38
39	Autonomy works when feedback is fast, unambiguous, and hard to game. Karpathy's `autoresearch` is the minimal pattern: one editable file, one locked evaluation file, fixed wall-clock budget, one scalar metric, git rollback, and a durable results log. The lesson is not that every harness needs one metric; it is that ambiguous feedback creates ambiguous autonomy.
40
41	For open-ended research-to-skill work, replace the scalar metric with locked rubrics, deterministic structure checks, source traceability, and human review thresholds.
42
43	### Durable State
44
45	Long-running agents must externalize state. Store plans, source queues, results, failures, and handoffs in files so future agents can resume without relying on chat history. Prime Intellect's autonomous nanoGPT work showed the value of durable scratchpads and `THREAD.md`-style logs for recovery, monitoring, and audit.
46
47	Use append-only logs for:
48
49	- What was tried
50	- What improved or failed
51	- Why a candidate was kept, discarded, or routed to review
52	- Which upstream sources were checked
53	- What the next agent should do
54
55	### Search Discipline
56
57	Agents tend to exploit the nearest surface, stack complexity, and under-run pruning. Add explicit search rules:
58
59	1. Refresh upstream sources on a schedule.
60	2. Require novelty checks before spending large budgets.
61	3. Preserve rejected attempts to avoid rediscovery.
62	4. Run leave-one-out pruning when a stack has multiple additions.
63	5. Reward simplification when quality is equal.
64	6. Use separate verification before promotion.
65
66	### Mechanism Registry
67
68	For research-to-skill systems, track accepted mechanisms separately from prose. A mechanism record should include a stable `mechanism_id`, `owning_skill`, `status`, activation scenario, behavior change, evidence, and failure modes. Novelty gates should compare against this registry before using broader corpus overlap, because keyword overlap catches stale phrasing while mechanism comparison catches real duplication.
69
70	### Governance
71
72	Autonomous agents may prepare PRs, but governance must be explicit. They can draft changes, run checks, and write PR summaries. They should not merge, deploy, or push without human approval unless the user has explicitly granted that permission for the specific action.
73
74	## Detailed Topics
75
76	### Autoresearch-Style Loop
77
78	Use this pattern when optimizing an artifact against a stable evaluator:
79
80	```text
81	read locked context -> choose hypothesis -> edit allowed surface -> commit/checkpoint
82	-> run evaluator -> log result -> keep if better -> discard or rollback if worse
83	-> repeat
84	```
85
86	Required properties:
87
88	- The evaluator is outside the editable surface.

People who liked this also viewed

6 picks

Type