Awesome Slash

AgentSys

A modular runtime and orchestration system for AI agents.

20 plugins · 49 agents · 41 skills (across all repos) · 30k lines of lib code · 3,507 tests · 5 platforms

Plugins distributed as standalone repos under agent-sh org - agentsys is the marketplace & installer

Commands · Installation · Website · Discussions

Built for Claude Code · Codex CLI · OpenCode · Cursor · Kiro

New skills, agents, and integrations ship constantly. Follow for real-time updates:

______________________________________________________________________

AI模型可以编写代码。这已经不是最难的部分了。最难的部分是它周围的一切——任务选择、分支管理、代码审查、工件清理、CI、PR注释、部署。 AgentSys是一个运行时，它编排代理来处理所有这些事务 -结构化管道、门控阶段、专用代理和在会话边界中幸存的持久状态。

______________________________________________________________________

构建自定义技能、代理、钩子或MCP工具？ agnix 是CLI+LSP linter，可以在配置错误无声失败之前捕获它们——实时IDE验证、自动建议、自动修复，以及用于Claude Code、Codex、OpenCode、Cursor、Kiro、Copilot、Gemini CLI、Cline、Windsurf、Roo Code、Amp等的399条规则。

这是什么

一个代理编排系统——20个插件、49个代理（39个基于文件的代理+10个基于角色的审计项目专家）和41种技能，这些技能组成了软件开发的结构化管道。每个插件都存在于它自己的独立仓库中 特工sh org.agentsys是将它们联系在一起的市场和安装程序。

每个代理都有一个单一的职责、一个特定的模型分配和定义的输入/输出。管道强制执行阶段门，因此代理不能跳过步骤。状态在会话中持续存在，因此工作不会中断。

该系统在Claude Code、OpenCode、Codex CLI、Cursor和Kiro上运行。通过市场或npm安装程序安装，插件会自动从其存储库中获取。

______________________________________________________________________

方法

代码做代码工作。AI做AI工作。

• 检测：正则表达式、AST分析、静态分析-快速、确定性、无令牌浪费
• 判决：法学硕士要求综合、规划、审查——其中推理很重要
• 结果：减少77%的代币 /漂移检测 与多智能体方法相比，整个研究结果的确定性分级

确定性水平的存在是因为并非所有发现都是相等的：

这来自对1000多个存储库的测试。

______________________________________________________________________

基准测试

结构化提示和丰富的上下文比模型层更能提高输出质量。2026年3月以实际任务为基准(/can-i-help 和 /onboard 反对 滑翔mq)，用 claude -p --output-format json模型：克劳德作品4和克劳德十四行诗4。

Sonnet+AgentSys与原始Opus

相同的任务，相同的仓库，相同的提示（“我想改进文档”）：

Sonnet+agentsys比原始Opus产生了更多的输出，具有更高的特异性，成本降低了40%。

有了agentsys，模型层就不那么重要了

一旦管道提供结构化提示、丰富的回购情报数据和阶段门控工作流，该模型就不那么繁重了。Sonnet和Opus之间的差距缩小了：

两种模型都达到了相同的结果质量——Sonnet只是成本更低。结构化管道捕获了大部分收益，否则需要更昂贵的模型。

这意味着什么

投资从模型支出转向管道设计。更好的提示、更丰富的上下文、强制执行的阶段——这些因素以模型升级本身无法实现的方式结合在一起。

______________________________________________________________________

命令

每个命令都是独立工作的。它们一起组成了端到端的管道。

______________________________________________________________________

技能

插件中包含41项技能：

外部技能插件 （独立存储库，单独安装）：

技能是可重用的实现单元。代理人调用技能；命令编排代理。安装插件后，该会话中的所有代理都可以使用其技能。

______________________________________________________________________

快速导航

______________________________________________________________________

仅限技能的插件

提供技能而无需 / 命令。与agentsys一起安装；所有代理人都可以使用技能。

滑翔mq

使用以下工具构建消息队列、后台作业和工作流编排 滑翔mq -Valkey/Redis上的高性能Node.js队列。

