AI Harness Engineering Template — guardrails, gates, and boundaries for AI coding agents. One-command install. Zero dependencies.
Agent
Part of harness
USE THIS WHEN symptoms keep recurring, layer boundaries blur, or changes ripple unexpectedly. ALWAYS invoke for structural diagnosis during /unstuck or major refactors. Finds root causes in design, not symptoms. Names tradeoffs explicitly.
Agent
Part of harness
USE THIS WHEN the team reaches quick consensus, before committing to a major design decision, or during /evolve and /unstuck. Challenges assumptions with "what if we're wrong?" scenarios. Always proposes at least one alternative.
Agent
Part of harness
USE THIS WHEN verifying implementation against a seed spec, running gates, or assessing AC compliance. ALWAYS invoke during /evaluate. Never fixes — only judges Pass/Fail with file:line evidence. Runs 3-stage verification (Mechanical → Semantic → Judgment).
Agent
Part of harness
USE THIS WHEN the official path is blocked, a deadline looms, or a temporary workaround is acceptable. ALWAYS invoke during /unstuck when standard approaches fail. Finds safe bypasses (monkey-patch, polyfill, shim) with explicit expiry dates.
Agent
Part of harness
USE PROACTIVELY whenever the user describes a new feature, vague requirement, or unclear goal. ALWAYS run BEFORE writing code or creating a seed spec. Asks Socratic questions to surface hidden assumptions. Never writes code or gives answers — only questions.
Agent
Part of harness
USE THIS as the planning half of pair programming during /run (PAIRMODE). Generates 3 solution plans per AC, selects optimal one, directs Driver. Never writes code directly. Based on PairCoder (ASE 2024) Navigator-Driver methodology. MUST be spawned as a background agent and communicated via SendMessage.
Agent
Part of harness
USE THIS WHEN defining domain terms, extracting entities/relationships from requirements, or unifying synonyms (e.g., "user" vs "member" vs "account"). ALWAYS invoke during /seed spec generation. Extracts Entity/Attribute/Relationship from interviews.
Agent
Part of harness
USE THIS WHEN a claim needs evidence, debugging requires history, or library/API behavior is uncertain. ALWAYS invoke before guessing — checks official docs, existing code patterns, git log/blame first. Evidence over speculation.
Agent
Part of harness
USE THIS WHEN crystallizing interview results into an immutable specification. ALWAYS invoke during /seed. Converts conversation + ontology into structured seed YAML with zero TODO/TBD tolerance. Blocks progress if any field is ambiguous.
Agent
Part of harness
USE THIS WHEN code feels over-engineered, scope seems to creep, or abstractions pile up. ALWAYS invoke during /evolve and /unstuck. Asks "is this needed for MVP?" on every feature. YAGNI-first — prefers convention over configuration.
Agent
Part of harness
USE THIS for independent test case generation during /run (PAIRMODE). Designs tests from AC and seed spec only — never reads implementation code. Prevents biased testing. Based on AgentCoder (2024) test separation methodology. MUST be spawned with isolation worktree to physically prevent source code access.
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: