一键导入
coordinator
Coordinate and monitor other agents — spawn, observe, fix issues
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Coordinate and monitor other agents — spawn, observe, fix issues
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Review pull requests for code quality, security, and correctness
Review pull requests for code quality, security, and correctness
End-to-end shipping workflow — tests, PR creation, review request. Unified pr-create + pr-complete.
Periodic cross-agent learning consolidation — review what worked, what didn't, propagate insights
Break down complex problems through structured analytical frameworks
Persist and recall context across sessions — critical for continuity
| name | coordinator |
| version | 1.0.0 |
| description | Coordinate and monitor other agents — spawn, observe, fix issues |
| uses | ["core/bus","core/memory","core/session"] |
| requires | {"tools":["curl"],"services":["AgentCoordinator"]} |
| security | {"risk_level":"admin","capabilities":["agent:spawn","agent:monitor","agent:terminate","bus:read","bus:write","memory:read","memory:write"],"requires_approval":true} |
Manage and monitor the agent ecosystem. The coordinator spawns agents, observes their work, fixes infrastructure issues, and ensures the multi-agent workflow operates smoothly. The coordinator orchestrates — it does not do the work itself.
This is an HTTP skill (handler: type: http). When coordinator_request is invoked, the executor makes an HTTP request to the Agent Coordinator server. The tool schema in tool.yaml defines the external contract; the executor handles the HTTP communication directly.
Role distinction: This skill is for the coordinator agent — the one managing the ecosystem. Regular agents use coordination/ac-http for their own registration and task management.
When work needs to be done:
While agents are working, check periodically:
Check at the configured monitoring interval (default: every 5 minutes).
When something is wrong:
| Symptom | Diagnosis | Fix |
|---|---|---|
| Agent offline | Crash or session timeout | Restore from checkpoint |
| No heartbeats | Agent hung or crashed | Check session, restart if needed |
| Messages not processed | Agent not polling bus | Verify listens_to in identity, send nudge |
| Task stuck (no progress) | Agent blocked or confused | Check memory/logs, send clarification |
Escalation levels:
The typical development workflow:
work channel for developer agent## Coordinator Status
### Agents
| Agent | Status | Current Task | Last Heartbeat |
|-------|--------|-------------|----------------|
| [name] | [active/idle/offline] | [task or none] | [timestamp] |
### Tasks
| Task | Assigned To | Status | Age |
|------|------------|--------|-----|
| [description] | [agent] | [claimed/in-progress/done] | [duration] |
### Issues
- [issue description] — [action taken]
review_completed message. If the bus message is the wrong type, the developer never sees it.base_url, not a hardcoded URL. Keep infrastructure details in config defaults.Coordinator work is complete when: