agentleFS
0SxD0SxD/agent-skills-plugin-v01/skills/coding-harness/SKILL.md

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

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    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.

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
  1. Distinctive:

    Before dispatching ANY coding agent, Opus defines in writing:

    line 17
  2. Distinctive:

    Context files: ONLY the files Sonnet needs (minimum viable context — NOT the full CLAUDE.md or rules)

    line 23
  3. Distinctive:

    Worktree: If parallel work, assign a worktree via worktree-isolation skill

    line 24
  4. Very specific:

    Write pre-dispatch entry to memory/.harness/dispatch_log.jsonl:

    line 26
  5. Distinctive:

    Do NOT inject full CLAUDE.md, full rules, or full memory into the agent prompt.

    line 46
  6. Distinctive:

    Do NOT present results yet

    line 52
  7. Distinctive:

    No hallucinated APIs: If agent called a function that doesn't exist in the library → FAIL.

    line 67
  8. Distinctive:

    No partial implementations: If done criteria not met → FAIL.

    line 68
  9. Distinctive:

    If the same issue recurs after fix: do NOT loop again.

    line 96
  10. Distinctive:

    Only after ALL Stage 1 gates PASS (or Austin-approved exceptions):

    line 102
  11. Distinctive:

    Commit to feature branch (pre-commit hook fires semgrep as first-line defense)

    line 104
  12. Distinctive:

    Never run a second coding dispatch while audit is pending on the first

    line 138
  13. Distinctive:

    All gates use INSTALLED PLUGINS — not raw MCP calls

    line 139

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

  1. Task: What exactly needs to be built/changed (file path, function, behavior)
  2. Done criteria: Specific, testable conditions that define "done"
  3. Must-not: Explicit constraints (no custom wrappers, no novel patterns, use library X)
  4. Escalation: Conditions where Sonnet should STOP and report rather than proceed
  5. Context files: ONLY the files Sonnet needs (minimum viable context — NOT the full CLAUDE.md or rules)
  6. 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:

  1. Report to Austin: "Agent came back — running Stage 1 audit"
  2. Do NOT present results yet

Dispatch gate agents (each = fresh Sonnet, zero-context, reports to Opus):

GatePlugin(s)What it checks
1. Semgrepsemgrep pluginStatic analysis, security vulnerabilities
2. CodeRabbitcoderabbit pluginLogic issues, code quality, AI-generated code patterns
3. Code-reviewcode-review + pr-review-toolkit pluginsArchitecture, design, best practices
4. Securitysecurity-guidance pluginOWASP top 10, injection, XSS, secure-by-default
5. Clone comparisonManual diffCompare against reference clones in _repos/
6. Custom (conditional)Per Austin's criteriaAdditional 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 tried

Rules:

  1. A fix without a passing re-audit is NOT a pass.
  2. Both the executor AND the auditor must pass for work to be done.
  3. If the same issue recurs after fix: do NOT loop again. STOP. Research WHY. Try a fundamentally different approach.
  4. Max 2 re-audit cycles per gate before escalating to Austin.
  5. 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):

  1. Commit to feature branch (pre-commit hook fires semgrep as first-line defense)
  2. Push branch → open PR (Austin must explicitly approve — rule 00, no public actions without approval)
  3. GitHub Actions triggers:
    • Remote semgrep scan (full repo, not just changed files)
    • CodeRabbit automated PR review (fresh LLM context, uncontaminated)
  4. Address PR review comments
  5. Austin reviews → Austin merges to main
  6. Main branch = verified master export. Agent never has direct write access.
  7. 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.