关键特性：按键排序、组并发、运行时组速率限制(job.rateLimitGroup())、令牌桶、DAG工作流、广播发布/订阅、步骤作业、重复数据删除、无服务器生产者。

______________________________________________________________________

命令详细信息

/下一个任务

目的： 完成生产自动化任务。

运行它时会发生什么：

1. 政策选择 -选择任务源（GitHub Issues、GitHub Projects、GitLab、本地文件）、优先级过滤器、停止点
2. 任务发现 -显示前5个优先任务，您可以选择一个
3. 工作树设置 -创建独立的分支和工作目录
4. 探索 -深入代码库分析以了解上下文
5. 规划 -设计实施方法
6. 用户批准 -您审核并批准该计划（上次人工交互）
7. 实施 -执行计划
8. 预审查 -跑步 德洛普-代理和准备交付：测试覆盖率检查器
9. 审查循环 -多代理审核迭代直到干净
10. 交付验证 -验证测试是否通过、构建是否通过、是否满足要求
11. 文档更新 -更新CHANGELOG和相关文档
12. 船 -创建PR、监控CI、处理评论、合并

第9阶段使用 orchestrate-review 培养并行审阅者（代码质量、安全性、性能、测试覆盖率）和条件专家的技能。

涉及的代理人：

跨插件代理：

用途：

/next-task              # Start new workflow
/next-task --resume     # Resume interrupted workflow
/next-task --status     # Check current state
/next-task --abort      # Cancel and cleanup

完整的工作流程文档→

______________________________________________________________________

/准备交货

目的： 在不发货的情况下运行所有装运前质量闸门。手动或外部完成实施后使用 /next-task.

它运行的内容（按顺序）：

1. 预审门 （并行）-开发+/简化+准备交付：测试覆盖率检查器
2. 配置lint （有条件）-agnix+/更改触摸代理/技能/插件文件时增强
3. 审查循环 -4名核心评审员+条件专家，最多5次迭代
4. 交付验证 -测试通过、构建通过、满足要求
5. 文档同步 -同步文档代理更新文档

/prepare-delivery                    # Run all quality gates
/prepare-delivery --skip-review      # Skip review loop
/prepare-delivery --skip-docs        # Skip docs sync
/prepare-delivery --base=develop     # Against a specific base branch

不创建PR或推送使用 /ship 或 /gate-and-ship 之后。

______________________________________________________________________

/大门和船

目的： 然后，质量门一次发货。链条 /prepare-delivery 然后 /ship.

/gate-and-ship                       # Full: quality gates + ship
/gate-and-ship --skip-review         # Skip review, still ship
/gate-and-ship --base=develop        # Against a specific base branch

可组合性：

/gate-and-ship = /prepare-delivery + /ship

每件作品都独立运行-使用 /prepare-delivery 在决定发货之前单独审查，或 /ship 如果已经验证，则单独使用。

______________________________________________________________________

/agnix

目的： 在破坏您的工作流程之前，请先进行Lint代理配置。第一个专门用于AI代理配置的linter。

agnix 是一个独立的开源项目，提供验证引擎。此插件将其集成到您的工作流程中。

它解决的问题是：

代理配置是代码。它们会影响行为、安全性和可靠性。但与应用程序代码不同，它们没有linting。当代理失败时，您会发现您的SKILL.md格式错误。当钩子被利用时，你会发现它们存在安全问题。当AI的行为出乎意料时，你会意识到你的CLAUDE.md有冲突的规则。

agnix在问题产生之前就发现了这些问题。

它验证了什么：

399验证规则 （126个可自动修复）来源于：

• 官方工具规范（Claude Code、Codex CLI、OpenCode、Cursor、Kiro、GitHub Copilot、Gemini CLI、Cline、Windsurf、Roo Code、Amp等）
• 关于试剂可靠性和快速注射的研究论文
• 在500多个存储库中进行真实测试
• 社区报告的问题和边缘案例

支持的文件：

CI/CD集成：

agnix输出SARIF格式用于GitHub代码扫描。将其添加到您的工作流中：

- name: Lint agent configs
  run: agnix --format sarif > results.sarif
- uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: results.sarif

用途：

/agnix                       # Validate current project
/agnix --fix                 # Auto-fix fixable issues
/agnix --strict              # Treat warnings as errors
/agnix --target claude-code  # Only Claude Code rules
/agnix --format sarif        # Output for GitHub Code Scanning

代理人： agnix代理（sonnet模型）

外部工具： 需要 agnix命令行界面

npm install -g agnix         # Install via npm
# or
cargo install agnix-cli      # Install via Cargo
# or
brew install agnix           # Install via Homebrew (macOS)

为什么使用agnix：

• 在配置错误导致代理失败之前将其捕获
• 在整个团队中实施安全最佳实践
• 随着代理配置的增长，保持一致性
• 将验证集成到CI/CD管道中
• 从一个linter支持多个AI工具

______________________________________________________________________

/船舶

目的： 将您当前的分支从“准备提交”更改为“合并PR”

运行它时会发生什么：

1. 飞行前 -检测CI平台、部署平台、分支策略
2. 提交 -使用生成的消息进行阶段和提交（如果未提交的更改）
3. 推送和公关 -推送分支，创建拉取请求
4. CI监视器 -等待CI，在暂时失败时重试
5. 审核等待 -等待3分钟自动审阅者（Copilot、Claude、Gemini、Codex）
6. 地址评论 -处理每位评论者的每一条评论
7. 合并 -当所有注释都已解决并且CI通过时合并
8. 部署 -部署和验证（如果是多分支工作流）
9. 清理 -删除工作树、关闭问题、删除分支

平台检测：

评审意见处理：

每一条评论都得到了回应。没有例外。工作流对评论进行分类并处理每个评论：

• 代码修复已实现
• 风格建议得到应用
• 问题得到回答
• 误报得到解释

如果无法修复某些问题，工作流会回复解释原因并解决该线程。

用途：

/ship                       # Full workflow
/ship --dry-run             # Preview without executing
/ship --strategy rebase     # Use rebase instead of squash

完整的工作流程文档→

______________________________________________________________________

/ 退出

目的： 查找AI错误（调试语句、占位符文本、详细注释、TODO）并将其删除。

检测工作原理：

三个阶段按顺序运行：

1. 第一阶段：正则表达式模式 （高度确定）

- console.log, print(), dbg!(), println!() - // TODO, // FIXME, // HACK - 空的挡块、失效的过梁 - 硬编码秘密（API密钥、令牌）

1. 第二阶段：多道分析器 （中等确定性）

- 文档代码比（注释过多） - 详细比率（AI前言） - 过度工程模式 - 流行语通货膨胀 - 死码检测 - 存根函数

1. 第3阶段：CLI工具 （低确定性，可选）

- jscpd、madge、escomplex（JS/TS） - pylint，radon（Python） - golangci lint（围棋） - clippy（生锈）

支持的语言： JavaScript/TypeScript、Python、Rust、Go、Java

用途：

/deslop              # Report only (safe)
/deslop apply        # Fix HIGH certainty issues
/deslop apply src/ 10  # Fix 10 issues in src/

彻底程度：

• quick -仅第1阶段（最快）
• normal -第1阶段+第2阶段（默认）
• deep -所有阶段（如果工具可用）

图案参考→

______________________________________________________________________

/perf

目的： 具有基线、分析和证据支持决策的结构化绩效调查。

10阶段方法 （基于记录的实际绩效调查会议）：

1. 设置 -确认场景、成功标准、基准命令
2. 基线 -最少运行60秒，需要PERF_METRICS标记
3. 临界点 -二分查找失败阈值
4. 约束 -CPU/内存限制，测量增量与基线
5. 假设 -生成多达5个有证据和信心的假设
6. 代码路径 -使用repo intel识别入口点和热文件
7. 分析 -特定语言工具（--cpu配置文件、JFR、cProfile、pprof）
8. 优化 -每个实验一次更改，2+次验证通过
9. 决定 -根据可衡量的改进继续或停止
10. 整合 -最终基线、证据日志、调查完成

代理人和技能：

用途：

/perf                 # Start new investigation
/perf --resume        # Resume previous investigation

阶段标志（高级）：

/perf --phase baseline --command "npm run bench" --version v1.2.0
/perf --phase breaking-point --param-min 1 --param-max 500
/perf --phase constraints --cpu 1 --memory 1GB
/perf --phase hypotheses --hypotheses-file perf-hypotheses.json
/perf --phase optimization --change "reduce allocations"
/perf --phase decision --verdict stop --rationale "no measurable improvement"

______________________________________________________________________

/漂移检测

目的： 将文档和计划与代码中的实际内容进行比较。

它解决的问题是：

你的路线图上写着“用户身份验证：完成”。但它真的实现了吗？你的GitHub问题说“添加黑暗模式”。它已经在代码库中了吗？计划与现实脱节。此命令可以找到漂移。

它是如何工作的：

1. JavaScript收集器 收集数据（快速、令牌高效）

- GitHub问题及其标签 - 文档文件 - 实际代码导出和实现

1. 单次Opus通话 执行语义分析

- 匹配概念，而不是字符串（“用户身份验证”匹配 auth/, login.js, session.ts) - 确定已实施但未记录 - 确定已记录但未实施的内容 - 查找应关闭的过时问题

为什么采用这种方法：

多代理收集在协调上浪费代币。JavaScript收集器是快速和确定的。一个提示良好的LLM调用进行了实际分析。结果：与多代理方法相比，令牌减少了77%。

在1000多个存储库上进行了测试 在释放之前。

用途：

/drift-detect              # Full analysis
/drift-detect --depth quick  # Quick scan

______________________________________________________________________

/审计项目

目的： 多代理代码审查，迭代直到问题得到解决。

运行它时会发生什么：

最多10个基于角色的专用代理根据您的项目运行：

调查结果按严重程度（严重/高/中/低）进行收集和分类。所有非误报问题都会自动修复。循环重复，直到没有遗留问题。

用途：

/audit-project                   # Full review
/audit-project --quick           # Single pass
/audit-project --resume          # Resume from queue file
/audit-project --domain security # Security focus only
/audit-project --recent          # Only recent changes

代理人参考→

______________________________________________________________________

/增强

目的： 分析你的提示、插件、代理、文档、钩子和技能，以寻找改进机会。

八台分析仪并行运行：

每个发现包括：

• 确定性级别（高/中/低）
• 具体位置（文件：行）
• 怎么了
• 如何修复它
• 是否可以自动修复

自动学习： 检测明显的误报（模式文档、工作流门），并将其保存以备将来运行。随着时间的推移，无需手动抑制文件即可降低噪音。

用途：

/enhance                    # Run all analyzers
/enhance --focus=agent      # Just agent prompts
/enhance --apply            # Apply HIGH certainty fixes
/enhance --show-suppressed  # Show what's being filtered
/enhance --no-learn         # Analyze but don't save false positives

______________________________________________________________________

/回购英特尔

目的： 统一的静态分析-在一个插件中集成git历史、AST符号和项目元数据。

它提供了什么：

• Git历史智能：热点、耦合、所有权、总线因素、缺陷点、AI检测
• AST符号映射：导出、函数、类、导入
• 项目元数据和健康指标

输出缓存在 {state-dir}/repo-intel.json （外部回购英特尔插件）和 {state-dir}/repo-map.json （agentsys内部仓库映射库）。 {state-dir} 是 .claude/, .opencode/，或 .codex/ 这取决于你的平台。

为什么重要：

工具如 /drift-detect, /onboard, /can-i-help，规划者使用这些数据，而不是每次重新扫描仓库。9个插件自动使用repo intel数据。

用途：

/repo-intel init                   # First-time scan
/repo-intel update                 # Incremental update
/repo-intel query hotspots         # Most active files
/repo-intel query ownership src/   # Who owns a path
/repo-intel query bus-factor       # Knowledge risk

由...支持 试剂分析仪 Rust二进制文件。

______________________________________________________________________

/同步文档

目的： 将文档与实际代码更改同步-查找过时的引用，更新CHANGELOG，标记过时的示例。

