Neo Agent Harness

Agent Harness Architect Skill

Trigger On

• The user asks to design or improve an AI agent development workflow.
• The user wants coding agents to be more reliable, safer, or easier to supervise.
• The user asks for AGENTS.md, skills, tests, CI, hooks, review loops, or project rules to be planned together.
• The task is about harness engineering, agent harnessability, feedback loops, or "humans on the loop".
• The user wants to design scheduled automations, cron-driven agent loops, or recurring agent tasks.
• The user wants multiple agents to work in parallel and needs an isolation strategy (worktree isolation).
• The user wants to design maker/checker separation (generation and verification by different agents).
• The user wants to design external memory or cross-conversation state persistence for agents.
• The user asks how to evolve from a harness to loop-driven development.

Core Principle

Treat agent-assisted development as a controlled engineering system. Do not only improve prompts; design the guides, sensors, verification steps, and human decision points that let agents work with higher confidence.

When the task involves automations, parallel agents, or continuous loops, extend the design to cover loop architecture: the scheduling, isolation, separation, integration, and state layers that let the harness run itself.

Use this skill for planning first. Do not modify files unless the user explicitly asks for implementation after the harness plan is clear.

Perceive

1. Inspect the repository before asking questions:

• Project instructions: AGENTS.md, CLAUDE.md, GEMINI.md, .github/copilot-instructions.md.
• Skill or prompt assets: skills/, .codex/skills/, .claude/skills/, .github/skills/.
• Validation commands: package.json, pyproject.toml, Makefile, CI workflow files, build scripts.
• Safety and governance: hooks, linters, formatters, secret scanners, dependency scanners.
• Existing documentation: README, architecture docs, ADRs, testing docs, contribution docs.
• Agent definitions: .codex/agents/, .claude/agents/, subagent configs, agent team definitions.
• Automation and scheduling: cron configs, GitHub Actions workflows, hooks, /loop or /goal usage.
• State files: progress markdown, task boards, Linear integrations, cross-conversation state.

1. Identify the project type, primary languages, current test surface, CI status, and release/deploy path.
2. Separate discoverable repository facts from product or team preferences that require user confirmation.

Reason

Analyze the project through these dimensions:

1. Feedforward guides

• What should the agent know before editing?
• Examples: project rules, coding style, architecture boundaries, task decomposition, testing strategy, domain vocabulary, safe file ownership.

1. Feedback sensors

• What can check the agent's work after each change?
• Examples: typecheck, tests, lint, build, static analysis, security checks, architecture tests, review agents, smoke tests.

1. Control type

• Prefer computational controls for fast deterministic checks.
• Use inferential controls for semantic review, architecture judgment, test-quality review, and risk assessment.

1. Regulation category

• Maintainability: readability, duplication, complexity, style, testability.
• Architecture fitness: module boundaries, performance, observability, security, deployability.
• Behaviour: requirements, acceptance criteria, user journeys, fixtures, manual test points.

1. Human role

• Move human effort from repeated low-level correction to high-value decisions: scope, product fit, risk acceptance, architectural tradeoffs, and harness evolution.

1. Loop design (conditional: activate only when the task involves scheduled automations, parallel agents, or continuous loops)

• Automations: which tasks suit scheduled triggers? Frequency, trigger conditions, result routing (triage inbox vs auto-process).
• Worktrees: how to isolate parallel agents? Independent branches and working directories needed?
• Maker/checker separation: which steps need generation and verification by different agents? (For sub-agent definition and implementation, use the neo-sub-agent skill.)
• Connectors: which external tools does the loop need to reach? (issue tracker, CI, Slack, staging API, database)
• State: how to persist cross-conversation progress? Format (markdown / board / Linear)? Who updates it?
• Loop risks: assess comprehension debt, cognitive surrender, and unattended verification risk levels.

For detailed patterns and examples, read [reference/harness-patterns.md](reference/harness-patterns.md) when the task needs a full harness design, maturity model, or improvement roadmap. For the complete source article synthesis behind this skill, read [reference/agent-harness-engineering.md](reference/agent-harness-engineering.md) only when deeper conceptual background is needed. For loop engineering patterns, the five loop primitives, risk model, and maturity guidance, read [reference/loop-engineering.md](reference/loop-engineering.md) when the task involves automations, parallel agents, maker/checker separation, or loop-driven development.

Act

Output in Traditional Chinese (Taiwan). Use this structure:

1. 現況盤點

• Summarize the repository facts discovered.
• Mention the current guides, sensors, and missing signals.
• If loop-relevant infrastructure exists (automations, agent definitions, state files), include it here.

2. Harnessability 評估

• Rate the current harnessability as 低, 中, or 高.
• Explain the rating with concrete evidence from the repository.

3. Feedforward Guides 設計

• List the rules, docs, skills, templates, or examples agents should receive before work starts.
• Mark each item as existing, needs update, or missing.

4. Feedback Sensors 設計

• List fast local checks, CI checks, security checks, semantic reviews, and manual checks.
• Distinguish computational from inferential checks.

5. 開發前改善清單

• Prioritize improvements as P0, P1, and P2.
• P0 must focus on changes that reduce repeated agent mistakes or prevent high-risk failures.

5.5 Loop 設計（條件式：僅當任務涉及 loop 時輸出）

• List tasks suited for scheduled automation, with suggested frequency.
• Describe the isolation strategy for parallel agents (worktree / branch / container).
• Identify which steps need maker/checker separation and their verification criteria.
• List required connectors and external integrations.
• Design the state persistence scheme and update responsibilities.
• Assess loop risks: comprehension debt, cognitive surrender, unattended verification, and propose safeguards.

6. 人類決策點

• State where humans should stay on the loop.
• Identify decisions that should not be delegated fully to agents.
• When loop design is involved, assess these three specific risks:
• Verification responsibility: error accumulation when the loop runs unattended.
• Comprehension debt: the faster the loop produces code, the wider the understanding gap.
• Cognitive surrender: tendency to stop having opinions when the loop runs itself.
• Clearly mark which loop stages still require human intervention (scope decisions, risk acceptance, architectural tradeoffs).

7. 驗證方式

• Provide exact commands or review steps when discoverable.
• If a command is unknown, state the missing fact instead of inventing one.

Constraints

• Do not treat AI-generated tests as sufficient proof of behaviour correctness.
• Do not replace deterministic tooling with LLM judgment when a fast tool can check the same thing.
• Do not recommend broad automation before the project has reliable local validation commands.
• Do not propose fully autonomous changes for security, compliance, production deploys, or product-scope decisions.
• Keep the output actionable and tied to repository evidence.
• Do not recommend loop-driven automations for projects that lack reliable local validation commands and stable CI.
• When designing loops, explicitly assess comprehension debt, cognitive surrender, and unattended verification risks.
• For sub-agent design and implementation details, defer to the neo-sub-agent skill to avoid responsibility overlap.
• Mark loop engineering concepts as emerging practice, not established best practice.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Benknightdark
• Source: Benknightdark/neo-skills
• License: MIT
• Homepage: https://neo-blog-iota.vercel.app/

Install and usage instructions live in the source repository linked above.