agent-teams-simplify-and-harden

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Agent Teams Simplify & Harden

Agent团队：简化与强化

Install

安装

bash

npx skills add pskoett/pskoett-ai-skills/agent-teams-simplify-and-harden

A two-phase team loop that produces production-quality code: implement, then audit using simplify + harden passes, then fix audit findings, then re-audit, repeating until the codebase is solid or the loop cap is reached.

bash

npx skills add pskoett/pskoett-ai-skills/agent-teams-simplify-and-harden

这是一个分两阶段的团队循环工作流，可生成生产级质量的代码：实现，然后通过简化+强化步骤进行审计，接着修复审计发现的问题，再重新审计，重复此过程直到代码库稳定或达到循环上限。

When to Use

适用场景

Implementing multiple features from a spec or plan
Hardening a codebase after a batch of changes
Fixing a list of issues or gaps identified in a review
Any task touching 5+ files where quality gates matter

根据规格或计划实现多个功能
批量变更后强化代码库
修复评审中发现的一系列问题或漏洞
任何涉及5个以上文件且质量管控至关重要的任务

The Pattern

工作模式

┌──────────────────────────────────────────────────────────┐
│                  TEAM LEAD (you)                          │
│                                                           │
│  Phase 1: IMPLEMENT (+ document pass on fix rounds)       │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐                 │
│  │ impl-1   │ │ impl-2   │ │ impl-3   │  ...            │
│  │ (general │ │ (general │ │ (general │                 │
│  │ purpose) │ │ purpose) │ │ purpose) │                 │
│  └──────────┘ └──────────┘ └──────────┘                 │
│       │             │            │                        │
│       ▼             ▼            ▼                        │
│  ┌─────────────────────────────────────┐                 │
│  │  Verify: compile + tests            │                 │
│  └─────────────────────────────────────┘                 │
│       │                                                   │
│  Phase 2: SIMPLIFY & HARDEN AUDIT                         │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐                 │
│  │ simplify │ │ harden   │ │ spec     │  ...            │
│  │ auditor  │ │ auditor  │ │ auditor  │                 │
│  │ (Explore)│ │ (Explore)│ │ (Explore)│                 │
│  └──────────┘ └──────────┘ └──────────┘                 │
│       │             │            │                        │
│       ▼             ▼            ▼                        │
│  Exit conditions met?                                     │
│    YES → Produce summary. Ship it.                        │
│    NO  → back to Phase 1 with findings as tasks           │
│          (max 3 audit rounds)                             │
└──────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────┐
│                  团队负责人（你）                          │
│                                                           │
│  阶段1：实现（修复轮次中包含文档步骤）                     │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐                 │
│  │ impl-1   │ │ impl-2   │ │ impl-3   │  ...            │
│  │ （通用型）│ │ （通用型）│ │ （通用型）│                 │
│  └──────────┘ └──────────┘ └──────────┘                 │
│       │             │            │                        │
│       ▼             ▼            ▼                        │
│  ┌─────────────────────────────────────┐                 │
│  │  验证：编译 + 测试                  │                 │
│  └─────────────────────────────────────┘                 │
│       │                                                   │
│  阶段2：简化与强化审计                                     │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐                 │
│  │ simplify │ │ harden   │ │ spec     │  ...            │
│  │ auditor  │ │ auditor  │ │ auditor  │                 │
│  │ （探索型）│ │ （探索型）│ │ （探索型）│                 │
│  └──────────┘ └──────────┘ └──────────┘                 │
│       │             │            │                        │
│       ▼             ▼            ▼                        │
│  是否满足退出条件？                                       │
│    是 → 生成总结，交付上线。                              │
│    否 → 将发现的问题作为任务返回阶段1                     │
│          （最多3轮审计）                                   │
└──────────────────────────────────────────────────────────┘

Loop Limits and Exit Conditions

循环限制与退出条件

The loop exits when ANY of these are true:

Clean audit: All auditors report zero findings
Low-only round: All findings in a round are severity
```
low
```
-- fix them inline (team lead or a single impl agent) and exit without re-auditing
Loop cap reached: 3 audit rounds have completed. After the third round, fix remaining critical/high findings inline and exit. Log any unresolved medium/low findings in the final summary.

Budget guidance: Track the cumulative diff growth across rounds. If fix rounds have added more than 30% on top of the original implementation diff, tighten the scope: skip medium/low simplify findings and focus only on harden patches and spec gaps.

当满足以下任一条件时，循环将退出：

审计无问题：所有审计Agent报告零问题
仅低级别问题轮次：某一轮次中所有问题的严重程度均为
```
low
```
——由团队负责人或单个实现Agent直接修复后退出，无需重新审计
达到循环上限：已完成3轮审计。第三轮后，直接修复剩余的关键/高级别问题并退出，将未解决的中/低级别问题记录在最终总结中。

预算指导：跟踪各轮次的累计代码差异增长量。如果修复轮次的代码差异比原始实现增加了30%以上，需缩小范围：跳过中/低级别简化问题，仅专注于强化补丁和规格漏洞。

Step-by-Step Procedure

分步操作流程

1. Create the Team

1. 创建团队

TeamCreate:
  team_name: "<project>-harden"
  description: "Implement and harden <description>"

TeamCreate:
  team_name: "<项目名>-harden"
  description: "实现并强化<项目描述>"

2. Create Tasks

2. 创建任务

Break the work into discrete, parallelizable tasks. Each task should be independent enough for one agent to complete without blocking on others.

TaskCreate for each unit of work:
  subject: "Implement <specific thing>"
  description: "Detailed requirements, file paths, acceptance criteria"
  activeForm: "Implementing <thing>"

Set up dependencies if needed:

TaskUpdate: { taskId: "2", addBlockedBy: ["1"] }

将工作拆分为独立的、可并行的任务。每个任务应足够独立，单个Agent无需等待其他任务即可完成。

为每个工作单元创建TaskCreate:
  subject: "实现<具体功能>"
  description: "详细需求、文件路径、验收标准"
  activeForm: "正在实现<功能>"

如有需要，设置依赖关系：

TaskUpdate: { taskId: "2", addBlockedBy: ["1"] }

3. Spawn Implementation Agents

3. 生成实现Agent

Spawn

general-purpose

agents (they can read, write, and edit files). One per task or one per logical group. Run them in parallel.

Task tool (spawn teammate):
  subagent_type: general-purpose
  team_name: "<project>-harden"
  name: "impl-<area>"
  mode: bypassPermissions
  prompt: |
    You are an implementation agent on the <project>-harden team.
    Your name is impl-<area>.

    Check TaskList for your assigned tasks and complete them.
    After completing each task, mark it completed and check for more.

    Quality gates:
    - Code must compile cleanly (substitute your project's compile
      command, e.g. bunx tsc --noEmit, cargo build, go build ./...)
    - Tests must pass (substitute your project's test command,
      e.g. bun test, pytest, go test ./...)
    - Follow existing code patterns and conventions

    When all your tasks are done, notify the team lead.

生成

general-purpose

（通用型）Agent（具备读写和编辑文件的权限）。每个任务或每个逻辑组分配一个Agent，并行运行。

任务工具（生成团队成员）:
  subagent_type: general-purpose
  team_name: "<项目名>-harden"
  name: "impl-<功能区域>"
  mode: bypassPermissions
  prompt: |
    你是<项目名>-harden团队的实现Agent。
    你的名称是impl-<功能区域>。

    查看TaskList获取你的分配任务并完成。
    完成每个任务后，标记为已完成并检查是否有更多任务。

    质量要求:
    - 代码必须编译无错误（替换为你的项目编译命令，例如 bunx tsc --noEmit, cargo build, go build ./...）
    - 测试必须全部通过（替换为你的项目测试命令，例如 bun test, pytest, go test ./...）
    - 遵循现有代码模式和规范

    完成所有任务后，通知团队负责人。

4. Wait for Implementation to Complete

4. 等待实现完成

Monitor agent messages. When all implementation agents report done:

Run compile/type checks to verify clean build
Run tests to verify all pass
If either fails, fix or assign fixes before proceeding

Before spawning auditors, collect the list of files modified in this session:

bash

git diff --name-only <base-branch>  # or: git diff --name-only HEAD~N

You will pass this file list to each auditor.

监控Agent消息。当所有实现Agent报告完成后：

运行编译/类型检查以验证构建无错误
运行测试以验证全部通过
若任一环节失败，先修复或分配修复任务，再继续

生成审计Agent前，收集本次会话中修改的文件列表：

bash

git diff --name-only <基准分支>  # 或: git diff --name-only HEAD~N

你需要将此文件列表传递给每个审计Agent。

5. Spawn Audit Agents

5. 生成审计Agent

Spawn

Explore

agents (read-only -- they cannot edit files, which prevents them from "fixing" issues silently). Each auditor covers a different concern using the Simplify & Harden methodology.

Recommended audit dimensions:

Auditor	Focus	Mindset
simplify-auditor	Code clarity and unnecessary complexity	"Is there a simpler way to express this?"
harden-auditor	Security and resilience gaps	"If someone malicious saw this, what would they try?"
spec-auditor	Implementation vs spec/plan completeness	"Does the code match what was asked for?"

生成

Explore

（探索型）Agent（只读权限——无法编辑文件，避免其悄悄“修复”问题，从而失去审计的意义）。每个审计Agent使用“简化与强化”方法论，聚焦不同的关注点。

推荐审计维度：

审计Agent	聚焦方向	思考模式
simplify-auditor	代码清晰度与不必要的复杂度	“有没有更简单的表达方式？”
harden-auditor	安全与韧性漏洞	“如果恶意人员看到这段代码，会尝试什么攻击？”
spec-auditor	实现与规格/计划的一致性	“代码是否符合要求？”

Simplify Auditor

简化审计Agent

Task tool (spawn teammate):
  subagent_type: Explore
  team_name: "<project>-harden"
  name: "simplify-auditor"
  prompt: |
    You are a simplify auditor on the <project>-harden team.
    Your name is simplify-auditor.

    Your job is to find unnecessary complexity -- NOT fix it. You are
    read-only.

    SCOPE: Only review the following files (modified in this session).
    Do NOT flag issues in other files, even if you notice them.
    Files to review:
    <paste file list here>

    Fresh-eyes start (mandatory): Before reporting findings, re-read all
    listed changed code with "fresh eyes" and actively look for obvious
    bugs, errors, confusing logic, brittle assumptions, naming issues,
    and missed hardening opportunities.

    Review each file and check for:

    1. Dead code and scaffolding -- debug logs, commented-out attempts,
       unused imports, temporary variables left from iteration
    2. Naming clarity -- function names, variables, and parameters that
       don't read clearly when seen fresh
    3. Control flow -- nested conditionals that could be flattened, early
       returns that could replace deep nesting, boolean expressions that
       could be simplified
    4. API surface -- public methods/functions that should be private,
       more exposure than necessary
    5. Over-abstraction -- classes, interfaces, or wrapper functions not
       justified by current scope. Agents tend to over-engineer.
    6. Consolidation -- logic spread across multiple functions/files that
       could live in one place

    For each finding, categorize as:
    - **Cosmetic** (dead code, unused imports, naming, control flow,
      visibility reduction) -- low risk, easy fix
    - **Refactor** (consolidation, restructuring, abstraction changes)
      -- only flag when genuinely necessary, not just "slightly better."
      The bar: would a senior engineer say the current state is clearly
      wrong, not just imperfect?

    For each finding report:
    1. File and line number
    2. Category (cosmetic or refactor)
    3. What's wrong
    4. What it should be (specific fix, not vague)
    5. Severity: high / medium / low

    If you notice issues outside the scoped files, list them separately
    under "Out-of-scope observations" at the end.

    Be thorough within scope. Check every listed file.
    When done, send your complete findings to the team lead.
    If you find ZERO in-scope issues, say so explicitly.

