Harness Starter Kit
June 18, 2026 · View on GitHub
English | 한국어 | 日本語 | 简体中文 | 繁體中文
Harness Starter Kit
A prompt-first starter kit for turning repeated coding-agent mistakes into durable repository instructions, checks, memory, and evaluation.
Product Effects
Harness Starter Kit does not position repository harnessing as raw coding performance tuning. Its product effect is operational: make agent work safer to run, easier to diagnose, and easier to improve from repository evidence.
- Isolate agent work safely. Run agent tasks inside clear repository boundaries so hidden or sensitive files, generated outputs, credentials, and forbidden paths stay out of normal task flow.
- Turn failures into diagnosis. Separate functional, schema, workflow, boundary, timeout, and hidden-access failures instead of reducing an agent result to one pass/fail label.
- Transfer repository conventions. Preserve local API style, documentation placement, validation commands, and review expectations in durable repo guidance that agents can follow repeatedly.
- Create an improvement loop. Convert observed mistakes into instructions, checks, failure records, decision memory, benchmark tasks, or review points so the next agent run has better operating context.
Quick Start
Open the target repository with your coding agent and give it this prompt.
Show full adoption prompt
Use this kit to apply harness engineering to this repository:
https://github.com/harnessworks/harness-starter-kit
Clone the kit into ./harness-starter-kit if it is not already present, read it,
then apply its prompt-first harness engineering workflow to this repository.
Requirements:
- Treat the current working directory as the target repository.
- Treat ./harness-starter-kit as read-only reference material after cloning.
- Inspect this repository before editing.
- Preserve existing architecture, tools, package manager, commands, docs, and
conventions.
- Do not blindly copy templates.
- Add only the minimum useful harness pieces.
- Prefer updating existing docs/configs over duplicating them.
- Do not overwrite or delete existing files without explaining why.
- If I ask for /harness doctor, use
./harness-starter-kit/commands/harness-doctor.md.
- If I ask for /harness update after adoption, use
./harness-starter-kit/commands/harness-update.md to refresh the kit reference,
record .harness/source.json, and selectively update target harness files
without blindly overwriting existing files.
- If I ask for /harness refresh after adoption, use
./harness-starter-kit/commands/harness-refresh.md to review existing harness
docs, rules, knowledge records, and checks for stale or duplicated guidance.
Do not delete, archive, move, or rename files without my explicit approval for
the specific files.
- If I ask for /harness review sub-agent, use
./harness-starter-kit/commands/harness-review.md and treat the request as
explicit permission to use a read-only reviewer subagent when available and
permitted by the active runtime and tool instructions. If unavailable,
blocked, not permitted, or failed, report the fallback reason.
- If I ask for /harness review, use
./harness-starter-kit/commands/harness-review.md to review the current change
set from an opposing harness-engineering perspective. Report findings,
missing checks, overreach, durable memory gaps, and follow-up recommendations
without modifying files unless I explicitly ask you to apply fixes after the
review.
Expected result:
- project-specific AGENTS.md or updated existing agent instructions
- knowledge store if no equivalent exists
- lightweight drift checks based on this repo's real rules
- local verification commands using existing tools
- adoption report with files changed, checks to run, assumptions, remaining
manual steps, failure memory, effectiveness measurement plan,
normal/focused/manual gate placement, and whether
./harness-starter-kit should be removed, ignored, or kept before commit
For the full prompt and workflow details, see
docs/prompts/apply-to-target-repo.md
and docs/adoption-workflow.md.
💫 If this kit helps you, a GitHub star would be appreciated. 💫
Harness Theory
Harness engineering treats the repository as the durable operating environment for coding agents:
Harness = Instructions + Constraints + Feedback + Memory + Evaluation + Governance
Harness health is different from agent effectiveness. Harness Doctor can scan
for durable repository evidence, but it cannot prove that agents make fewer
mistakes. Measure that separately with task outcomes and effectiveness reports.
See docs/theory/harness-engineering.md
for the model.
Every recurring agent failure should be converted into at least one durable artifact: a clearer instruction, an automated constraint, a test or CI check, a decision or failure record, or a drift check.
Command Flow
The /harness ... names below are prompt conventions by default, not built-in
editor commands. Type or paste them into your coding agent chat. In editors such
as Cursor, they will not appear in the command palette unless you separately add
matching custom slash commands.
Think about the commands by user stage:
| Stage | Command | Use when |
|---|---|---|
| First time | /harness doctor | Inspect current harness readiness without modifying files. |
| First time | /harness adopt | Apply the smallest useful harness pieces to this repository. |
| Daily work | /harness review | Challenge the current diff before commit or PR. |
| Daily work | /harness review sub-agent | Explicitly request a read-only reviewer subagent when the runtime permits it. |
| Maintenance | /harness update | Bring in a newer harness-starter-kit reference and selectively update this repo. |
| Maintenance | /harness refresh | Clean up stale, duplicated, obsolete, or unused harness guidance already in this repo. |
Quick rule:
- Use
doctorto inspect. - Use
adoptto start. - Use
reviewbefore finishing work. - Use
updatewhen the kit version changes. - Use
refreshwhen this repo's existing harness guidance gets stale.
See commands/ for full workflows:
adopt,
doctor,
update,
refresh,
and review.
Install Agent Skills
Harness workflows are prompt-first by default, but the same workflows are also published as runtime-native skills for Codex and Claude Code.
Codex
codex plugin marketplace add harnessworks/harness-agent-skills-marketplace --ref v0.1.16
Restart Codex, open the Plugins screen, select Harnessworks, and install
harness-agent-skills.
Use the same command model in every runtime:
Start: $harness doctor → $harness adopt
Daily: $harness review
Maintain: $harness update or $harness refresh
Common commands:
$harness doctor
$harness adopt
$harness review
Maintenance commands:
$harness update
$harness refresh
Claude Code
claude plugin marketplace add harnessworks/harness-agent-skills-marketplace@v0.1.16
claude plugin install harness-agent-skills@harnessworks
Use the router command:
Start: /harness-agent-skills:harness doctor → /harness-agent-skills:harness adopt
Daily: /harness-agent-skills:harness review
Maintain: /harness-agent-skills:harness update or /harness-agent-skills:harness refresh
Common commands:
/harness-agent-skills:harness doctor
/harness-agent-skills:harness adopt
/harness-agent-skills:harness review
Maintenance commands:
/harness-agent-skills:harness update
/harness-agent-skills:harness refresh
The source package lives in agent-skills/. For direct
repo-local installs, packaging details, and update behavior, see
docs/agent-skills-package.md.
How Adoption Works
Show adoption details
This is not primarily an automatic installer. The agent should inspect the
target repository first, then adapt the smallest useful set of harness
artifacts: instructions, enforceable constraints, feedback loops, durable
memory, drift checks, and an adoption report. Follow
docs/adoption-workflow.md and the prompt in
docs/prompts/apply-to-target-repo.md.
Use the optional installer only when you want a skeleton before agent-driven
adaptation. It copies profile snippets into
docs/harness/profiles/<profile> for review; prompt-first adoption reads
profiles from the cloned kit at
harness-starter-kit/templates/profiles/<profile>.
python harness-starter-kit/scripts/apply_harness.py --target . --profile generic --dry-run
Profiles shown in the badges above are conservative reference snippets, not
automatic migrations. See docs/profiles.md and
docs/checklists/profile-absorption.md.
For the detailed documentation index, see
docs/component-map.md. Common adoption references:
docs/checklists/external-api-work.md,
docs/checklists/decision-failure-memory.md,
and docs/checklists/verification-scripts.md.
Validation coverage and local checks live in
docs/validation.md. Lifecycle pilot details live in
docs/examples/lifecycle-pilot-results.md.
They do not prove that harness adoption reduces repeated agent mistakes. Use
docs/evaluation.md,
docs/templates/effectiveness-report.md,
and docs/templates/task-outcome.yaml to
measure comparable tasks, wrong-file edits, first-pass verification, and human
rework.
Dogfood reports include
TodayBus for a
Next.js public-data target and
Harness ERP for
a Spring/Maven backend and vanilla frontend target. Both are harnessed-only
benchmarks, not proof of effectiveness improvement.
Contributors
Thanks to everyone who has helped shape this kit through code, docs, reviews, examples, translations, and dogfooding.
Recognition
Listed in:
- Awesome-AI-Agents as an AI agent tooling project.
- github/awesome-copilot as a Copilot customization resource.
License
This project is licensed under the MIT License.