harness-starter
Skill438 starsChanged 7 months agoMITView on GitHub
A portable orchestrator that completes a high-level task through 5 stages — clarify → context-gather → plan → implement → verify. Each stage hands off via file artifacts, and a stage is skipped when its artifact already exists. The plan is decomposed into a task graph (DAG); independent nodes run in parallel, dependent nodes run in order.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- nadavnaveh/skillstheir own version, first seen Nov 8, 2026
- devexpert-io/harness-startertheir own version, first seen Sep 26, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- devexpert-io/harness-starter★ 4same name
- nadavnaveh/skills★ 2same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository16 other files it gives its agents.
- cc-usage-auditSkill
- commitSkill
- discord-messageSkill
- email-draftSkill
- gmailSkill
- google-calendarSkill
- hook-creatorSkill
- ideationSkill
- persuasion-reviewSkill
- plan-and-buildSkill
- shipSkill
- skill-creatorSkill
- slash-command-creatorSkill
- subagent-creatorSkill
- transcribeSkill
- youtube-collectorSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 7 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 13
If references/conventions.md is filled in, pass its contents into every delegation prompt.
- Very specific: line 18
Create .harness/{specs,context,plans,reports}/ if missing.
- Very specific: line 25
If .harness/specs/<slug>.spec.md exists → skip.
- Distinctive: line 27
If ambiguity is high, clarify may ask the user (questions are allowed in this stage only).
- Very specific: line 34
If .harness/plans/<slug>.plan.md exists → skip (treat as a validated plan).
- Distinctive: line 36
Check the returned plan against the decomposition checklist (decomposition.md): 3–6 nodes?
- Distinctive: line 39
If human approval is desired, summarize the plan and confirm before proceeding (optional).
- Distinctive: line 56
If a node fails: do not advance its dependents.
- Very specific: line 57
Scope escalation: if an implementer reports it needs to edit a shared/crosscutting file outside its scope (it must NOT have edited it), add …
- Very specific: line 65
When all nodes are done, delegate to harness-verifier → produces report.md.
- Distinctive: line 66
If verdict=PASS, report completion.
- Distinctive: line 67
If verdict=FAIL: per the report's "on failure" instruction, reset only the failed nodes to status=pending and run one more wavefront pass …
- Distinctive: line 71
Stages hand off only via artifacts: Do not let the next-stage agent rely on "context in your head" — always have it read the files …
- Very specific: line 80
Use this harness only up to plan, then implement/verify with another tool → hand over plan.md.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
$ARGUMENTS
Handle the request above through the 5-stage harness. You are the orchestrator. Do not analyze or implement code yourself — delegate each stage to a dedicated subagent, hand off via artifacts, and schedule the task graph.
First, study references/artifacts.md (artifact contracts) and references/decomposition.md (decomposition criteria).
If references/conventions.md is filled in, pass its contents into every delegation prompt.
0. Setup
- Choose a
<slug>(kebab-case) to identify the task. - Create
.harness/{specs,context,plans,reports}/if missing.
Stage procedure (judge skip before each stage)
Each stage is skipped when its artifact already exists (reuse outputs made by external tools or humans).
1. Clarify
- If
.harness/specs/<slug>.spec.mdexists → skip. - Otherwise delegate to the
harness-clarifyagent → producesspec.md. - If ambiguity is high, clarify may ask the user (questions are allowed in this stage only).
2. Context Gather
- If
.harness/context/<slug>.context.mdexists → skip. - Otherwise give the spec to
harness-contextand delegate → producescontext.md. (read-only)
3. Plan
- If
.harness/plans/<slug>.plan.mdexists → skip (treat as a validated plan). - Otherwise give spec + context to
harness-plannerand delegate → producesplan.md(task graph). - Check the returned plan against the decomposition checklist (decomposition.md): 3–6 nodes? per-node acceptanceCriteria? are parallel nodes file/module-scoped (no conflicts)? no cycles in blockedBy? If anything is off, ask the planner to fix it (up to 2 times).
- If human approval is desired, summarize the plan and confirm before proceeding (optional).
4. Implement — wavefront execution of the task graph
Execute plan.md nodes in parallel, wave by wave. No locks or scripts — the orchestrator schedules:
loop:
1. ready = nodes whose blockedBy are all status=done AND whose own status=pending
2. if ready is empty but unfinished nodes remain → deadlock (cycle/stuck). Stop and report.
3. delegate the ready nodes in parallel within a single message:
for each node, Task(harness-implementer, input = that node + spec + context + conventions)
(nodes in the same wave are file/module-scoped, so there are no write conflicts — safe to parallelize)
4. on each node completion, update its status in plan.md to done (or failed).
5. when all nodes are done, finish.- Within one wave, issue multiple implementer Tasks in the same message (do not wait for one to finish).
- If a node fails: do not advance its dependents; re-delegate the failed node once (attach a cause summary). If it still fails, stop and report.
- Scope escalation: if an implementer reports it needs to edit a shared/crosscutting file outside its scope
(it must NOT have edited it), add a new wire-up node scoped to that file,
blockedBythe nodes that feed it, and schedule it in a later wave. This converts a would-be parallel collision into a serialized node. - When in doubt, serialize. Parallelism is an optimization, not a requirement. If you can't be confident two ready nodes are truly independent (disjoint files, no semantic dependency), run them in separate waves instead. A single-file or uncertain plan should just run sequentially — correctness over speed.
5. Verify
- When all nodes are done, delegate to
harness-verifier→ producesreport.md. Input = spec (acceptance criteria) + plan (nodes) + actual changes. - If verdict=PASS, report completion.
- If verdict=FAIL: per the report's "on failure" instruction, reset only the failed nodes to status=pending and run one more wavefront pass (fix loop). If still FAIL, stop and report to the human.
Principles
- Stages hand off only via artifacts. Do not let the next-stage agent rely on "context in your head" — always have it read the files (subagents start with fresh context).
- The orchestrator does not implement. Analysis/exploration/implementation/verification are all done by subagents. You only schedule, manage artifacts, and judge skips.
- Do not manufacture over-verification or over-decomposition. A trivial task may have a 1-node plan and a light verify. Scale to the size.
- User questions only in the clarify stage. Later stages proceed on the assumptions recorded in the artifacts.
- For a single-node task, the wavefront is just one implementer call — create no overhead.
Partial use (cherry-pick)
You need not run the whole harness. Since each stage's artifact is a contract:
- Use this harness only up to plan, then implement/verify with another tool → hand over
plan.md. - Drop an externally produced
spec.md/plan.mdinto.harness/and that stage is skipped automatically.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