任务工具（生成团队成员）:
  subagent_type: Explore
  team_name: "<项目名>-harden"
  name: "simplify-auditor"
  prompt: |
    你是<项目名>-harden团队的简化审计Agent。
    你的名称是simplify-auditor。

    你的工作是查找不必要的复杂度——而非修复问题。你拥有只读权限。

    范围：仅审核以下文件（本次会话中修改的文件）。
    即使发现其他文件的问题，也不要标记。
    待审核文件:
    <粘贴文件列表>

    强制“新视角”检查：在报告问题前，以全新视角重新阅读所有列出的修改代码，主动查找明显的bug、错误、混淆逻辑、脆弱假设、命名问题和遗漏的强化机会。

    审核每个文件并检查以下内容：

    1. 死代码与脚手架——调试日志、注释掉的尝试代码、未使用的导入、迭代遗留的临时变量
    2. 命名清晰度——函数名、变量和参数，新视角下难以理解的命名
    3. 控制流——可扁平化的嵌套条件、可替代深层嵌套的提前返回、可简化的布尔表达式
    4. API暴露面——应设为私有但当前为公共的方法/函数、过度暴露的接口
    5. 过度抽象——当前范围无需的类、接口或包装函数。Agent往往会过度设计。
    6. 逻辑整合——分散在多个函数/文件中可合并到一处的逻辑

    每个问题分类为：
    - ** cosmetic（ cosmetic）**（死代码、未使用导入、命名、控制流、可见性调整）——低风险，易修复
    - **Refactor（重构）**（逻辑整合、结构调整、抽象变更）——仅当确实必要时标记，而非“稍微更好”。判断标准：资深工程师是否会认为当前状态明显错误，而非只是不够完美？

    每个问题报告需包含：
    1. 文件和行号
    2. 分类（cosmetic或refactor）
    3. 问题描述
    4. 具体修复方案（而非模糊建议）
    5. 严重程度：high / medium / low

    若发现超出范围的问题，在报告末尾单独列出“Out-of-scope observations（超出范围的观察）”。

    在范围内需彻底检查，确保每个列出的文件都被审核。
    完成后，将完整的问题报告发送给团队负责人。
    若未发现任何范围内问题，请明确说明。

Harden Auditor

强化审计Agent

Task tool (spawn teammate):
  subagent_type: Explore
  team_name: "<project>-harden"
  name: "harden-auditor"
  prompt: |
    You are a security/harden auditor on the <project>-harden team.
    Your name is harden-auditor.

    Your job is to find security and resilience gaps -- NOT fix them.
    You are read-only.

    SCOPE: Only review the following files (modified in this session).
    Do NOT flag issues in other files, even if you notice them.
    Files to review:
    <paste file list here>

    Fresh-eyes start (mandatory): Before reporting findings, re-read all
    listed changed code with "fresh eyes" and actively look for obvious
    bugs, errors, confusing logic, brittle assumptions, naming issues,
    and missed hardening opportunities.

    Review each file and check for:

    1. Input validation -- unvalidated external inputs (user input, API
       params, file paths, env vars), type coercion issues, missing
       bounds checks, unconstrained string lengths
    2. Error handling -- non-specific catch blocks, errors logged without
       context, swallowed exceptions, sensitive data in error messages
    3. Injection vectors -- SQL injection, XSS, command injection, path
       traversal, template injection in string-building code
    4. Auth and authorization -- endpoints or functions missing auth,
       incorrect permission checks, privilege escalation risks
    5. Secrets and credentials -- hardcoded secrets, API keys, tokens,
       credentials in log output, unparameterized connection strings
    6. Data exposure -- internal state in error output, stack traces in
       responses, PII in logs, database schemas leaked
    7. Dependency risk -- new dependencies that are unmaintained, poorly
       versioned, or have known vulnerabilities
    8. Race conditions -- unsynchronized shared resources, TOCTOU
       vulnerabilities in concurrent code

    For each finding, categorize as:
    - **Patch** (adding validation, escaping output, removing a secret)
      -- straightforward fix
    - **Security refactor** (restructuring auth flow, replacing a
      vulnerable pattern) -- requires structural changes

    For each finding report:
    1. File and line number
    2. Category (patch or security refactor)
    3. What's wrong
    4. Severity: critical / high / medium / low
    5. Attack vector (if applicable)
    6. Specific fix recommendation

    If you notice issues outside the scoped files, list them separately
    under "Out-of-scope observations" at the end.

    Be thorough within scope. Check every listed file.
    When done, send your complete findings to the team lead.
    If you find ZERO in-scope issues, say so explicitly.

