# Harness Engineering Starter: A Universal Template for Building Agent Collaboration Rules

> A universal template repository for building "in-repository Agent collaboration rules", providing document skeletons and routing methods to help teams constrain Agents' work boundaries, execution paths, and delivery traces in real projects.

- 板块: [Openclaw Llm](https://www.zingnex.cn/en/forum/board/openclaw-llm)
- 发布时间: 2026-05-20T05:45:57.000Z
- 最近活动: 2026-05-20T05:50:12.768Z
- 热度: 150.9
- 关键词: Agent协作, 开发规范, 文档模板, AI工程, 仓库管理, 工作流, 架构文档, 人机协作
- 页面链接: https://www.zingnex.cn/en/forum/thread/harness-engineering-starter-agent
- Canonical: https://www.zingnex.cn/forum/thread/harness-engineering-starter-agent
- Markdown 来源: floors_fallback

---

## [Introduction] Harness Engineering Starter: A Universal Template for Building Agent Collaboration Rules

Harness Engineering Starter is a universal template repository for building "in-repository Agent collaboration rules". Its core goal is to help teams constrain Agents' work boundaries, execution paths, and delivery traces in real projects. It provides document skeletons and a routing system, with the core concept of "Rules as Interfaces". By clarifying collaboration contracts, it solves key issues in collaboration between Agents and human teams, addressing three major pain points in practice: context loss, inconsistent rules, and hard-to-trace outputs.

## Background: Rule Requirements After Agents Become Collaborative Members

As AI Agents shift from "auxiliary tools" to "collaborative members" in software development, how to make Agents work effectively and controllably has become a new problem. Human developers can synchronize cognition through meetings and documents, but Agents need clear rules to define work boundaries, execution paths, and delivery standards. Harness Engineering Starter is designed for this purpose; it does not provide specific tech stacks or coding standards, but rather document skeletons and a routing system to help teams establish Agent collaboration rules.

## Core Concept: Rules as Interfaces and Key Principles

The template's design philosophy is "Rules as Interfaces"—document rules define the collaboration contract between humans and Agents, just as APIs define system interaction contracts. Key principles include: 1. The template is not equivalent to facts; it only describes what should be defined. 2. Placeholders should be used after project confirmation. 3. Hierarchical management of project facts, domain rules, and generated outputs. 4. Tailor as needed: keep matching content and delete irrelevant parts.

## Document Architecture: Detailed Explanation of the Eight-Layer Routing System

The template provides a hierarchical document architecture with clear responsibilities for each layer:
1. AGENTS.md: Repository-level entry rules, the first stop for Agents entering the repository, defining basic behavioral guidelines, entry routing, and global constraints.
2. docs/WORKFLOW.md: Execution path selection, Agent operation manual (e.g., branch creation, PR submission, code review standards).
3. docs/ARCHITECTURE.md: System structure facts; Agents must read this before executing tasks to ensure changes comply with the architecture.
4. docs/guides/: General processes and templates (e.g., API document writing, code review processes).
5. docs/project/: Project hard constraints (tech stack, compatibility requirements, business background, etc.).
6. docs/rules/: Domain rules (API design, data access, exception handling, etc.).
7. docs/tasks/: Specific task descriptions and temporary documents.
8. docs/generated/: Agent-generated outputs, distinguished from manual documents.
There are also reference material layers (docs/references/) and template layers (docs/templates/) for reference.

## Usage: Four Steps from Template to Real Project

The template serves as a starting point, with usage steps as follows:
1. Replace core entry files: Modify AGENTS.md, docs/WORKFLOW.md, and docs/ARCHITECTURE.md to reflect the real project.
2. Complete project hard constraints: Supplement documents on tech stack, compatibility boundaries, business background, core terms, and domain facts.
3. Sink domain rules: Stabilize constraints and sink them to docs/guides/ (processes), docs/rules/ (domains), and .agents/skills/ (automated processes).
4. Tailor irrelevant parts: Delete or replace irrelevant template content to keep it concise and focused.

## Practical Value: Solving Three Major Pain Points in Agent Collaboration

The template solves three major pain points in Agent collaboration:
1. Context loss: Force Agents to read AGENTS.md and ARCHITECTURE.md before acting to ensure they have the necessary context.
2. Inconsistent rules: Standardize processes through WORKFLOW.md and guides to ensure Agents follow consistent rules.
3. Hard-to-trace outputs: The hierarchical architecture and generated directory conventions make Agent-generated outputs traceable and reviewable.

## Design Trade-offs and Future Outlook

The template clearly defines its scope of application:
**Not**: A fixed standard answer, a universal specification, or a placeholder repository replacing real project facts.
**Is**: A template skeleton, a tailorable routing system, and an entry point for shared context rules.
Future Outlook: As the role of Agents becomes more important, such templates will evolve into a rich ecosystem (best practice variants for different tech stacks, team sizes, and business domains). The template provides a minimal viable starting point to help teams immediately practice Agent collaboration.