它解决的问题是：

你重构 auth.js 进入 auth/index.js.你的README仍然说 import from './auth'。您重命名了一个函数。三份文件仍然引用旧名称。你发布了一个功能。CHANGELOG没有提到这一点。文档偏离了代码。此命令可以找到漂移。

它检测到的内容：

自动修复与标记：

用途：

/sync-docs              # Check what docs need updates (safe)
/sync-docs apply        # Apply safe fixes
/sync-docs report src/  # Check docs related to src/
/sync-docs --all        # Full codebase scan

______________________________________________________________________

/学习

目的： 在线研究任何主题，并使用RAG优化的索引创建全面的学习指南。

它的作用：

1. 渐进式发现 -使用漏斗方法（广泛→ 特定的→ deep）寻找优质资源
2. 质量评分 -按权威性、时效性、深度、示例、唯一性对来源进行评分
3. 实时提取 -仅获取高分来源以保存代币
4. 合成 -通过示例和最佳实践创建结构化的学习指南
5. RAG指数 -更新CLAUDE.md/AGENTS.md主索引以供将来查找
6. 增强 -运行增强：增强文档和增强：增强提示

深度级别：

输出结构：

agent-knowledge/
  CLAUDE.md                    # Master index (updated each run)
  AGENTS.md                    # Index for OpenCode/Codex
  recursion.md                 # Topic-specific guide
  resources/
    recursion-sources.json     # Source metadata with quality scores

用途：

/learn recursion                    # Default (20 sources)
/learn react hooks --depth=deep     # Comprehensive (40 sources)
/learn kubernetes --depth=brief     # Quick overview (10 sources)
/learn python async --no-enhance    # Skip enhancement pass

代理人： 学习代理（十四行诗模型）

______________________________________________________________________

/咨询

目的： 在不离开当前会话的情况下，从另一个AI CLI工具获取第二意见。

它的作用：

1. 刀具检测 -检测安装了哪些AI CLI工具（跨平台）
2. 交互式选择器 -如果未指定工具，则仅显示已安装的工具供选择
3. 努力映射 -将工作量水平映射到每个提供者的模型和推理标志
4. 执行 -以安全模式默认值和120秒超时运行咨询
5. 会话连续性 -为Claude和Gemini保存会话状态（支持 --continue)

支持的工具：

用途：

/consult "Is this the right approach?" --tool=gemini --effort=high
/consult "Review for performance issues" --tool=codex
/consult "Suggest alternatives" --tool=claude --effort=max
/consult "Continue from where we left off" --continue
/consult "Explain this error" --context=diff --tool=gemini

代理人： 咨询代理（十四行诗编排模型）

______________________________________________________________________

/辩论

目的： 通过两个AI CLI工具之间的结构化多轮辩论来进行压力测试。

它的作用：

1. 刀具检测 -检测安装了哪些AI CLI工具（跨平台）
2. 交互式选择器 -如果没有指定工具，则在单个批量问题中提示提议者、挑战者、努力、轮次和上下文
3. 提议者/挑战者格式 -第一个工具为主题辩护；第二个工具挑战与证据
4. 多轮交易 -每一轮提议者进行辩护，挑战者进行回应（1-5轮）
5. 裁决 -Orchestrator提供最终综合，通过推理选出获胜者

用途：

# Natural language
/debate codex vs gemini about microservices vs monolith
/debate with claude and codex about our auth implementation
/debate thoroughly gemini vs codex about database schema design
/debate codex vs gemini 3 rounds about event sourcing

# Explicit flags
/debate "Should we use event sourcing?" --tools=claude,gemini --rounds=3 --effort=high
/debate "Valkey vs PostgreSQL for caching" --tools=codex,opencode

# With codebase context
/debate "Is our current approach correct?" --tools=gemini,codex --context=diff

选项：

代理人： 辩论编排器（编排的opus模型）

/web ctl

目的： AI代理的浏览器自动化——导航、身份验证和与网页交互。

它是如何工作的：

