@moon791017/neo-skills 1.1.21 → 1.1.22
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/AGENTS.md +47 -67
- package/README.md +2 -30
- package/package.json +1 -1
- package/skills/neo-harness/SKILL.md +75 -0
- package/skills/neo-harness/assets/AGENTS.md.template +63 -0
- package/skills/neo-harness/references/execution-protocol.md +47 -0
- package/skills/neo-harness/references/harness-assessment.md +67 -0
- package/skills/neo-harness/references/orchestration-patterns.md +46 -0
- package/skills/neo-harness/scripts/generate-agents-md.py +266 -0
- package/skills/neo-agent-harness/SKILL.md +0 -127
- package/skills/neo-agent-harness/reference/agent-harness-engineering.md +0 -343
- package/skills/neo-agent-harness/reference/harness-patterns.md +0 -194
- package/skills/neo-agent-harness/reference/loop-engineering.md +0 -149
- package/skills/neo-agent-protocol/SKILL.md +0 -68
- package/skills/neo-agent-protocol/reference/agent-execution-rules.md +0 -58
- package/skills/neo-agentic-design/SKILL.md +0 -89
- package/skills/neo-agentic-design/evals/eval_queries.json +0 -58
- package/skills/neo-agentic-design/evals/evals.json +0 -27
- package/skills/neo-agentic-design/references/advanced-safety.md +0 -158
- package/skills/neo-agentic-design/references/base-workflows.md +0 -219
- package/skills/neo-agentic-design/references/resilience-hitl.md +0 -105
- package/skills/neo-agentic-design/references/system-components.md +0 -93
package/AGENTS.md
CHANGED
|
@@ -1,82 +1,62 @@
|
|
|
1
|
-
#
|
|
1
|
+
# neo-skills AGENTS.md
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
---
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
## 1. Project Overview
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
- **Primary Technology Stack**: `Node.js / JavaScript`
|
|
8
|
+
- **Coding & Architectural Conventions**:
|
|
9
|
+
- Follow modular architecture and existing code formatting.
|
|
10
|
+
- Inspect existing implementation files before creating new utilities.
|
|
11
|
+
- Do NOT introduce unrequested third-party dependencies.
|
|
8
12
|
|
|
9
|
-
|
|
10
|
-
- Commit 訊息必須使用繁體中文(台灣)。
|
|
11
|
-
- 需要事實判斷時,只根據使用者提供內容、目前 worktree、專案檔案或已驗證來源回答;資料不足時直接說明不能確定。
|
|
13
|
+
---
|
|
12
14
|
|
|
13
|
-
##
|
|
15
|
+
## 2. Commands
|
|
14
16
|
|
|
15
|
-
|
|
16
|
-
| :--- | :--- |
|
|
17
|
-
| `skills/<skill-name>/SKILL.md` | 每個技能的主要入口;第一行必須是 `---` frontmatter。 |
|
|
18
|
-
| `skills/<skill-name>/references/` 或 `reference/` | 深度知識、檢核表、反模式、設計規範;只在需要時載入。 |
|
|
19
|
-
| `skills/<skill-name>/assets/` | 文件、程式碼或設定檔範本。 |
|
|
20
|
-
| `skills/<skill-name>/scripts/` | 可重複執行的非互動式輔助腳本。 |
|
|
21
|
-
| `skills/<skill-name>/evals/` | 觸發率與輸出品質評估資料。 |
|
|
22
|
-
| `bin/` | 安裝 CLI 與共用工具。 |
|
|
23
|
-
| `scripts/check-skills-syntax.py` | 技能 frontmatter 與基本結構驗證工具。 |
|
|
24
|
-
| `test/*.test.js` | Node.js 測試。 |
|
|
17
|
+
List exact command lines used for project development, testing, linting, typechecking, and building:
|
|
25
18
|
|
|
26
|
-
|
|
19
|
+
| Command Type | Exact Command Line | Purpose / Scope |
|
|
20
|
+
| :--- | :--- | :--- |
|
|
21
|
+
| **Unit / Integration Tests** | `npm test` | Verify behavioral correctness |
|
|
22
|
+
| **Skill Syntax Check** | `python3 scripts/check-skills-syntax.py` | Verify skill markdown and frontmatter syntax |
|
|
23
|
+
| **Build Check** | `npm run build` | Confirm clean compilation |
|
|
27
24
|
|
|
28
|
-
|
|
29
|
-
- `npm test`:執行 Node.js 測試。
|
|
30
|
-
- `python3 scripts/check-skills-syntax.py --dir skills`:驗證所有技能目錄與 `SKILL.md` frontmatter。
|
|
31
|
-
- `node bin/install-skills.js`:將技能同步到 Antigravity CLI 全域技能目錄。
|
|
25
|
+
---
|
|
32
26
|
|
|
33
|
-
##
|
|
27
|
+
## 3. Workflow
|
|
34
28
|
|
|
35
|
-
|
|
29
|
+
The development workflow strictly follows this 9-stage closed loop:
|
|
36
30
|
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
31
|
+
```mermaid
|
|
32
|
+
graph TD
|
|
33
|
+
Step1[1. Perceive Task] --> Step2[2. Establish Baseline]
|
|
34
|
+
Step2 --> Step3[3. Reproduce Problem]
|
|
35
|
+
Step3 --> Step4[4. Plan Edits]
|
|
36
|
+
Step4 --> Step5[5. Minimal Implementation]
|
|
37
|
+
Step5 --> Step6[6. Incremental Verification]
|
|
38
|
+
Step6 --> Step7[7. Self-Review]
|
|
39
|
+
Step7 -->|Fail| Step4
|
|
40
|
+
Step7 -->|Pass| Step9[9. Handoff upon Pass]
|
|
41
|
+
```
|
|
45
42
|
|
|
46
|
-
|
|
43
|
+
1. **Perceive Task**: Read project guidelines (`AGENTS.md`) and target source files to understand goals and constraints.
|
|
44
|
+
2. **Establish Baseline**: Run existing test and build commands to confirm the project is in a stable, passing state.
|
|
45
|
+
3. **Reproduce Problem**: Write or run test cases/verification steps that reliably reproduce the issue or requirement.
|
|
46
|
+
4. **Plan Edits**: Decompose the task into small, atomic edit plans to avoid large single-turn changes.
|
|
47
|
+
5. **Minimal Implementation**: Apply minimal code changes while preserving existing comments and public API contracts.
|
|
48
|
+
6. **Incremental Verification**: Run local test, lint, and build commands immediately after each edit.
|
|
49
|
+
7. **Self-Review**: Inspect diffs and execution logs; if checks fail, read full un-truncated error logs to find the root cause.
|
|
50
|
+
8. **Remediate on Failure**: If verification or self-review fails, return to "Plan Edits / Minimal Implementation" to adjust.
|
|
51
|
+
9. **Handoff upon Pass**: Once all verification sensors pass, present a concise report with empirical proof for handoff.
|
|
47
52
|
|
|
48
|
-
|
|
53
|
+
---
|
|
49
54
|
|
|
50
|
-
|
|
51
|
-
2. **stdout/stderr 分離**:stdout 只輸出可解析資料(JSON、CSV、TSV);診斷、進度與錯誤輸出到 stderr。
|
|
52
|
-
3. **可重試**:能支援 dry-run 或安全重跑時要提供;避免同一輸入造成不可預期副作用。
|
|
53
|
-
4. **PEP 723**:Python 腳本需放入 inline dependency block,方便 `uv run` 直接執行。
|
|
55
|
+
## 4. Forbidden Antipattern Redlines
|
|
54
56
|
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
## Commit 與 PR
|
|
63
|
-
|
|
64
|
-
- Commit 採 Conventional Commits 1.0.0:`<type>[optional scope]: <description>`。
|
|
65
|
-
- 常用 type:`feat`、`fix`、`docs`、`test`、`refactor`、`build`、`ci`、`chore`。
|
|
66
|
-
- Commit 主旨使用繁體中文(台灣),不要加句號。
|
|
67
|
-
- 不要加入 `Co-authored-by` 或任何 AI attribution trailer。
|
|
68
|
-
- 每個 commit 聚焦單一邏輯變更,不混入不相關修改。
|
|
69
|
-
- PR 說明需包含行為變更、已執行指令與相關 issue。
|
|
70
|
-
|
|
71
|
-
## 安全與內容
|
|
72
|
-
|
|
73
|
-
- 不提交 secret、token、sample credentials 或可被誤用的危險提示詞。
|
|
74
|
-
- 移除技能時,完整刪除目錄並同步清理 README、安裝文件與任何引用。
|
|
75
|
-
- 不確定某項外部規格是否仍正確時,不要把它寫成確定事實。
|
|
76
|
-
|
|
77
|
-
## Agent 工作流程
|
|
78
|
-
|
|
79
|
-
1. 先讀目前 worktree,不依賴記憶中的舊狀態。
|
|
80
|
-
2. 小步修改,保留使用者既有變更。
|
|
81
|
-
3. 文件、技能與驗證工具要互相對齊。
|
|
82
|
-
4. 完成後回報修改重點、已跑驗證,以及仍未處理的風險或待辦。
|
|
57
|
+
| Forbidden Action | Why It Is Prohibited | Required Behavior |
|
|
58
|
+
| :--- | :--- | :--- |
|
|
59
|
+
| **Silent Exception Swallowing** | Hides runtime failures and causes silent data corruption. | Let exceptions surface or handle explicitly with logging. |
|
|
60
|
+
| **Test Deletion / Suppression** | Forces builds to pass without fixing underlying bugs. | Fix root cause in source or update contract with justification. |
|
|
61
|
+
| **Hallucinated Signatures** | Invokes non-existent methods causing runtime crashes. | View symbol definition using search tools first. |
|
|
62
|
+
| **Unverified Completion Claim** | Misleads user regarding feature or bug state. | Run test/build commands and present log proof. |
|
package/README.md
CHANGED
|
@@ -37,8 +37,7 @@
|
|
|
37
37
|
|
|
38
38
|
| 類別 | Skill | 使用時機 |
|
|
39
39
|
| :--- | :--- | :--- |
|
|
40
|
-
| Agent 治理 | `neo-
|
|
41
|
-
| Agent 治理 | `neo-agent-protocol` | 當 AI Agent 執行開發、重構、除錯或架構任務時,強制實施嚴格 harness 原則、自我驗證關卡、非破壞性編輯、上下文崩潰防禦與 Human-in-the-loop 邊界。 |
|
|
40
|
+
| Agent 治理 | `neo-harness` | 掃描專案環境,自動產生或升級專屬且合規的 AGENTS.md 檔,整合 Harness 評估、閉環 Workflow 與編排架構。 |
|
|
42
41
|
| DevOps | `neo-azure-pipelines` | 建立、審查、除錯或現代化 Azure Pipelines YAML,尤其是 .NET build、Azure App Service 或 IIS 部署。 |
|
|
43
42
|
| 需求釐清 | `neo-clarification` | 將模糊、情緒化、片段式、截圖式需求轉成規格、驗收條件或釐清問題。 |
|
|
44
43
|
| Code Review | `neo-code-review` | 進行程式碼審查、PR/diff review、bug 風險掃描、安全性、效能或可維護性檢查。 |
|
|
@@ -60,7 +59,6 @@
|
|
|
60
59
|
| TypeScript | `neo-typescript` | 處理 TypeScript、tsconfig、strict mode、泛型、conditional/mapped/template literal types、ESM/CJS 與 runtime boundaries。 |
|
|
61
60
|
| Vue | `neo-vue` | 建置、除錯、重構或審查 Vue 3、SFC、Composition API、Pinia、Vue Router、Vite 與 Vue+TypeScript。 |
|
|
62
61
|
| Agent 架構 | `neo-sub-agent` | 設計、建立、審查或轉換 sub-agent、custom agent、worker/reviewer/planner agent 或 multi-agent workflow。 |
|
|
63
|
-
| Agent 架構 | `neo-agentic-design` | 設計、評估或實作 Agent 工作流、提示詞鏈、路由、規劃、反思、多 Agent 協作與記憶體管理等框架無關模式。 |
|
|
64
62
|
| 技能開發 | `generate-skill` | 建立、更新、審查或最佳化 Agent Skill,包含規格、觸發描述、延伸資源、評估資料與設計模式。 |
|
|
65
63
|
| 可觀測性 | `neo-opentelemetry` | 解釋 OpenTelemetry 概念、規劃或審查 Collector 架構與設定、處理維運排障、安全、零程式 instrumentation 及相容性遷移。 |
|
|
66
64
|
| 文字潤飾 | `neo-stop-slop` | 去除繁中或英文中的 AI 腔、贅詞、公式化句式,支援文件、註解、commit message 與 PR 說明。 |
|
|
@@ -153,33 +151,7 @@ npx -p @moon791017/neo-skills install-system-instructions \
|
|
|
153
151
|
| 設計乾淨架構 | `neo-clean-architecture` | `幫我用 Clean Architecture 設計訂單管理模組` |
|
|
154
152
|
| 寫 TypeScript 型別 | `neo-typescript` | `幫我設計這個 API response 的泛型型別` |
|
|
155
153
|
| 建 Vue 3 元件 | `neo-vue` | `幫我重構這個 SFC,避免響應式踩坑` |
|
|
156
|
-
|
|
|
157
|
-
| 遵循 Agent 執行協議 | `neo-agent-protocol` | `請按照 neo-agent-protocol 執行這項開發任務` |
|
|
154
|
+
| 建立 Agent 治理 | `neo-harness` | `幫我針對這個專案評估並產生 AGENTS.md` |
|
|
158
155
|
| 建立 sub-agent | `neo-sub-agent` | `幫我新增一個 Codex code-reviewer sub agent` |
|
|
159
|
-
| 設計 Agent 編排架構 | `neo-agentic-design` | `幫我設計一個多 Agent 客服系統的拓撲結構與重試機制` |
|
|
160
156
|
| 規劃 OpenTelemetry | `neo-opentelemetry` | `幫我審查 Collector 架構、韌性、安全與零程式觀測方案` |
|
|
161
157
|
| 去掉 AI 腔 | `neo-stop-slop` | `把這段 PR 說明改得自然、直接一點` |
|
|
162
|
-
|
|
163
|
-
## 開發
|
|
164
|
-
|
|
165
|
-
```bash
|
|
166
|
-
npm install
|
|
167
|
-
npm test
|
|
168
|
-
python3 scripts/check-skills-syntax.py --dir skills
|
|
169
|
-
```
|
|
170
|
-
|
|
171
|
-
## 維護技能
|
|
172
|
-
|
|
173
|
-
新增或修改 skill 時,請同步檢查:
|
|
174
|
-
|
|
175
|
-
1. `SKILL.md` 第一行是 `---`。
|
|
176
|
-
2. frontmatter 有 `name` 與觸發導向的 `description`。
|
|
177
|
-
3. `name` 與資料夾名稱一致。
|
|
178
|
-
4. 深度內容放進 `references/` 或 `reference/`,範本放進 `assets/` 或 `templates/`,可執行流程放進 `scripts/`。
|
|
179
|
-
5. 腳本必須非互動式,stdout 只輸出可解析資料,診斷輸出到 stderr。
|
|
180
|
-
6. README 的技能清單與實際 `skills/` 內容一致。
|
|
181
|
-
7. 執行 `python3 scripts/check-skills-syntax.py --dir skills` 與 `npm test`。
|
|
182
|
-
|
|
183
|
-
## License
|
|
184
|
-
|
|
185
|
-
MIT
|
package/package.json
CHANGED
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: neo-harness
|
|
3
|
+
description: >
|
|
4
|
+
Use this skill when you need to inspect a target project codebase and generate or improve a tailored,
|
|
5
|
+
comprehensive AGENTS.md file (Harness Workflow Specification) that enforces strict AI agent
|
|
6
|
+
harness rules, feedback sensors, execution SOP, orchestration topologies, and safety redlines.
|
|
7
|
+
Supports non-interactive script execution via scripts/generate-agents-md.py.
|
|
8
|
+
The generated AGENTS.md MUST NOT exceed 32 KiB in size.
|
|
9
|
+
license: MIT
|
|
10
|
+
metadata:
|
|
11
|
+
version: "1.0.0"
|
|
12
|
+
type: "unified-harness-generator"
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
# Unified Agent Harness Architect & Workflow Generator
|
|
16
|
+
|
|
17
|
+
This skill integrates three core Agent engineering domains (**Harness Assessment**, **Execution Protocol**, and **Orchestration Architecture**) to analyze a target project and generate a tailored, strict `AGENTS.md` file (Harness Workflow Specification).
|
|
18
|
+
|
|
19
|
+
## Core Principle
|
|
20
|
+
|
|
21
|
+
```text
|
|
22
|
+
Agent = Model (Reasoning & Generation) + Harness (Guides + Sensors + Gates + Topologies)
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
The generated `AGENTS.md` acts as the single source of truth governing all AI Agents operating in the project.
|
|
26
|
+
|
|
27
|
+
> [!IMPORTANT]
|
|
28
|
+
> **Size Constraint**: The generated `AGENTS.md` MUST NOT exceed 32 KiB (32,768 bytes) to prevent token pollution in session context windows.
|
|
29
|
+
|
|
30
|
+
---
|
|
31
|
+
|
|
32
|
+
## Quick Automation (Non-Interactive Generator Script)
|
|
33
|
+
|
|
34
|
+
To quickly analyze a repository and generate or preview an `AGENTS.md` file, run the non-interactive script:
|
|
35
|
+
|
|
36
|
+
```bash
|
|
37
|
+
# Preview generated content (dry-run)
|
|
38
|
+
python3 skills/neo-harness/scripts/generate-agents-md.py --target-dir /path/to/repo --dry-run
|
|
39
|
+
|
|
40
|
+
# Generate AGENTS.md directly in target repository
|
|
41
|
+
python3 skills/neo-harness/scripts/generate-agents-md.py --target-dir /path/to/repo --force
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
## Workflow SOP
|
|
47
|
+
|
|
48
|
+
### Step 1 — Perceive Target Repository
|
|
49
|
+
1. Inspect project root and structure manually or via `scripts/generate-agents-md.py`:
|
|
50
|
+
- Configuration files: `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `Makefile`, etc.
|
|
51
|
+
- Build, lint, and test toolchains.
|
|
52
|
+
- Existing guidelines: `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, README.
|
|
53
|
+
- CI workflows: `.github/workflows/`, GitLab CI, etc.
|
|
54
|
+
2. Identify primary languages, test suites, and fast local feedback sensors.
|
|
55
|
+
|
|
56
|
+
### Step 2 — Reason & Synthesize Harness Rules
|
|
57
|
+
Load detailed reference knowledge as needed:
|
|
58
|
+
* **Harness Assessment & Sensors**: Read [references/harness-assessment.md](references/harness-assessment.md) to rate harnessability and define computational vs. inferential sensors.
|
|
59
|
+
* **Execution Protocol & SOP**: Read [references/execution-protocol.md](references/execution-protocol.md) to enforce the 5 Harness Laws, dual-loop SOP, zero-fake pass, and antipattern rules.
|
|
60
|
+
* **Orchestration Topologies**: Read [references/orchestration-patterns.md](references/orchestration-patterns.md) to select appropriate routing, chaining, or human-in-the-loop (HITL) gates.
|
|
61
|
+
|
|
62
|
+
### Step 3 — Generate `AGENTS.md`
|
|
63
|
+
Use `scripts/generate-agents-md.py` or [assets/AGENTS.md.template](assets/AGENTS.md.template) as the baseline template. Populate it with discovered project facts:
|
|
64
|
+
1. **Feedforward Guides**: Exact coding styles, module boundaries, and domain conventions.
|
|
65
|
+
2. **Deterministic Feedback Sensors**: Exact one-click test/lint/build commands.
|
|
66
|
+
3. **The 5 Agent Harness Laws**: Mandatory execution principles.
|
|
67
|
+
4. **Dual Closed-Loop Execution SOP**: Perceive ➔ Execute ➔ Sense ➔ Remediate.
|
|
68
|
+
5. **Forbidden Antipatterns**: Strict redlines (no silent exception swallowing, no test deletion, no hallucinated signatures).
|
|
69
|
+
6. **Human Decision Points & Safety Redlines**: Explicit boundaries requiring human approval.
|
|
70
|
+
|
|
71
|
+
### Step 4 — Verify Size & Quality Gate
|
|
72
|
+
1. Check the file size of the generated `AGENTS.md`:
|
|
73
|
+
- Must be `<= 32,768 bytes`.
|
|
74
|
+
- If over 32 KiB, prune redundant descriptions or move extended reference docs to separate files under `.agents/` or `docs/`.
|
|
75
|
+
2. Validate syntax and formatting.
|
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
# {{PROJECT_NAME}} AGENTS.md
|
|
2
|
+
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
## 1. Project Overview
|
|
6
|
+
|
|
7
|
+
- **Primary Technology Stack**: `{{TECH_STACK}}`
|
|
8
|
+
- **Coding & Architectural Conventions**:
|
|
9
|
+
- Follow modular architecture and existing code formatting.
|
|
10
|
+
- Inspect existing implementation files before creating new utilities.
|
|
11
|
+
- Do NOT introduce unrequested third-party dependencies.
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## 2. Commands
|
|
16
|
+
|
|
17
|
+
List exact command lines used for project development, testing, linting, typechecking, and building:
|
|
18
|
+
|
|
19
|
+
| Command Type | Exact Command Line | Purpose / Scope |
|
|
20
|
+
| :--- | :--- | :--- |
|
|
21
|
+
| **Unit / Integration Tests** | `{{TEST_COMMAND}}` | Verify behavioral correctness |
|
|
22
|
+
| **Type Check** | `{{TYPECHECK_COMMAND}}` | Verify static type contracts |
|
|
23
|
+
| **Lint & Format** | `{{LINT_COMMAND}}` | Enforce code style and syntax rules |
|
|
24
|
+
| **Build Check** | `{{BUILD_COMMAND}}` | Confirm clean compilation |
|
|
25
|
+
|
|
26
|
+
---
|
|
27
|
+
|
|
28
|
+
## 3. Workflow
|
|
29
|
+
|
|
30
|
+
The development workflow strictly follows this 9-stage closed loop:
|
|
31
|
+
|
|
32
|
+
```mermaid
|
|
33
|
+
graph TD
|
|
34
|
+
Step1[1. Perceive Task] --> Step2[2. Establish Baseline]
|
|
35
|
+
Step2 --> Step3[3. Reproduce Problem]
|
|
36
|
+
Step3 --> Step4[4. Plan Edits]
|
|
37
|
+
Step4 --> Step5[5. Minimal Implementation]
|
|
38
|
+
Step5 --> Step6[6. Incremental Verification]
|
|
39
|
+
Step6 --> Step7[7. Self-Review]
|
|
40
|
+
Step7 -->|Fail| Step4
|
|
41
|
+
Step7 -->|Pass| Step9[9. Handoff upon Pass]
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
1. **Perceive Task**: Read project guidelines (`AGENTS.md`) and target source files to understand goals and constraints.
|
|
45
|
+
2. **Establish Baseline**: Run existing test and build commands to confirm the project is in a stable, passing state.
|
|
46
|
+
3. **Reproduce Problem**: Write or run test cases/verification steps that reliably reproduce the issue or requirement.
|
|
47
|
+
4. **Plan Edits**: Decompose the task into small, atomic edit plans to avoid large single-turn changes.
|
|
48
|
+
5. **Minimal Implementation**: Apply minimal code changes while preserving existing comments and public API contracts.
|
|
49
|
+
6. **Incremental Verification**: Run local test, lint, and build commands immediately after each edit.
|
|
50
|
+
7. **Self-Review**: Inspect diffs and execution logs; if checks fail, read full un-truncated error logs to find the root cause.
|
|
51
|
+
8. **Remediate on Failure**: If verification or self-review fails, return to "Plan Edits / Minimal Implementation" to adjust.
|
|
52
|
+
9. **Handoff upon Pass**: Once all verification sensors pass, present a concise report with empirical proof for handoff.
|
|
53
|
+
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
## 4. Forbidden Antipattern Redlines
|
|
57
|
+
|
|
58
|
+
| Forbidden Action | Why It Is Prohibited | Required Behavior |
|
|
59
|
+
| :--- | :--- | :--- |
|
|
60
|
+
| **Silent Exception Swallowing** | Hides runtime failures and causes silent data corruption. | Let exceptions surface or handle explicitly with logging. |
|
|
61
|
+
| **Test Deletion / Suppression** | Forces builds to pass without fixing underlying bugs. | Fix root cause in source or update contract with justification. |
|
|
62
|
+
| **Hallucinated Signatures** | Invokes non-existent methods causing runtime crashes. | View symbol definition using search tools first. |
|
|
63
|
+
| **Unverified Completion Claim** | Misleads user regarding feature or bug state. | Run test/build commands and present log proof. |
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
# Agent Execution Protocol & Safety Redlines
|
|
2
|
+
|
|
3
|
+
This reference provides execution laws, closed-loop SOPs, and antipattern rules for neo-harness.
|
|
4
|
+
|
|
5
|
+
## The 5 Agent Harness Laws
|
|
6
|
+
|
|
7
|
+
### Law 1: Feedforward First (Read Before Modify)
|
|
8
|
+
- Read `AGENTS.md` and target source files before making edits.
|
|
9
|
+
- Never guess API signatures, struct fields, or database schemas. Inspect authoritative files first.
|
|
10
|
+
|
|
11
|
+
### Law 2: Deterministic Sensors & Verification Gates
|
|
12
|
+
- Execute test/lint/build commands after every edit. Never declare completion without log proof.
|
|
13
|
+
- Zero-fake pass: Never patch errors by swallowing exceptions, returning dummy fallbacks, commenting out broken assertions, or deleting failing unit tests.
|
|
14
|
+
|
|
15
|
+
### Law 3: Dual Closed-Loop Execution Protocol
|
|
16
|
+
- **Online Execution Loop**: Perceive ➔ Execute (Atomic Diff) ➔ Sense (Fast Local Check) ➔ Remediate (Fix using Log Evidence).
|
|
17
|
+
- **Offline Evolution Loop**: Convert recurring agent errors into permanent linter rules or test cases.
|
|
18
|
+
|
|
19
|
+
### Law 4: Context Collapse Defense & State Persistence
|
|
20
|
+
- Maintain disk-based progress files (`Plan.md` or `Progress.md`) for long-horizon or multi-file tasks.
|
|
21
|
+
- Keep single-turn code diffs small and targeted.
|
|
22
|
+
|
|
23
|
+
### Law 5: Human Decision Points & Safety Redlines
|
|
24
|
+
Immediately pause and request human intervention when encountering:
|
|
25
|
+
- Destructive file/database operations or git history resets.
|
|
26
|
+
- Secret/credential exposures or modifications.
|
|
27
|
+
- High-risk production deployments, compliance, or architecture trade-offs.
|
|
28
|
+
|
|
29
|
+
---
|
|
30
|
+
|
|
31
|
+
## High-Risk Antipattern Redlines
|
|
32
|
+
|
|
33
|
+
| Forbidden Antipattern | Description & Hazard | Mandatory Alternative |
|
|
34
|
+
| :--- | :--- | :--- |
|
|
35
|
+
| **Silent Exception Swallowing** | Wrapping errors in empty `try/catch` or returning empty default values. | Surface errors or handle explicitly with verified logging. |
|
|
36
|
+
| **Test Deletion / Suppression** | Deleting or commenting out failing test assertions to pass CI. | Fix root cause in source code or update test contract with justification. |
|
|
37
|
+
| **Hallucinated Signatures** | Calling functions without reading their definition file. | View target symbol definition file first using code search. |
|
|
38
|
+
| **Unverified Completion Claim** | Telling the user a task is fixed without running verification commands. | Run exact test/build commands and present log proof. |
|
|
39
|
+
|
|
40
|
+
---
|
|
41
|
+
|
|
42
|
+
## Log-Driven Diagnostic Checklist
|
|
43
|
+
|
|
44
|
+
1. When a command fails, fetch and read the complete, un-truncated error log.
|
|
45
|
+
2. Identify the exact file line number and root cause exception message.
|
|
46
|
+
3. Formulate a targeted fix addressing the root cause, not just masking the symptom.
|
|
47
|
+
4. Re-run verification commands to confirm the fix works cleanly.
|
|
@@ -0,0 +1,67 @@
|
|
|
1
|
+
# Harness Assessment & Sensor Design
|
|
2
|
+
|
|
3
|
+
This reference provides harness evaluation, sensor classification, and maturity rating guidance for neo-harness.
|
|
4
|
+
|
|
5
|
+
## Core Model
|
|
6
|
+
|
|
7
|
+
An Agent Harness is the complete external control system wrapped around an LLM model:
|
|
8
|
+
|
|
9
|
+
```text
|
|
10
|
+
Agent = Model + Harness
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
A robust harness fulfills two primary objectives:
|
|
14
|
+
1. **Increase First-Time Accuracy**: Provide clear feedforward guidance before code generation.
|
|
15
|
+
2. **Enable Autonomous Remediation**: Provide fast, deterministic feedback sensors so the agent self-corrects before human review.
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
|
|
19
|
+
## 1. Feedforward Guides (Before Action)
|
|
20
|
+
|
|
21
|
+
Feedforward controls shape agent output before any edits occur:
|
|
22
|
+
- Project instruction files (`AGENTS.md`, `CLAUDE.md`, `GEMINI.md`).
|
|
23
|
+
- Coding style references, architecture documentation, module boundary maps.
|
|
24
|
+
- Task breakdown templates and domain vocabulary glossaries.
|
|
25
|
+
|
|
26
|
+
---
|
|
27
|
+
|
|
28
|
+
## 2. Feedback Sensors (After Action)
|
|
29
|
+
|
|
30
|
+
Feedback sensors evaluate generated code and provide correction signals.
|
|
31
|
+
|
|
32
|
+
### Computational Sensors (Fast & Deterministic)
|
|
33
|
+
Prefer computational sensors whenever available:
|
|
34
|
+
- **Type Checking**: `tsc`, `mypy`, `pyright`, `go vet`, `cargo check`.
|
|
35
|
+
- **Unit & Integration Tests**: `npm test`, `pytest`, `cargo test`, `go test`.
|
|
36
|
+
- **Linters & Formatters**: `eslint`, `flake8`, `ruff`, `prettier`.
|
|
37
|
+
- **Security & Dependency Scanners**: `npm audit`, `trivy`, secret scanners.
|
|
38
|
+
|
|
39
|
+
### Inferential Sensors (Semantic & Judgment)
|
|
40
|
+
Use inferential sensors when deterministic tools are insufficient:
|
|
41
|
+
- AI Code Reviews & LLM Judges.
|
|
42
|
+
- Architecture fitness reviews.
|
|
43
|
+
- Acceptance criteria verification.
|
|
44
|
+
|
|
45
|
+
---
|
|
46
|
+
|
|
47
|
+
## 3. Harnessability Maturity Model
|
|
48
|
+
|
|
49
|
+
Rate target repository harnessability as **Low**, **Medium**, or **High**:
|
|
50
|
+
|
|
51
|
+
| Rating | Characteristics | Required Actions |
|
|
52
|
+
| :--- | :--- | :--- |
|
|
53
|
+
| **Low (低)** | Missing test suites, no single-command test runner, ambiguous coding style, unconfigured linters. | Establish baseline test runners and lint commands before delegating multi-file agent tasks. |
|
|
54
|
+
| **Medium (中)** | Tests exist but run slowly; linters present but not enforced in CI; partial `AGENTS.md`. | Define exact fast-sensor commands in `AGENTS.md`; break tasks into atomic verifiable steps. |
|
|
55
|
+
| **High (高)** | Single-command fast test/lint/build runners; strict CI enforcement; clear module boundaries and explicit `AGENTS.md`. | Fully leverage autonomous closed-loop execution and scheduled/loop automations. |
|
|
56
|
+
|
|
57
|
+
---
|
|
58
|
+
|
|
59
|
+
## 4. Loop Primitives & State Persistence
|
|
60
|
+
|
|
61
|
+
When workflows extend beyond a single session:
|
|
62
|
+
1. **Automations**: Scheduled triggers for periodic maintenance or exploration.
|
|
63
|
+
2. **Worktrees**: Git worktree isolation for parallel agent executions.
|
|
64
|
+
3. **Skills**: Modularized domain knowledge in `SKILL.md`.
|
|
65
|
+
4. **Connectors**: External tools (CI, issue trackers, messaging).
|
|
66
|
+
5. **Sub-agents**: Separation of generation (Maker) and verification (Checker).
|
|
67
|
+
6. **State**: Disk-persisted progress tracking (`Plan.md`, `Progress.md`).
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
# LLM Orchestration Patterns & Topology Design
|
|
2
|
+
|
|
3
|
+
This reference provides LLM agent orchestration architectures and safety guardrails for neo-harness.
|
|
4
|
+
|
|
5
|
+
## Core Orchestration Patterns
|
|
6
|
+
|
|
7
|
+
### 1. Prompt Chaining
|
|
8
|
+
Decompose complex tasks into sequential, dependent sub-tasks. Output of Step A feeds into Step B.
|
|
9
|
+
|
|
10
|
+
### 2. Routing
|
|
11
|
+
Dynamically route requests to specialized sub-agents or tools based on classification or semantic input.
|
|
12
|
+
|
|
13
|
+
### 3. Parallelization
|
|
14
|
+
Run independent sub-tasks concurrently (e.g., section generation or multi-perspective reviews) and synthesize results.
|
|
15
|
+
|
|
16
|
+
### 4. Reflection & Self-Correction
|
|
17
|
+
Evaluate generated output against quality criteria or test feedback, then iterate.
|
|
18
|
+
> [!WARNING]
|
|
19
|
+
> Always enforce a maximum iteration limit (3–5 cycles) to prevent infinite loops.
|
|
20
|
+
|
|
21
|
+
### 5. Human-in-the-Loop (HITL) Gates
|
|
22
|
+
Insert explicit review checkpoints for high-risk operations (e.g., database schema migrations, external API calls, financial actions).
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## Standard Topology Diagram (Mermaid)
|
|
27
|
+
|
|
28
|
+
When documenting an Agent workflow in `AGENTS.md`, include a concise Mermaid topology:
|
|
29
|
+
|
|
30
|
+
```mermaid
|
|
31
|
+
graph TD
|
|
32
|
+
UserReq[User Request / Goal] --> Perceive[Perceive & Plan Step]
|
|
33
|
+
Perceive --> Execute[Atomic Code Edit]
|
|
34
|
+
Execute --> Sense{Local Sensor Check}
|
|
35
|
+
Sense -->|Pass| HITL{HITL Gate / Approval}
|
|
36
|
+
Sense -->|Fail| Remediate[Log-driven Self-Correction]
|
|
37
|
+
Remediate --> Execute
|
|
38
|
+
HITL -->|Approved| Done[Complete & Commit]
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
## Context Window Guardrails
|
|
44
|
+
|
|
45
|
+
1. **Context Pruning Protection**: Protect system prompts, project rules, and active task state from being pruned during context compaction.
|
|
46
|
+
2. **Size Enforcement**: Keep project instruction files (like `AGENTS.md`) under 32 KiB (32,768 bytes) to preserve prompt headroom.
|