coding-harness
Skill0 starsChanged 7 months agoMITView on GitHub
Dispatch a Sonnet coding agent, run 5-gate audit pipeline, present results. Invoke when Opus has a coding task ready for execution. This is the local coding harness — the primary agent species for this workspace.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- jscraik/Agent-Skillstheir own version, first seen Sep 27, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- jscraik/Agent-Skills★ 9same 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 repository6 other files it gives its agents.
- audit-loopSkill
- brain-harnessSkill
- edit-modeSkill
- notebooklm-researchSkill
- research-gateSkill
- worktree-isolationSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. About 0 are common, 12 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈12
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 17
Before dispatching ANY coding agent, Opus defines in writing:
- Distinctive: line 23
Context files: ONLY the files Sonnet needs (minimum viable context — NOT the full CLAUDE.md or rules)
- Distinctive: line 24
Worktree: If parallel work, assign a worktree via worktree-isolation skill
- Very specific: line 26
Write pre-dispatch entry to memory/.harness/dispatch_log.jsonl:
- Distinctive: line 46
Do NOT inject full CLAUDE.md, full rules, or full memory into the agent prompt.
- Distinctive: line 52
Do NOT present results yet
- Distinctive: line 67
No hallucinated APIs: If agent called a function that doesn't exist in the library → FAIL.
- Distinctive: line 68
No partial implementations: If done criteria not met → FAIL.
- Distinctive: line 96
If the same issue recurs after fix: do NOT loop again.
- Distinctive: line 102
Only after ALL Stage 1 gates PASS (or Austin-approved exceptions):
- Distinctive: line 104
Commit to feature branch (pre-commit hook fires semgrep as first-line defense)
- Distinctive: line 138
Never run a second coding dispatch while audit is pending on the first
- Distinctive: line 139
All gates use INSTALLED PLUGINS — not raw MCP calls
≈ “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
Coding Harness — Full Lifecycle
Overview
This skill codifies the dispatch → code → audit → merge loop. Opus orchestrates and audits. Sonnet agents execute. All gates use installed PLUGINS. No custom code without Austin's permission.
Based on the "Coding Harness" agent species (source: Gemini/NotebookLM research, 2026-03-25).
Phase 1: Contract Definition (Opus — no agents dispatched yet)
Before dispatching ANY coding agent, Opus defines in writing:
- Task: What exactly needs to be built/changed (file path, function, behavior)
- Done criteria: Specific, testable conditions that define "done"
- Must-not: Explicit constraints (no custom wrappers, no novel patterns, use library X)
- Escalation: Conditions where Sonnet should STOP and report rather than proceed
- Context files: ONLY the files Sonnet needs (minimum viable context — NOT the full CLAUDE.md or rules)
- Worktree: If parallel work, assign a worktree via worktree-isolation skill
Write pre-dispatch entry to memory/.harness/dispatch_log.jsonl:
{
"timestamp": "ISO8601",
"task_id": "TASK-{n}",
"agent": "sonnet",
"task_summary": "...",
"target_files": ["..."],
"status": "dispatched"
}Phase 2: Execution (1 Sonnet agent)
Dispatch via Agent tool:
- model: sonnet (explicit — NEVER inherit Opus)
- mode: acceptEdits
- prompt: Contract from Phase 1 + ONLY the specified context files
- Agent codes in isolation. Completes. Returns.
Do NOT inject full CLAUDE.md, full rules, or full memory into the agent prompt.
Phase 3: Stage 1 — Local Audit (5-gate pipeline via PLUGINS)
When Sonnet returns:
- Report to Austin: "Agent came back — running Stage 1 audit"
- Do NOT present results yet
Dispatch gate agents (each = fresh Sonnet, zero-context, reports to Opus):
| Gate | Plugin(s) | What it checks |
| 1. Semgrep | semgrep plugin | Static analysis, security vulnerabilities |
| 2. CodeRabbit | coderabbit plugin | Logic issues, code quality, AI-generated code patterns |
| 3. Code-review | code-review + pr-review-toolkit plugins | Architecture, design, best practices |
| 4. Security | security-guidance plugin | OWASP top 10, injection, XSS, secure-by-default |
| 5. Clone comparison | Manual diff | Compare against reference clones in _repos/ |
| 6. Custom (conditional) | Per Austin's criteria | Additional pass/fail if Austin specifies |
Hard Gates (automatic FAIL if violated):
- No custom code without Austin's explicit permission. If agent wrote custom code where a library exists → flag it, ask Austin.
- No hallucinated APIs. If agent called a function that doesn't exist in the library → FAIL.
- No partial implementations. If done criteria not met → FAIL.
Violation Handling:
- On ANY violation: Opus asks Austin via question. Agents do NOT decide exceptions.
- Austin approves or rejects. Austin's decision is final.
- Questions are good. ASK when uncertain.
Each gate agent writes: agent_sync/audit_result_{task_id}_{gate}.md
Opus writes: agent_sync/audit_summary_{task_id}.md
Max 2 gate agents concurrent.
Phase 4: Audit Loop (MANDATORY — not optional)
execute → audit → FAIL?
↓ YES
fix → re-audit
↓ FAIL again?
same issue? → STOP → research why → different approach
new issue? → fix → re-audit
↓ FAIL a 3rd time?
STOP → escalate to Austin with: what failed, why, what was triedRules:
- A fix without a passing re-audit is NOT a pass.
- Both the executor AND the auditor must pass for work to be done.
- If the same issue recurs after fix: do NOT loop again. STOP. Research WHY. Try a fundamentally different approach.
- Max 2 re-audit cycles per gate before escalating to Austin.
- Opus tells Sonnet HOW to fix — Sonnet does the fix. Opus does NOT rewrite code (unless it's a trivial one-liner).
Phase 5: Stage 2 — GitHub PR Airlock (requires Austin approval)
Only after ALL Stage 1 gates PASS (or Austin-approved exceptions):
- Commit to feature branch (pre-commit hook fires semgrep as first-line defense)
- Push branch → open PR (Austin must explicitly approve — rule 00, no public actions without approval)
- GitHub Actions triggers:
- Remote semgrep scan (full repo, not just changed files)
- CodeRabbit automated PR review (fresh LLM context, uncontaminated)
- Address PR review comments
- Austin reviews → Austin merges to main
- Main branch = verified master export. Agent never has direct write access.
- All repos PRIVATE unless Austin explicitly approves public.
Phase 6: Logging
Update memory/.harness/dispatch_log.jsonl:
{
"task_id": "TASK-{n}",
"stage1_verdict": "PASS|FAIL",
"gates": {
"semgrep": "PASS|FAIL",
"coderabbit": "PASS|FAIL",
"code_review": "PASS|FAIL",
"security": "PASS|FAIL",
"clone_comparison": "PASS|FAIL"
},
"re_audit_count": 0,
"austin_exceptions": [],
"stage2_pr": "URL or pending",
"status": "complete|escalated"
}Constraints
- Max 2 concurrent agents at any time (1 executor + 1 auditor, or 2 auditors)
- Never run a second coding dispatch while audit is pending on the first
- All gates use INSTALLED PLUGINS — not raw MCP calls
- Sonnet executes. Opus audits and orchestrates. Opus does NOT write code.
- MCP = intelligence layer only. No MCP on the hot path.
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.

