SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场agent-teams-simplify-and-harden

agent-teams-simplify-and-harden

编程与开发

查看项目

更新于 10-15 15:25

技能介绍

用途

Agent Teams Simplify & Harden 是一个两阶段的团队循环技能，目标是产出接近生产质量的代码：先实现，再用简化与加固审计，然后修复审计发现，再重新审计，重复直到代码库稳固或达到循环上限。

适用场景（资料明确列出）：

  • 从规格或计划实现多个功能
  • 在一批改动后加固代码库
  • 修复评审中识别出的问题或缺口清单
  • 任何涉及 5 个以上文件且质量门禁重要的任务

主要能力

  • 两阶段团队循环：第一阶段 IMPLEMENT（在修复轮次中加入文档 pass）；第二阶段 SIMPLIFY & HARDEN AUDIT。审计后若退出条件未满足，则带着发现回到第一阶段，最多 3 轮审计。
  • 并行实现 Agent：派出 general-purpose 类型的 Agent（可读写编辑文件），每个任务或每组逻辑任务一个，并行执行。
  • 并行审计 Agent：派出 Explore 只读 Agent，无法编辑文件，防止其“静默修复”问题。推荐审计维度：simplify-auditor（代码清晰度与不必要的复杂度）、harden-auditor（安全与韧性缺口）、spec-auditor（实现与规格/计划的完成度）。
  • 验证门禁：实现完成后运行编译/类型检查与测试，两者失败需先修复再继续。可选用 verify-gate 技能替代临时命令。
  • 漂移检查：团队负责人在轮次之间重读意图框架与计划，比较当前工作与原始范围，若范围扩大则重新界定或提前退出。
  • 文档 pass：在每个实现 Agent 的修复工作中捆绑，允许在其触碰的文件中为非显而易见决策添加最多 5 条单行注释；不得评论审计修复本身。
  • 学习循环输出：将跨轮次反复出现的审计发现规范化为 pattern_key 条目，供 self-improvement 做跨任务模式跟踪与提升。

使用方式

安装命令：

gh skill install pskoett/pskoett-skills agent-teams-simplify-and-harden

使用 Agent Skills CLI 的备选方式：

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

流程步骤（按资料）：

  1. 规划与框架：若存在计划文件（来自 plan-interview 的 docs/plans/plan-NNN-<slug>.md 或用户提供），读取并提取实现清单作为任务列表；若无计划，运行简短的在线规划访谈（要构建/修复/加固什么、规格或事实来源、验收标准），转化为具体任务列表。创建团队前，团队负责人输出 Intent Frame #1（结果、方法、约束、成功标准、预估复杂度），并与用户确认。
  2. 创建团队：TeamCreate，team_name 形如 "<project>-harden"。
  3. 创建任务：TaskCreate，拆分为离散、可并行的任务，必要时用 TaskUpdate 设置 blockedBy 依赖。
  4. 派发实现 Agent：spawn general-purpose 子 Agent，每人负责一个任务或一组逻辑任务，并行运行。提示词要求检查 TaskList、完成每个任务后标记 completed、遵守质量门禁（编译、测试通过、遵循现有代码模式）、完成后通知团队负责人。
  5. 等待实现完成：监控 Agent 消息，全部完成后运行编译/类型检查与测试；任一失败先修复。可选将编译/测试步骤委托给 verify-gate 技能。生成审计 Agent 前先收集本会话修改的文件列表（git diff --name-only <base-branch> 或 git diff --name-only HEAD~N），并将该列表传给每个审计 Agent。
  6. 派发审计 Agent：spawn Explore Agent（只读）。完整审计提示词模板位于 references/auditor-prompts.md。各审计 Agent 检查内容与报告格式见资料：
    • Simplify Auditor：死代码、命名、控制流、API 表面、过度抽象、合并；分类为 cosmetic 或 refactor（refactor 门槛：明确错误，而非仅仅不完美）；报告 file、line、category、fix、severity。
    • Harden Auditor：输入验证、错误处理、注入向量、认证/授权、密钥、数据暴露、依赖风险、竞态条件；分类为 patch 或 security refactor；报告 file、line、category、severity、attack vector、fix。
    • Spec Auditor：缺失功能、错误行为、实现不完整、契约违反、测试覆盖、验收标准缺口；分类为 missing、incorrect、incomplete 或 untested；报告 file、line、category、spec reference、severity。
  7. 处理审计发现：Critical/High 创建任务并分派给实现 Agent；Medium 创建任务纳入下一实现轮；Low/Cosmetic 仅在易于修复时纳入下一轮，否则记入最终总结并跳过。对 refactor / security refactor 类发现，在创建任务前评估是否真正必要，门槛为“资深工程师会认为当前状态明确错误而非仅仅不完美吗？”拒绝风格偏好或边缘改进。若本轮所有发现均为 low 严重度，则内联修复并跳过重新审计。为修复任务捆绑文档 pass 指令。
  8. 循环：若有发现需修复，从发现创建任务、派发实现 Agent（或通过 SendMessage 复用空闲 Agent）、等待修复、运行编译+测试验证、团队负责人做漂移检查、检查循环上限；若未退出，再次派发审计 Agent（全新 Agent 而非复用）。
  9. 最终验证与总结：编译/类型检查干净、测试全部通过、无未对应任务的 // TODO 或 // FIXME 注释。产出总结，包含审计轮次、退出原因、各轮发现、采取的行动（修复/跳过/文档 pass）、未解决项、范围外观察、learning_loop 输出。
  10. 清理：向所有 Agent 发送 shutdown_request，然后 TeamDelete。

