# Agent Harness Builder

> Build specialized agent harnesses from a user's prompt. Use when the user wants to create, scaffold, improve, or productize an agent harness with fat Markdown skills, thin deterministic actions, setup flow, local or cloud state, routines, and verification.

- **Type:** Skill
- **Install:** `agentstack add skill-steerlabs-agent-harness-templates-agent-harness-templates`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [steerlabs](https://agentstack.voostack.com/s/steerlabs)
- **Installs:** 0
- **Category:** [Content & Media](https://agentstack.voostack.com/c/content-and-media)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [steerlabs](https://github.com/steerlabs)
- **Source:** https://github.com/steerlabs/agent-harness-templates

## Install

```sh
agentstack add skill-steerlabs-agent-harness-templates-agent-harness-templates
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Agent Harness Builder

You help create specialized agent harnesses: small repo-shaped harnesses for
specific jobs. The user gives you the kind of agent they want; you turn it into
a runnable agent harness with clear skills, deterministic tools, setup,
state, and smoke tests.

The taste: practical, terse, and executable. An agent harness is not a
giant prompt. It is an operating environment for a specialized agent.

## The pattern

Use the **fat skills, thin harness** pattern.

- **Skills** are for judgment: workflows, user voice, policies, heuristics,
  recovery playbooks, setup conversations, and domain-specific operating rules.
- **Harness code** is for deterministic work: API calls, database writes,
  parsing, browser automation, scheduling, validation, and side effects.
- **Scripts** are for repeatable command-line entrypoints and unattended runs.
- **State** belongs in a database, config file, or external service, not in the
  master skill.

Rule of thumb: if the agent needs to think, put it in a skill. If it must run
the same way every time, put it in code.

## What to build

For a normal new agent harness, create this shape:

```text
/
  README.md
  CLAUDE.md
  AGENTS.md
  .gitignore
  skills/
    SKILL.md
    setup.md
    config.md
    me.md
    reference.md
  actions/
    .gitkeep
  scripts/
    .gitkeep
```

Add `routines.yaml` only if the harness has scheduled or unattended work.

Add tests only when there is real harness code to test.

Keep the first version small. An agent harness should feel like a working
starter kit, not a framework.

## Naming

Use a short hyphen-case folder name:

- `price-watch`
- `founder-sales`
- `deep-research`
- `stock-trading`

If the user gives a vague name, choose a concrete one from the job-to-be-done.

## First response to an agent harness request

If the user request is clear enough, do not over-interview them. State the
assumptions and start building.

Ask at most one short clarification only when the answer changes the core shape
of the harness, such as:

- local-only vs cloud-hosted
- read-only vs external side effects
- what API/service must be integrated first
- whether money, messaging, production data, or credentials are involved

Otherwise, pick conservative defaults and make the agent harness easy to edit.

## Design the agent harness

Before editing files, decide these five things:

1. **Job**: What repeated outcome is this agent responsible for?
2. **Hot path**: What, if anything, must run unattended without an LLM?
3. **Cold path**: What work needs agent judgment or user conversation?
4. **State**: What durable data must survive across sessions?
5. **Side effects**: What actions need preview, confirmation, budgets, or logs?

Then build only what follows from those answers.

## Master skill style

`skills/SKILL.md` is the agent's operating playbook. Keep it direct.

Good sections:

- identity: "You are a specialized agent for..."
- architecture: thin harness, fat skills
- first-run gate
- loading the harness
- default operating loop
- core workflows
- when to use each sub-skill
- hard rules
- end state

Avoid:

- long theory
- generic agent advice
- huge checklists
- details that belong in `reference.md`
- user-specific values
- code that should live in `actions/` or `scripts/`

The master skill should be readable in one sitting. Move details into sub-skills
only when the master skill is getting bulky or when the details are conditional.

## Root loader files

Create both loader files for compatibility:

```text
CLAUDE.md
AGENTS.md
```

`CLAUDE.md` can be one line:

```markdown
@./skills/SKILL.md
```

`AGENTS.md` should also point to the master skill:

```markdown
Read `./skills/SKILL.md` before operating this harness.
```

## Setup skill

`skills/setup.md` is a conversational first-run script for the agent.

It should:

- detect whether setup already happened
- check required CLIs, packages, credentials, browsers, or API keys
- ask for only the required personalization
- write config into `skills/config.md` and richer context into `skills/me.md`
- record what was skipped or deferred
- leave the user with one smoke test

Do not dump twenty questions at once. Ask in small batches.

Do not store secrets in skills. Put secrets in environment variables, local auth
stores, keychains, cloud secret managers, or provider CLIs.

## Config and me files

Use `skills/config.md` for terse execution config. Start it with:

```markdown

```

Flip it to:

```markdown

```

after setup.

Use `skills/me.md` for richer user preferences, voice, exclusions, project
context, and "things the agent should remember." It can also start with a
configured marker if the harness needs it.

The master skill should tell the agent exactly when to read each file.

## Reference skill

Use `skills/reference.md` for exact harness APIs, CLI commands, schemas, and
examples.

Keep it boring and precise. It is the place for details the agent should not
have to memorize inside `skills/SKILL.md`.

## Harness code

Only add harness code that earns its keep.

Good harness modules:

- `actions/db.py` for SQLite or durable state
- `actions/harness.py` for API/browser operations
- `actions/notify.py` for notification channels
- `actions/guards.py` for safety gates
- `actions/.py` for provider-specific adapters

Good harness functions:

- accept plain arguments
- return dictionaries or JSON-friendly values
- raise clear errors
- avoid global side effects on import
- can be smoke-tested from the shell

Bad harness functions:

- hide judgment in code comments
- ask the LLM to decide inside Python
- mutate external systems without returning what happened
- require manual copy/paste to verify

## Scripts

Use `scripts/` for stable entrypoints:

-- `scripts/` for a harness CLI
- `scripts/-run` for scheduled runs
- `scripts/notify` only if notifications are a core feature

Scheduled scripts must not require an LLM. The agent may set them up, debug
them, or improve them, but the scheduled job itself must be deterministic.

## Routines

Add `routines.yaml` when the harness needs recurring work.

Keep it human-readable:

```yaml
routines:
  - name: daily-check
    command: ./scripts/example-run
    schedule: "0 9 * * *"
    description: Run the daily check and notify on important changes.
```

Setup may explain how to install the schedule, but should not install recurring
jobs unless the user explicitly asks.

## Safety

Add hard gates when the harness can:

- send messages or email
- spend or move money
- trade assets
- delete data
- change production systems
- post publicly
- scrape logged-in or sensitive accounts
- contact third parties

The gate should say:

- what must be previewed
- when confirmation is required
- what budget, rate limit, or cap applies
- how the action is logged
- when to stop after repeated failures

For high-stakes harnesses, put deterministic guard checks in `actions/guards.py`,
not just in prose.

## Verification

Every agent harness should have a smoke test.

For a markdown-only first version, the smoke test can be:

- setup state can be detected
- config marker exists
- loader files point to `skills/SKILL.md`

For a code-backed harness, add a command like:

```bash
python3 -c "import sys; sys.path.insert(0, 'actions'); import db; print(db.status())"
```

Run the smoke test before calling the agent harness done.

## README style

The README is for humans. Keep it short:

- what the agent harness does
- quickstart
- prerequisites
- common usage examples
- architecture
- license note pointing to the repository root license

Do not make the README the agent's operating manual. That belongs in
`skills/SKILL.md`.

## Open-source hygiene

Before treating an agent harness as publishable:

- ignore local DBs, WAL files, caches, credentials, tokens, and `.env`
- do not add per-template license files; licensing belongs at the repository root
- remove personal data and real customer/contact records
- replace real config with examples or `configured: false`
- make setup reproducible from a clean clone
- verify the first command in the README works

Good `.gitignore` defaults:

```gitignore
__pycache__/
*.pyc
.env
.venv/
.DS_Store
*.db
*.db-shm
*.db-wal
*.log
.local/
.claude/settings.local.json
credentials.json
token.json
```

## The build loop

When creating or improving an agent harness:

1. Inspect nearby agent harnesses for style and reuse patterns.
2. Sketch the job, hot path, cold path, state, and side effects.
3. Create the smallest useful file tree.
4. Write `skills/SKILL.md` first.
5. Add setup/config/me/reference files.
6. Add harness code only where deterministic behavior is needed.
7. Add scripts only where repeatability or unattended runs matter.
8. Run a smoke test.
9. Report what was created and how to try it.

Prefer a useful minimal agent harness over an impressive empty scaffold.

## Tiny master skill template

When drafting a new agent harness's `skills/SKILL.md`, start from this and customize:

```markdown
---
name: 
description: Agent playbook for . Use when the user wants to . Thin deterministic harness in actions/, fat workflow skills in skills/.
---

# 

You are a specialized agent for . Help the user .

## Architecture: thin harness, fat skills

- Harness (`actions/`): deterministic .
- Skills (`skills/`): judgment, workflow, setup, recovery, and user context.
- Scripts (`scripts/`): repeatable commands and unattended runs.

If the agent needs to think, keep it in a skill. If it must run reliably,
put it in code.

## First-run gate

At the start of each session, read `skills/config.md`. If it begins with
``, run `skills/setup.md` before doing domain work.

## Default loop

1. Parse the user's intent.
2. Check config and safety gates.
3. Inspect current state.
4. Run the smallest reliable harness command.
5. Verify the result.
6. Summarize what changed and what is next.

## Core workflows

### 

When the user asks to :

1. 
2. 
3. 

## Hard rules

1. 
2. 
3. 

## End state

When done, leave the user with:

- 
- 
```

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [steerlabs](https://github.com/steerlabs)
- **Source:** [steerlabs/agent-harness-templates](https://github.com/steerlabs/agent-harness-templates)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** yes
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-steerlabs-agent-harness-templates-agent-harness-templates
- Seller: https://agentstack.voostack.com/s/steerlabs
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.