每次调用都是一个使用Playwright的Node.js进程。没有守护进程，没有MCP服务器。会话状态通过Chrome的userDataDir和AES-256-GCM加密存储保持不变。

Agent calls skill -> node scripts/web-ctl.js  -> Playwright API -> JSON result

会话生命周期：

1. session start -创建会话（加密配置文件目录）
2. session auth --url -打开Chrome进行人工登录（2FA、验证码）。轮询成功URL/选择器，完成后加密Cookie
3. run -使用持久Cookie的无头操作
4. session end -清理

行动：

click-wait 等待网络空闲+无DOM突变500毫秒后返回。将SPA交互从多个代理切换到一个代理。

错误处理：

所有错误都会返回带有可操作恢复建议的分类代码：

安全： 输出净化（cookie/令牌已编辑），提示注入防御([PAGE_CONTENT: ...] 分隔符）、AES-256-GCM静态加密、反机器人措施(webdriver=false，随机延迟），只读代理（无写/编辑工具）。

选择器语法： role=button[name='Submit'], css=div.class, text=Click here, #id

用途：

/web-ctl goto https://example.com
/web-ctl auth twitter --url https://x.com/i/flow/login
/web-ctl   # describe what you want to do, agent orchestrates it

安装：

agentsys install web-ctl
npm install playwright
npx playwright install chromium

代理人： 网络会话（十四行诗模型）

技能： web身份验证（人在循环中的身份验证）、web浏览（无头操作）

/释放

具有自动生态系统和工具检测功能的版本发布

/release                # Patch release (auto-discovers how this repo releases)
/release minor          # Minor version bump
/release major --dry-run # Preview what would happen

发布代理在执行之前发现您的仓库是如何发布的：

1. 检查发布工具 -语义释放，释放它，goreleaser，变更集，货物释放
2. 检查脚本 -Makefile release: target，npm release 脚本， scripts/release.*
3. 回到通用 -版本升级、变更日志、标签、推送、GitHub发布、发布

支持12个以上的生态系统：npm、cargo、python、go、maven、gradle、ruby、nuget、dart、hex、packagist、swift。

代理人： 脱模剂（十四行诗模型）

技能： 发布（通用回退工作流）

/熟练工

从您的工作流程模式中学习并建议自动化

/skillers show              # Display current config and knowledge stats
/skillers compact           # Analyze recent transcripts, extract patterns
/skillers compact --days=14 # Analyze older transcripts
/skillers recommend         # Get automation suggestions from accumulated knowledge

阅读您的Claude Code对话记录，识别重复出现的模式（痛点、重复的工作流程、愿望），将它们聚类到加权主题中，并建议技能、钩子或代理来自动化它们。

没有每轮开销-它读取Claude Code已经保存的成绩单。

代理人： skillers压缩器（十四行诗），skillers推荐器（作品）

技能： 紧凑型煎锅，推荐

______________________________________________________________________

/机载

目的： 在3分钟内熟悉任何代码库。

运行它时会发生什么：

1. 收集 （中位数68ms）-纯JavaScript扫描清单、结构、README、CI、git信息。正常深度添加了CLAUDE.md/AGENTS.md和repo intel。没有LLM令牌。
2. 合成 -Sonnet代理生成结构化概述：技术栈、关键文件、活动区域、惯例
3. 指南 -互动问答：询问特定文件、区域或模式

代币减少74% 而不是手动入职。在JS/TS、Rust、Go、Python、C/C++、Java和Deno的100个repos上进行了验证。

深度级别：

支持的清单： package.json、Cargo.toml、go.mod、pyproject.toml、deno.json、CMakeLists.txt、meson.build、setup.py、pom.xml、build.gradle。检测monorepos（npm/pnpm/lerna/Cargo工作区、Python库/、Deno工作区）。

用途：

/onboard                    # Current repo
/onboard /path/to/repo      # Specific repo
/onboard --depth=deep       # Include AST data

代理人： 机载代理（十四行诗模型）

完整文档→

______________________________________________________________________

/can-i-heep

目的： 将贡献者的技能与他们可以提供帮助的特定领域相匹配。

运行它时会发生什么：

1. 收集 -收集项目数据+贡献者信号（测试差距、文档漂移、问题点、良好的第一领域、未决问题）。已在100个repos上验证。
2. 匹配 -Sonnet代理询问开发人员背景，并将技能与项目需求相匹配
3. 指南 -对于每项建议：阅读代码，解释需要做什么，给出具体的第一步

匹配：

用途：

/can-i-help                       # Current repo
/can-i-help /path/to/repo         # Specific repo
/can-i-help --depth=deep          # Include AST data

代理人： can-i-heep-agent（十四行诗模型）

完整文档→

______________________________________________________________________

命令如何协同工作

独立使用：

/deslop apply          # Just clean up your code
/sync-docs             # Just check if docs need updates
/prepare-delivery      # Run all quality gates (no ship)
/ship                  # Just ship this branch
/gate-and-ship         # Quality gates + ship in one command
/audit-project         # Just review the codebase

可组合输送链：

/prepare-delivery  = quality gates only (deslop, review, validation, docs)
/ship              = PR + CI + merge only
/gate-and-ship     = /prepare-delivery + /ship
/next-task         = full workflow (discovery → implementation → /prepare-delivery → /ship)

完全集成的工作流程：

当你奔跑时 /next-task，它协调一切：

/next-task picks task → explores codebase → plans implementation
    ↓
implementation-agent writes code
    ↓
deslop-agent + prepare-delivery:test-coverage-checker + /simplify (parallel)
    ↓
review loop iterates until approved
    ↓
prepare-delivery:delivery-validator checks requirements
    ↓
sync-docs-agent syncs documentation
    ↓
/ship creates PR → monitors CI → merges

工作流跟踪状态，因此您可以从任何点恢复。

______________________________________________________________________

设计理念

Architecture decisions and trade-offs (click to expand)

实际问题

前沿模型能写出好的代码。解决了。未解决的问题：

• 上下文管理 -模特们在训练中忘记了自己在做什么
• 紧实性失忆症 -长时间会话被总结，失去关键状态
• 任务漂移 -没有结构，代理就会偏离实际目标
• 跳过步骤 -代理在未执行时跳过审查、测试或清理
• 代币浪费 -使用LLM需要静态分析可以更快地完成的工作
• 照看孩子 -手动编排开发的每个阶段
• 重复请求 -每次会话都要求相同的工作流程

这是如何解决的

1.一个代理，一份工作，做得非常好

与良好代码相同的原则：单一责任。勘探代理进行勘探。实现代理实现。第9阶段培养了多名专注的审稿人。没有代理人会试图做所有事情。专业代理，每个代理的范围都很窄，成功标准也很明确。

2.带闸门的管道，而不是单体管道

与DevOps的原理相同。每一步都必须通过，然后才能开始下一步。审核前不能推。在CI通过之前无法合并。钩子强制执行这一点——代理不能跳过阶段。

3.工具做工具工作，代理人做代理人工作

如果静态分析、正则表达式或shell命令可以做到这一点，不要问LLM。模式检测使用预索引正则表达式。文件发现使用glob。平台检测使用文件存在性检查。LLM只处理需要判断的事情。

4.代理人不需要知道工具是如何工作的

斜率检测器返回的结果具有确定性。代理不需要理解三阶段管道、正则表达式模式或分析器启发式算法。好的工具设计意味着消费者不需要实现细节。

5.在没有工具的地方构建工具

许多任务缺乏现有的工具。用于漂移检测的JavaScript收集器。用于斜坡检测的多通道分析仪。结果：代理接收结构化数据，而不是需要解决的原始问题。

6.研究支持的快速工程

可显著改善结果的记录技术：

• 渐进式披露 -代理只看到当前步骤所需的内容
• 结构化输出 -分隔符之间的JSON，节的XML标签
• 显式约束 -代理人不能做什么和他们做什么一样重要
• 射击示例很少 -模式不明显的地方
• 工具调用过代 -让模型使用工具，而不是生成类似工具的输出

7.验证计划和结果，而不是每一步

批准该计划。查看结果。中间是自动化的。一次计划批准就可以通过实施、审查、清理和运输来解锁自主执行。

8.适合任务的模型

将模型能力与任务复杂性相匹配：

• 作品 -规划、实施、审查编排
• 十四行诗 -模式匹配、验证、发现
• 俳句 -Git操作、文件移动、CI轮询

优质化合物。勘探不力→ 糟糕的计划→ 执行不力→ 审查周期。早期阶段值得最好的模式。

9.会话后的持久状态

两个JSON文件跟踪所有内容：什么任务，什么阶段。会话可以终止并恢复。多个会话使用单独的工作树在不同的任务上并行运行。

10.委派所有可自动化的任务

特工不只是写代码。他们：

• 清洁自己的输出（除垢剂）
• 更新文档（同步文档代理）
• 修复CI故障（CI修复程序）
• 回应评审意见
• 检查计划偏差(/漂移检测)
• 分析自己的提示(/增强)

如果可以指定，则可以委派。

11.编排者保持高水平

主工作流编排器不读取文件、搜索代码或编写实现。它启动专门的代理并接收他们的输出。使编排器的上下文窗口可用于协调，而不是填充文件内容。

12.可组合式，非整体式

每个命令都是独立运行的。 /deslop 无需清理代码 /next-task. /ship 无需完整的工作流程即可合并PR。作品组合在一起，但每一件作品都有其自身的价值。

这给你带来了什么

• 运行多个会话 -不同工作树上的不同任务，无干扰
• 快速迭代 -批准计划，检查结果，重复
• 呆在有趣的地方 -政策决策、架构选择、边缘案例
• 审查负担最小 -在看到输出之前，大多数问题都被发现并修复了
• 无重复请求 -您想要的工作流程，无需每次询问
• 水平扩展 -更多的会议，更多的任务，相同的监督级别

______________________________________________________________________

安装

克劳德代码（推荐方式）

/plugin marketplace add agent-sh/agentsys
/plugin install next-task@agentsys
/plugin install ship@agentsys

所有平台（npm）

npm install -g agentsys && agentsys

Claude Code、OpenCode、Codex CLI、Cursor和Kiro的交互式安装程序。

# Non-interactive install
agentsys --tool claude              # Single tool
agentsys --tool cursor              # Cursor (project-scoped skills + commands)
agentsys --tool kiro                # Kiro (project-scoped steering + skills + agents)
agentsys --tools "claude,opencode"  # Multiple tools
agentsys --development              # Dev mode (bypasses marketplace)

完整安装指南→

______________________________________________________________________

需求

必修的：

• Git
• Node.js 18+

对于GitHub工作流：

• GitHub命令行界面(gh)已认证

对于GitLab工作流：

• GitLab命令行界面(glab)已认证

For/repo intel：

• 代理分析器（通过npm自动安装）

对于/agnix：

• agnix命令行界面 已安装(npm install -g agnix, cargo install agnix-cli，或 brew install agnix)

本地诊断（可选）：

npm run detect   # Platform detection (CI, deploy, project type)
npm run verify   # Tool availability + versions

______________________________________________________________________

研究与测试

该系统建立在研究的基础上，而不是猜测。

知识库 (agent-docs/)：来自Anthropic、OpenAI、谷歌和微软的8000行精选文档，涵盖：

• Agent体系结构和设计模式
• 快速工程技术
• 函数调用和工具使用
• 上下文效率和令牌优化
• 多代理系统和编排
• 指令遵循可靠性

测试：

• 3507项测试通过
• 漂移检测已在1000多个存储库上验证
• 所有命令的E2E工作流程测试
• 跨平台验证（Claude Code、OpenCode、Codex CLI、Cursor、Kiro）

方法论：

• /perf 基于记录的实际绩效调查会议的调查阶段
• 从跨存储库的模式分析中得出的确定性级别
• 已测量并验证令牌优化（漂移检测减少77%）

______________________________________________________________________

文档

工作流程深度剖析

参考

______________________________________________________________________

支持

• 问题：
• 讨论：

______________________________________________________________________

MIT许可证|由 阿维·费内什