循环上限与退出条件

以下任一成立即退出：

  • 干净审计：所有审计 Agent 报告零发现。
  • 仅 low 轮：一轮中所有发现均为 low 严重度——内联修复并退出，不再重新审计。
  • 达到循环上限：完成 3 轮审计后，内联修复剩余 critical/high 发现并退出；未解决的 medium/low 发现记入最终总结。

预算指引：跟踪各轮累计 diff 增长。若修复轮在原始实现 diff 基础上增加超过 30%，收紧范围：跳过 medium/low 的 simplify 发现，只关注 harden 补丁与规格缺口。

环境要求与限制

  • 该流程使用多 Agent 团队工具（TeamCreate、TaskCreate、TaskUpdate、SendMessage、TeamDelete）以及子 Agent 派发（general-purpose 和 Explore Agent 类型），存在于启用了 agent teams 的 Claude Code 风格环境中。
  • 若环境缺少团队工具但可派生子 Agent：跳过团队/任务工具，直接编排相同阶段（派生实现子 Agent，再派生审计子 Agent，用 markdown 清单跟踪任务）。
  • 若环境完全无法派生子 Agent（例如 GitHub Copilot chat）：不要使用本技能，改用顺序的 simplify-and-harden 技能，并在聊天中询问每个阶段的发现。
  • 流水线集成：本技能替换标准流水线的第 2–4 阶段（执行、评审、学习），可接在 plan-interview 之后或独立运行——所有上游产物均为可选。[plan-interview] → [agent-teams-simplify-and-harden] → [self-improvement]。存在来自 plan-interview 的计划文件时，技能从中提取任务；无计划时，团队负责人运行简短的在线规划阶段。

Agent 规模指南

  • 小型（< 10 文件）：1-2 个实现 Agent，2 个审计 Agent（simplify + harden）。
  • 中型（10-30 文件）：2-3 个实现 Agent，2-3 个审计 Agent。
  • 大型（30+ 文件）：3-5 个实现 Agent，3 个审计 Agent（simplify + harden + spec）。

更多 Agent 意味着更多并行度，也意味着更多协调开销；多数任务 2-3 个实现 Agent 与 2-3 个审计 Agent 是较佳平衡点。

其他要点（资料明确列出）

  • 实现 Agent 应为 general-purpose（需要写权限）；审计 Agent 应为 Explore（只读）。
  • 每轮使用全新审计 Agent，不复用，避免其带有“已检查过”的偏见。
  • 任务描述必须具体，包含文件路径、函数名、预期确切行为。
  • 阶段之间运行编译+测试；不要在损坏的代码上派发审计 Agent。
  • 保持循环紧凑；若审计只发现 1-2 个 low 严重度的外观问题，自行修复而非启动完整实现轮。
  • 派发前先分配任务（通过 TaskUpdate 设置 owner）。
  • 简化优先姿态：优先处理减少噪音的外观清理，清理是默认，重构是例外。
  • 安全优先于风格：预算或时间受限时，优先 harden 发现而非 simplify 发现。
  • 始终给审计 Agent 明确的修改文件列表，不依赖其自行确定范围。

本技能是否开源、是否免费、支持的具体平台、价格、版本等事实在资料中暂未提供。