任务工具（生成团队成员）:
  subagent_type: Explore
  team_name: "<项目名>-harden"
  name: "harden-auditor"
  prompt: |
    你是<项目名>-harden团队的安全/强化审计Agent。
    你的名称是harden-auditor。

    你的工作是查找安全与韧性漏洞——而非修复问题。你拥有只读权限。

    范围：仅审核以下文件（本次会话中修改的文件）。
    即使发现其他文件的问题，也不要标记。
    待审核文件:
    <粘贴文件列表>

    强制“新视角”检查：在报告问题前，以全新视角重新阅读所有列出的修改代码，主动查找明显的bug、错误、混淆逻辑、脆弱假设、命名问题和遗漏的强化机会。

    审核每个文件并检查以下内容：

    1. 输入验证——未验证的外部输入（用户输入、API参数、文件路径、环境变量）、类型转换问题、缺失的边界检查、无限制的字符串长度
    2. 错误处理——非特定的catch块、无上下文的错误日志、被吞掉的异常、错误信息中的敏感数据
    3. 注入漏洞——SQL注入、XSS、命令注入、路径遍历、字符串构建代码中的模板注入
    4. 认证与授权——缺失认证的端点或函数、错误的权限检查、权限提升风险
    5. 密钥与凭证——硬编码的密钥、API密钥、令牌、日志输出中的凭证、未参数化的连接字符串
    6. 数据泄露——错误输出中的内部状态、响应中的堆栈跟踪、日志中的PII（个人可识别信息）、泄露的数据库 schema
    7. 依赖风险——未维护、版本管理差或已知漏洞的新依赖
    8. 竞态条件——未同步的共享资源、并发代码中的TOCTOU（时间检查到时间使用）漏洞

    每个问题分类为：
    - **Patch（补丁）**（添加验证、转义输出、移除密钥）——直接修复
    - **Security refactor（安全重构）**（重构认证流程、替换脆弱模式）——需要结构性变更

    每个问题报告需包含：
    1. 文件和行号
    2. 分类（patch或security refactor）
    3. 问题描述
    4. 严重程度：critical / high / medium / low
    5. 攻击向量（如适用）
    6. 具体修复建议

    若发现超出范围的问题，在报告末尾单独列出“Out-of-scope observations（超出范围的观察）”。

    在范围内需彻底检查，确保每个列出的文件都被审核。
    完成后，将完整的问题报告发送给团队负责人。
    若未发现任何范围内问题，请明确说明。

Spec Auditor

规格审计Agent

