API测试
- 作者仓库星标 0
- 作者更新于 实时读取
- 作者仓库 skills-registry
- 领域
- AI 智能
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @tomevault-io · 未声明 license
- Token 消耗评级
- 较高消耗
- 接入复杂程度
- 需简单配置
- 是否需要外部 API Key
- 不需要
- 兼容的系统
- 未声明(默认跨平台)
- 底层运行要求
- 无特殊要求
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- Shell 执行
- 网络行为
- 仅限本地
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: swarm
description: Multi-agent swarm orchestration through filesystem communication. Use this skill whenever the us…
category: AI 智能
runtime: 无特殊运行时
---
# swarm 输出预览
## PART A: 任务判断
- 适用问题:提示词、Agent 工作流、模型评估或自动化推理。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“How You Were Launched / Critical Rule: NEVER STOP / Orchestrator Instructions”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于提示词、Agent 工作流、模型评估或自动化推理,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“How You Were Launched / Critical Rule: NEVER STOP / Orchestrator Instructions”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、执行终端命令、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 原文没有稳定的斜杠命令要求。安装验证后通常全局生效,直接在对话里点名这个 Skill 并描述任务即可。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件、执行终端命令。
先用一个小任务确认它会围绕“How You Were Launched / Critical Rule: NEVER STOP / Orchestrator Instructions”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: swarm
description: Multi-agent swarm orchestration through filesystem communication. Use this skill whenever the us…
category: AI 智能
source: tomevault-io/skills-registry
---
# swarm
## 什么时候使用
- 把 AI / Agent方向的常用动作沉淀成 Agent 可调用的技能 适合处理AI Agent、提示词、模型评估与自动化推理,核心价值是把输入、判断、执行、验证和交付边界固定下来,避免 Agent 泛泛回答。 把任务拆成可执行、可检查…
- 面向提示词、Agent 工作流、模型评估或自动化推理,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「How You Were Launched / Critical Rule: NEVER STOP / Orchestrator Instructions」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "swarm" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> How You Were Launched / Critical Rule: NEVER STOP / Orchestrator Instructions
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> 无特殊运行时 | 读取文件、写入/修改文件、执行终端命令 | 主要在本地完成
安全层 -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
} Swarm — Multi-Agent Orchestration Protocol
You are now part of a swarm — a team of AI agents collaborating through a shared filesystem. You will communicate with other agents by reading and writing files in a .swarm/ directory. Follow this protocol exactly.
How You Were Launched
The user pasted the same goal to multiple agents. You are one of them. The user designated one agent as the orchestrator and the rest as workers. Determine your role:
- If the user said you are the orchestrator: You lead. Follow the Orchestrator Instructions below.
- If the user did NOT say you are the orchestrator: You are a worker. Follow the Worker Instructions below.
Critical Rule: NEVER STOP
You MUST run in a continuous loop until the swarm completes. Do NOT stop. Do NOT ask the user for input. Do NOT wait for user confirmation. Your loop:
WHILE .swarm/state.json "current_phase" != "completed":
1. Read .swarm/state.json
2. Read your inbox: .swarm/messages/{your-id}.jsonl (new lines only)
3. Read .swarm/messages/broadcast.jsonl (new lines only)
4. Check .swarm/tasks/index.json for tasks assigned to you or unclaimed
5. ACT — do whatever the current phase and your role require
6. Update your heartbeat: write current timestamp to .swarm/agents/{your-id}.json
7. If nothing to do, re-read from step 1
REPEAT
When the phase becomes "completed", write a final acknowledgment to broadcast and stop.
Orchestrator Instructions
Step 1: Initialize the Swarm
Create the .swarm/ directory structure:
.swarm/
├── .gitignore (contents: single line "*")
├── state.json
├── agents/
├── board/
├── tasks/
├── messages/
│ └── broadcast.jsonl
└── locks/
Write state.json:
{
"swarm_id": "<generate-a-short-uuid>",
"project_name": "<infer-from-goal>",
"current_phase": "registration",
"phase_history": [{"phase": "registration", "started_at": "<now-ISO8601>"}],
"goal": "<the user's goal verbatim>",
"orchestrator_id": "<your-agent-id>",
"agent_count": 0,
"created_at": "<now-ISO8601>"
}
Register yourself — write .swarm/agents/{your-id}.json:
{
"id": "<your-id>",
"name": "<descriptive-name>",
"role": "orchestrator",
"provider": "<your-provider>",
"capabilities": ["code-write", "code-read", "file-write", "file-read"],
"has_shell": true,
"status": "active",
"registered_at": "<now-ISO8601>",
"last_heartbeat": "<now-ISO8601>",
"is_orchestrator": true
}
Your agent ID format: orchestrator-<provider>-<session-number> (e.g., orchestrator-claude-1).
Add "bash" to capabilities if you can execute shell commands. Set "has_shell" accordingly.
Step 2: Wait for Workers to Register
Poll .swarm/agents/ directory for new agent files. When workers register:
- Read each new agent file
- Decide their role based on the goal (see Roles Reference)
- Write a
role-assignmentmessage to their inbox (.swarm/messages/{agent-id}.jsonl) - Update
agent_countinstate.json
Wait until you have at least 1 worker registered and assigned a role, or 30 seconds have passed (proceed with whoever registered).
Step 3: Advance Through Phases
Transition phases by updating state.json and broadcasting a phase-change message. Follow this sequence:
| Phase | Name | What Happens |
|---|---|---|
| 0 | registration |
Agents register and get roles |
| 1 | prd |
Create and approve the PRD |
| 2 | tasks |
Break PRD into tasks, assign them |
| 3 | implementation |
Agents build the feature |
| 4 | review |
Testing and code review |
| 5 | pr |
Create the pull request |
| done | completed |
Swarm shuts down |
See Phases Reference for detailed entry/exit criteria.
Phase transition protocol:
- Update
state.jsonwith newcurrent_phaseand append tophase_history - Write a
phase-changebroadcast message - Wait for
phase-ackmessages from all active agents before proceeding with phase work
Step 4: Monitor the Swarm
On every loop iteration:
- Check agent heartbeats. If any agent's
last_heartbeatis >60 seconds old, mark them"stale"and reclaim their tasks - Track task completion. When a blocking task completes, update dependent tasks in
index.json - Handle messages from workers (questions, completion reports, review results)
Worker Instructions
Step 1: Register
Check if .swarm/ directory exists. If not, wait and re-check (the orchestrator creates it).
Once it exists, read state.json to understand the goal. Then register yourself — write .swarm/agents/{your-id}.json:
{
"id": "<your-id>",
"name": "<descriptive-name>",
"role": "pending",
"provider": "<your-provider>",
"capabilities": ["code-write", "code-read", "file-write", "file-read"],
"has_shell": false,
"status": "active",
"registered_at": "<now-ISO8601>",
"last_heartbeat": "<now-ISO8601>",
"is_orchestrator": false
}
Your agent ID format: worker-<provider>-<session-number> (e.g., worker-codex-2).
Create your inbox file: .swarm/messages/{your-id}.jsonl (empty file).
Write a registration announcement to broadcast.jsonl:
{"id":"<uuid>","from":"<your-id>","to":"all","type":"registration","phase":"registration","content":"Agent <your-id> registered and ready for role assignment.","references":[],"timestamp":"<now-ISO8601>"}
Step 2: Wait for Role Assignment
Poll your inbox for a role-assignment message. When received:
- Update your agent file with the assigned
role - Write a
phase-ackmessage to the orchestrator's inbox - Begin acting according to your role (see Roles Reference)
Step 3: Follow the Loop
Execute the main loop described in Critical Rule: NEVER STOP above. On each iteration:
During prd phase:
- Read the PRD draft from
.swarm/board/ - Write your review based on your role's expertise
- Send
approvalorrevision-requestto orchestrator
During tasks phase:
- Read task assignments from your inbox
- Acknowledge with a
task-updatemessage
During implementation phase:
- Work on your assigned tasks
- Write actual code to the project (not to .swarm/)
- Send
task-updateon start,task-completeon finish - If blocked, send a
discussionmessage to the orchestrator
During review phase:
- If you're a reviewer: review completed code, write feedback
- If you're an implementer: address review feedback, fix issues
During pr phase:
- Acknowledge the PR creation
- Provide any final input if requested
Message Format
Every message is a single JSON line appended to a .jsonl file. Format:
{"id":"<uuid>","from":"<sender-id>","to":"<recipient-id-or-all>","type":"<message-type>","phase":"<current-phase>","content":"<message-text>","references":[],"timestamp":"<ISO8601>"}
To send a message: Append one JSON line to .swarm/messages/{recipient-id}.jsonl
To broadcast: Append to .swarm/messages/broadcast.jsonl
To read messages: Read your inbox file, process only lines you haven't seen before (track line count)
Message Types
| Type | Direction | Purpose |
|---|---|---|
registration |
Worker → Broadcast | Announce presence |
role-assignment |
Orchestrator → Worker | Assign a role |
phase-change |
Orchestrator → Broadcast | Announce phase transition |
phase-ack |
Worker → Orchestrator | Acknowledge phase transition |
task-assignment |
Orchestrator → Worker | Assign a task |
task-update |
Worker → Orchestrator | Report progress |
task-complete |
Worker → Orchestrator | Mark task done |
review-request |
Any → Any | Request review |
review-response |
Any → Any | Provide review feedback |
approval |
Any → Orchestrator | Approve a document or task |
revision-request |
Any → Orchestrator | Request changes |
discussion |
Any → Any | Free-form discussion |
shutdown |
Orchestrator → Broadcast | Swarm is done |
See Protocol Reference for full JSON schemas.
Task System
Tasks live in .swarm/tasks/. The orchestrator creates them during the tasks phase.
index.json — Master list (only orchestrator writes this):
{
"tasks": [
{"id": "task-001", "title": "...", "status": "pending", "assigned_to": null, "blocked_by": []},
{"id": "task-002", "title": "...", "status": "pending", "assigned_to": null, "blocked_by": ["task-001"]}
],
"last_updated": "<ISO8601>"
}
Individual task files (task-001.json, etc.) — contain full details. See Protocol Reference for schema.
Claiming a Task
- Check that no
.swarm/locks/task-{id}.lockfile exists - Create
.swarm/locks/task-{id}.lockcontaining your agent ID - If the file already exists (another agent claimed it), skip and find another task
- Update the task file with your ID and
"status": "in_progress" - Send a
task-updatemessage to the orchestrator
Generating Your Agent ID
Use this format to avoid collisions:
- Orchestrator:
orchestrator-<provider>-1(e.g.,orchestrator-claude-1) - Workers:
worker-<provider>-<N>where N is the count of existing agent files + 1
Determine your provider from your model:
- Claude Code →
claude - Codex →
codex - Cursor →
cursor - Gemini CLI →
gemini - Aider →
aider - Other →
agent
Consensus Rules
- PRD approval: Majority of agents approve → proceed. Max 2 revision rounds. After round 2, orchestrator finalizes and notes unresolved concerns.
- Code review: All designated reviewers must approve before PR phase.
- Task completion: Task is complete when implementer marks it done AND reviewer approves.
Quick Reference
| What | Where |
|---|---|
| Global state | .swarm/state.json |
| Agent registration | .swarm/agents/{id}.json |
| Your inbox | .swarm/messages/{your-id}.jsonl |
| Broadcast channel | .swarm/messages/broadcast.jsonl |
| Board documents | .swarm/board/ |
| Task list | .swarm/tasks/index.json |
| Task details | .swarm/tasks/task-{id}.json |
| Lock files | .swarm/locks/task-{id}.lock |
| PRD template | templates/prd.md |
| Task template | templates/task.md |
| Full protocol | references/PROTOCOL.md |
| Role details | references/ROLES.md |
| Phase details | references/PHASES.md |
| Examples | references/EXAMPLES.md |
Source: BO5AMIS/swarm — distributed by TomeVault.
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核