Task tool (spawn teammate):
  subagent_type: Explore
  team_name: "<project>-harden"
  name: "spec-auditor"
  prompt: |
    You are a spec auditor on the <project>-harden team.
    Your name is spec-auditor.

    Your job is to find gaps between implementation and spec/plan --
    NOT fix them. You are read-only.

    SCOPE: Only review the following files (modified in this session).
    Do NOT flag issues in other files, even if you notice them.
    Files to review:
    <paste file list here>

    Fresh-eyes start (mandatory): Before reporting findings, re-read all
    listed changed code with "fresh eyes" and actively look for obvious
    bugs, errors, confusing logic, brittle assumptions, and
    implementation/spec mismatches before running the spec checklist.

    Review each file against the spec/plan and check for:

    1. Missing features -- spec requirements that have no corresponding
       implementation
    2. Incorrect behavior -- logic that contradicts what the spec
       describes (wrong conditions, wrong outputs, wrong error handling)
    3. Incomplete implementation -- features that are partially built
       but missing edge cases, error paths, or configuration the spec
       requires
    4. Contract violations -- API shapes, response formats, status
       codes, or error messages that don't match the spec
    5. Test coverage -- untested code paths, missing edge case tests,
       assertions that don't verify enough, happy-path-only testing
    6. Acceptance criteria gaps -- spec conditions that aren't verified
       by any test

    For each finding, categorize as:
    - **Missing** -- feature or behavior not implemented at all
    - **Incorrect** -- implemented but wrong
    - **Incomplete** -- partially implemented, gaps remain
    - **Untested** -- implemented but no test coverage

    For each finding report:
    1. File and line number (or "N/A -- not implemented")
    2. Category (missing, incorrect, incomplete, untested)
    3. What the spec requires (quote or reference the spec)
    4. What the implementation does (or doesn't do)
    5. Severity: critical / high / medium / low

    If you notice issues outside the scoped files, list them separately
    under "Out-of-scope observations" at the end.

    Be thorough within scope. Cross-reference every spec requirement.
    When done, send your complete findings to the team lead.
    If you find ZERO in-scope issues, say so explicitly.

任务工具（生成团队成员）:
  subagent_type: Explore
  team_name: "<项目名>-harden"
  name: "spec-auditor"
  prompt: |
    你是<项目名>-harden团队的规格审计Agent。
    你的名称是spec-auditor。

    你的工作是查找实现与规格/计划的差距——而非修复问题。你拥有只读权限。

    范围：仅审核以下文件（本次会话中修改的文件）。
    即使发现其他文件的问题，也不要标记。
    待审核文件:
    <粘贴文件列表>

    强制“新视角”检查：在报告问题前，以全新视角重新阅读所有列出的修改代码，主动查找明显的bug、错误、混淆逻辑、脆弱假设和实现/规格不匹配问题，再执行规格检查清单。

    对照规格/计划审核每个文件并检查以下内容：

    1. 缺失功能——规格要求但未实现的功能
    2. 行为错误——与规格描述矛盾的逻辑（错误条件、错误输出、错误的错误处理）
    3. 实现不完整——部分构建但缺少边缘情况、错误路径或规格要求的配置的功能
    4. 契约违反——与规格不符的API形状、响应格式、状态码或错误信息
    5. 测试覆盖——未测试的代码路径、缺失的边缘情况测试、断言不足、仅覆盖正常流程的测试
    6. 验收标准差距——规格中未被任何测试验证的条件

    每个问题分类为：
    - **Missing（缺失）**——完全未实现的功能或行为
    - **Incorrect（错误）**——已实现但不符合要求
    - **Incomplete（不完整）**——部分实现，仍有差距
    - **Untested（未测试）**——已实现但无测试覆盖

    每个问题报告需包含：
    1. 文件和行号（或“N/A——未实现”）
    2. 分类（missing、incorrect、incomplete、untested）
    3. 规格要求（引用规格原文或参考）
    4. 实现情况（或未实现）
    5. 严重程度：critical / high / medium / low

    若发现超出范围的问题，在报告末尾单独列出“Out-of-scope observations（超出范围的观察）”。

    在范围内需彻底检查，对照每个规格要求。
    完成后，将完整的问题报告发送给团队负责人。
    若未发现任何范围内问题，请明确说明。

6. Process Audit Findings

6. 处理审计发现的问题

Collect findings from all auditors. For each finding:

Critical/High: Create a task and assign to an implementation agent
Medium: Create a task, include in next implementation round
Low/Cosmetic: Include in next round only if trivial to fix; otherwise note in the final summary and skip

Refactor gate: For findings categorized as refactor or security refactor, evaluate whether the refactor is genuinely necessary before creating a task. The bar: "Would a senior engineer say the current state is clearly wrong, not just imperfect?" Reject refactor proposals that are style preferences or marginal improvements.

Exit check: If all findings in this round are severity

low

, fix them inline and skip re-auditing (see Loop Limits).

When creating fix tasks, bundle a document pass into each implementation agent's work:

After fixing your assigned issues, add up to 5 single-line comments across the files you touched on non-obvious decisions:

Logic that needs more than 5 seconds of "why does this exist?" thought

Workarounds or hacks, with context and a TODO for removal conditions

Performance choices and why the current approach was picked

Do NOT comment on the audit fixes themselves -- only on decisions from the original implementation that lack explanation.

This keeps the document pass lightweight and scoped. Auditors in subsequent rounds should not flag these comments as findings.

收集所有审计Agent的问题。针对每个问题：

关键/高级别：创建任务并分配给实现Agent
中级别：创建任务，纳入下一轮实现
低级别/Cosmetic：若修复成本极低则纳入下一轮，否则记录在最终总结中并跳过

重构门槛：对于分类为refactor或security refactor的问题，在创建任务前需评估是否确实需要重构。判断标准：“资深工程师是否会认为当前状态明显错误，而非只是不够完美？”拒绝仅为风格偏好或边际改进的重构建议。

退出检查：若本轮所有问题的严重程度均为

low

，直接修复后跳过重新审计（见“循环限制与退出条件”）。

创建修复任务时，需为每个实现Agent的工作添加文档步骤：

修复分配的问题后，在你修改的文件中添加最多5条单行注释，说明非显而易见的决策：

需要超过5秒思考“为什么存在？”的逻辑

变通方案或临时技巧，附上下文和移除条件的TODO

性能选择及当前方案的原因

请勿为审计修复本身添加注释——仅为原始实现中缺乏解释的决策添加。

这使文档步骤轻量化且聚焦。后续轮次的审计Agent不应将这些注释标记为问题。

7. Loop

7. 循环

If there are findings to fix:

Create tasks from findings (include document pass instructions)
Spawn implementation agents (or reuse idle ones via SendMessage)
Wait for fixes
Run compile + test verification
Check loop limits (see "Loop Limits and Exit Conditions")
If not exiting: spawn audit agents again (fresh agents, not reused -- clean context)
Repeat

若存在需修复的问题：

根据问题创建任务（包含文档步骤说明）
生成实现Agent（或通过SendMessage复用闲置Agent）
等待修复完成
运行编译+测试验证
检查循环限制（见“循环限制与退出条件”）
若不退出：重新生成审计Agent（使用新Agent，而非复用——确保上下文干净）
重复

8. Final Verification and Summary

8. 最终验证与总结

When exit conditions are met:

Compile / type check -- must be clean
Tests -- must all pass
No
```
// TODO
```
or
```
// FIXME
```
comments introduced without corresponding tasks

Produce a final summary for the session:

undefined

满足退出条件后：

编译/类型检查——必须无错误
测试——必须全部通过
未引入无对应任务的
```
// TODO
```
或
```
// FIXME
```
注释

生成本次会话的最终总结：

undefined

Hardening Summary

强化总结

Audit rounds completed: 2 of 3 max Exit reason: Clean audit (all auditors reported zero findings)

已完成审计轮次： 2/3（上限3轮） 退出原因： 审计无问题（所有审计Agent报告零问题）

Findings by round

各轮次问题

Round 1:

simplify-auditor: 4 cosmetic, 1 refactor (rejected -- style preference)
harden-auditor: 2 patches, 1 security refactor (approved)
spec-auditor: 1 missing feature

Round 2:

simplify-auditor: 0 findings
harden-auditor: 0 findings
spec-auditor: 0 findings

第1轮:

simplify-auditor: 4个cosmetic问题，1个重构建议（已拒绝——风格偏好）
harden-auditor: 2个补丁问题，1个安全重构建议（已批准）
spec-auditor: 1个缺失功能

第2轮:

simplify-auditor: 0个问题
harden-auditor: 0个问题
spec-auditor: 0个问题

Actions taken

已执行操作

Fixed: 6 findings (4 cosmetic, 2 patches, 1 security refactor, 1 missing feature -- rejected refactor excluded)
Skipped: 1 refactor proposal (reason: style preference, not a defect)
Document pass: 3 comments added across 2 files

已修复：6个问题（4个cosmetic、2个补丁、1个安全重构、1个缺失功能——已排除被拒绝的重构）
已跳过：1个重构建议（原因：风格偏好，非缺陷）
文档步骤：在2个文件中添加了3条注释

Unresolved

未解决问题

None

Out-of-scope observations

超出范围的观察

<any out-of-scope items auditors flagged, for future reference>


Adapt the format to your context. The goal is a clear record of what was found, what was fixed, what was skipped and why, and what remains.

<审计Agent标记的任何超出范围的问题，供未来参考>


可根据自身上下文调整格式。目标是清晰记录发现的问题、已修复的内容、已跳过的内容及原因，以及剩余问题。

9. Cleanup

9. 清理

Send shutdown requests to all agents, then delete the team:

SendMessage type: shutdown_request to each agent
TeamDelete

向所有Agent发送关闭请求，然后删除团队：

SendMessage type: shutdown_request to each agent
TeamDelete

Agent Sizing Guide

Agent规模指南

Codebase / Task Size	Impl Agents	Audit Agents
Small (< 10 files)	1-2	2 (simplify + harden)
Medium (10-30 files)	2-3	2-3
Large (30+ files)	3-5	3 (simplify + harden + spec)

More agents = more parallelism but more coordination overhead. For most tasks, 2-3 implementation agents and 2-3 auditors is the sweet spot.

代码库/任务规模	实现Agent数量	审计Agent数量
小型（<10个文件）	1-2	2（simplify + harden）
中型（10-30个文件）	2-3	2-3
大型（30+个文件）	3-5	3（simplify + harden + spec）

Agent数量越多，并行度越高，但协调开销也越大。大多数任务的最优配置是2-3个实现Agent和2-3个审计Agent。

Tips

小贴士

Implementation agents should be
general-purpose
-- they need write access
Audit agents should be
Explore
-- read-only prevents them from silently "fixing" things, which defeats the purpose of auditing
Fresh audit agents each round -- don't reuse auditors from previous rounds; they carry context that biases them toward "already checked" areas
Task descriptions must be specific -- include file paths, function names, exact behavior expected. Vague tasks produce vague implementations.
Run compile + tests between phases -- don't spawn auditors on broken code; fix compilation/test errors first
Keep the loop tight -- if auditors find only 1-2 low-severity cosmetic issues, fix them yourself instead of spawning a full implementation round
Assign tasks before spawning -- set
```
owner
```
on tasks via TaskUpdate so agents know what to work on immediately
Simplify-first posture -- when processing audit findings, prioritize cosmetic cleanups that reduce noise before tackling refactors. Cleanup is the default, refactoring is the exception
Security over style -- when budget or time is constrained, prioritize harden findings over simplify findings
Pass the file list -- always give auditors the explicit list of modified files. Don't rely on them figuring out scope on their own.

实现Agent应使用
general-purpose
——需要写入权限
审计Agent应使用
Explore
——只读权限可防止其悄悄“修复”问题，避免失去审计的意义
每轮使用新的审计Agent——不要复用前一轮的审计Agent；他们会携带上下文，导致偏向“已检查过”的区域
任务描述必须具体——包含文件路径、函数名、预期的精确行为。模糊的任务会产生模糊的实现。
阶段间运行编译+测试——不要在代码有问题时生成审计Agent；先修复编译/测试错误
保持循环紧凑——若审计Agent仅发现1-2个低级别cosmetic问题，直接自行修复，无需启动完整的实现轮次
生成Agent前分配任务——通过TaskUpdate为任务设置
```
owner
```
，使Agent立即知道要处理的内容
优先简化——处理审计问题时，先优先清理cosmetic问题以减少干扰，再处理重构。清理是默认操作，重构是例外
安全优先于风格——当预算或时间有限时，优先处理强化问题而非简化问题
传递文件列表——始终向审计Agent提供明确的修改文件列表。不要依赖他们自行判断范围。

Example: Implementing Spec Features

示例：实现规格功能

1.  Read spec, identify 8 features to implement
2.  TeamCreate: "feature-harden"
3.  TaskCreate x8 (one per feature)
4.  Spawn 3 impl agents, assign ~3 tasks each
5.  Wait → all done → compile clean → tests pass
6.  Collect modified file list (git diff --name-only)
7.  Spawn 3 auditors: simplify-auditor, harden-auditor, spec-auditor
8.  Simplify-auditor finds 4 cosmetic + 1 refactor proposal
9.  Harden-auditor finds 2 patches + 1 security refactor
10. Spec-auditor finds 1 missing feature
11. Team lead evaluates refactors (approve security refactor,
    reject simplify refactor), creates fix + document tasks
12. Spawn 2 impl agents for fixes
13. Wait → compile clean → tests pass
14. Round 2: Spawn 3 fresh auditors
15. Auditors find 0 issues → exit condition met
16. Produce hardening summary
17. Shutdown agents, TeamDelete

1. 阅读规格，确定需实现8个功能
2. TeamCreate: "feature-harden"
3. 创建8个TaskCreate（每个功能一个）
4. 生成3个实现Agent，每个分配约3个任务
5. 等待→全部完成→编译无错误→测试通过
6. 收集修改文件列表（git diff --name-only）
7. 生成3个审计Agent：simplify-auditor、harden-auditor、spec-auditor
8. simplify-auditor发现4个cosmetic问题+1个重构建议
9. harden-auditor发现2个补丁问题+1个安全重构建议
10. spec-auditor发现1个缺失功能
11. 团队负责人评估重构建议（批准安全重构，拒绝简化重构），创建修复+文档任务
12. 生成2个实现Agent处理修复
13. 等待→编译无错误→测试通过
14. 第2轮：生成3个新的审计Agent
15. 审计Agent发现0个问题→满足退出条件
16. 生成强化总结
17. 关闭Agent，删除团队

Quality Gates (Non-Negotiable)

质量门禁（不可协商）

These must pass before the loop can exit:

Clean compile / type check -- zero errors
Tests -- zero failures
Exit condition met (clean audit, low-only round, or loop cap reached with critical/high findings resolved)
No
```
// TODO
```
or
```
// FIXME
```
comments introduced without corresponding tasks

必须满足以下条件，循环才能退出：

编译/类型检查——无错误
测试——无失败
满足退出条件（审计无问题、仅低级别问题轮次，或达到循环上限且关键/高级别问题已修复）
未引入无对应任务的
```
// TODO
```
或
```
// FIXME
```
注释