Token导航 LogoToken导航TokenDH.com
前端设计执行命令github未标认证来源可访问许可证需确认审计提醒

agent-managerAgent 经理

Agent Skill

agent-manager 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

848

周安装

35

GitHub Stars

23

下载量

277
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:agent-manager(Agent 经理)
来源仓库:https://github.com/fractalmind-ai/agent-manager-skill
仓库路径:skills/agent-manager
安装命令:
npx skills add https://github.com/fractalmind-ai/agent-manager-skill --skill agent-manager
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/fractalmind-ai/agent-manager-skill --skill agent-manager

简介

agent-manager 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息。

  • 适合在 Codex、Claude、Cursor、Gemini CLI 中围绕仓库状态和协作事项进行整理。
  • 可通过 npx skills add 命令从指定仓库安装并使用。
  • 安装前需确认权限范围、维护状态及是否触发联网或文件操作。
  • 建议结合原始 README 核验具体用法和功能边界。

SKILL.md

Agent Manager

Employee agent orchestration system for managing AI agents in tmux sessions. A simple, dependency-light alternative to CAO.

Quick Start

# Project-local install path varies by tool. If `.agent/skills/` doesn't exist, try `.claude/skills/`.
# List all agents
python3 .agent/skills/agent-manager/scripts/main.py list
python3 .claude/skills/agent-manager/scripts/main.py list

# (use the same path you chose above for the remaining commands)
# Start dev agent
python3 .agent/skills/agent-manager/scripts/main.py start dev

# Monitor output (live)
python3 .agent/skills/agent-manager/scripts/main.py monitor dev --follow

# Assign task
python3 .agent/skills/agent-manager/scripts/main.py assign dev <<EOF
Fix the login bug in the auth module
EOF

# Stop agent
python3 .agent/skills/agent-manager/scripts/main.py stop dev

Command Path Parity (Docs Baseline)

For consistency with README.md and runbook examples, define one CLI alias and reuse it in your session:

# Installed skill path (pick one that exists)
CLI="python3 .agent/skills/agent-manager/scripts/main.py"
# CLI="python3 .claude/skills/agent-manager/scripts/main.py"

# If operating from a cloned repo instead of installed skill:
# CLI="python3 agent-manager/scripts/main.py"

$CLI doctor
$CLI list
$CLI status EMP_0001

Core Concepts

Agent Configuration

Agents are defined in agents/EMP_*.md files with YAML frontmatter:

---
name: dev
description: Dev Agent (project-agnostic)
working_directory: ${REPO_ROOT}
launcher: ${REPO_ROOT}/projects/claude-code-switch/ccc
launcher_args:
  - cp
  - --dangerously-skip-permissions
skills:
  - review-pr
  - bsc-contract-development
---

# DEV AGENT

## Role and Identity
You are the Dev Agent...

Fields:

  • name: Agent identifier (dev, qa)
  • description: Agent description
  • enabled: Whether agent can be started (default: true, set false to disable)
  • working_directory: Default working directory (supports ${REPO_ROOT})
  • launcher: Full path OR provider name
  • launcher_args: Arguments for launcher
  • launcher_config: Optional launcher/provider-specific startup config
  • skills: Array of skill names from .agent/skills/ (optional, injected at start)
  • schedules: Array of scheduled jobs (optional, see Scheduling section)
  • tmux: Optional tmux layout metadata (layout + target pane)

Tmux Sessions

Each agent runs in a dedicated tmux session (agent-{name}):

  • Easy monitoring: tmux capture-pane -t agent-dev
  • Direct interaction: tmux attach -t agent-dev
  • Clean separation: No process pollution

Optional: Tmux Layouts

You can auto-create a tmux layout and launch the agent in a specific pane:

tmux:
  layout:
    split: h
    panes:
      - {}
      - split: v
        panes:
          - {}
          - {}
  target_pane: "1.1"

Notes:

  • split: h (left/right) or v (top/bottom). horizontal/vertical also work.
  • target_pane: dot-separated path of 0/1 indexes into the layout tree. 0 = left/top, 1 = right/bottom. "1.1" means right -> bottom.
  • If tmux.layout is set, tmux.target_pane is required.

Launcher Types

Full path: Local Claude Code launcher

launcher: ${REPO_ROOT}/projects/claude-code-switch/ccc
launcher_args: ["cp", "--dangerously-skip-permissions"]

Provider name: CAO provider (optional integration)

launcher: droid
launcher_args: []

Provider name: OpenAI Codex CLI

launcher: codex
launcher_args:
  - --model=gpt-5.2
launcher_config:
  model_instructions_file: ${REPO_ROOT}/agents/EMP_0001/prompt/shade-main-model.md

launcher_config is the generic escape hatch for launcher/provider-specific startup config. Each CLI provider adapts this flat mapping into its own startup flags (for Codex, each entry becomes -c key=value).

Reserved main agents default to the bundled skill prompt at agent-manager/.codex/main-codex-model.md when launcher: codex is used and no explicit launcher_config.model_instructions_file override is provided in the workspace agent config.

Note: For scheduled jobs, agent-manager will best-effort auto-dismiss Codex's first-run/upgrade model selection prompt to keep cron runs non-interactive.

Commands

All examples below assume you already defined $CLI in Command Path Parity (Docs Baseline).

list - List All Agents

Show all configured agents and their status.

$CLI list              # All agents
$CLI list --running    # Only running

Output:

📋 Agents:

✅ Running dev (session: agent-dev)
   Description: Dev Agent (project-agnostic)
   Working Dir: /home/user/repo
   Skills: review-pr, bsc-contract-development

⭕ Stopped qa
   Description: QA Agent in a multi-agent system
   Working Dir: /home/user/repo/projects/CloudBank-feat-invite-code

⛔ Disabled old-dev
   Description: Legacy Dev Agent (deprecated)
   Working Dir: /home/user/repo

start - Start an Agent

Start an agent in a tmux session.

$CLI start dev                      # Use default working_dir
$CLI start dev --working-dir /path   # Override working dir
  • Rejects if already running (one agent, one terminal)
  • Rejects if agent is disabled (enabled: false in config)
  • Loads skills and injects as system prompt
  • Session named agent-{name}

stop - Stop a Running Agent

Stop (kill) an agent's tmux session.

$CLI stop dev

status - Show Agent Status

Show one agent's runtime snapshot, including running state, runtime state, and the most recent heartbeat marker/event.

$CLI status dev

monitor - Monitor Agent Output

View agent output from tmux session.

$CLI monitor dev              # Last 100 lines
$CLI monitor dev -n 500       # Last 500 lines
$CLI monitor dev --follow     # Live monitoring (Ctrl+C to stop)

send - Send Message to Agent

Send a message/command to a running agent.

$CLI send dev "Please run tests"
$CLI send dev --no-enter "Draft message only"

By default, send submits the message immediately (Enter is sent automatically). Use --no-enter to type without submitting.

assign - Assign Task to Agent

Assign a task to an agent (starts if not running).

# From stdin
$CLI assign dev <<EOF
🎯 Task: Fix the login bug

1. Reproduce the issue
2. Identify root cause
3. Implement fix
4. Add tests
EOF

# From file
$CLI assign dev --task-file task.md

assign submits automatically (Enter is sent by default), so no manual tmux Enter step is required.

Disabling Agents

Agents can be temporarily disabled to prevent them from being started (useful for maintenance, testing, or decommissioning).

Disable an Agent

Add enabled: false to the agent's YAML frontmatter:

---
name: dev
description: Dev Agent (project-agnostic)
enabled: false  # ← Agent cannot be started
working_directory: ${REPO_ROOT}
launcher: ${REPO_ROOT}/projects/claude-code-switch/ccc
---

Behavior

When an agent is disabled:

  • list command shows "Disabled" status
  • ⚠️ start command is rejected with error message
  • schedule sync skips all schedules for the disabled agent
  • Running sessions are NOT automatically stopped (manual stop required)

To re-enable: Set enabled: true or remove the field (defaults to true)

Use Cases

  • Maintenance: Temporarily disable an agent while updating its configuration
  • Testing: Prevent a scheduled agent from running during testing
  • Decommissioning: Mark an agent as obsolete before removing its file

Scheduling

Agents can be configured to run automatically on a schedule using cron expressions.

Schedule Configuration

Add a schedules array to the agent's YAML frontmatter:

---
name: dev
description: Dev Agent
working_directory: ${REPO_ROOT}
launcher: ${REPO_ROOT}/projects/claude-code-switch/ccc
launcher_args:
  - cp
  - --dangerously-skip-permissions
skills:
  - bsc-contract-development

schedules:
  - name: daily-standup
    cron: "0 9 * * 1-5"
    task: |
      Review GitHub issues, prioritize today's work
    max_runtime: 30m

  - name: code-review
    cron: "0 14 * * 1-5"
    task_file: ${REPO_ROOT}/tasks/templates/code-review.md
    max_runtime: 2h

  - name: weekly-report
    cron: "0 17 * * 5"
    task: |
      Generate weekly progress report and commit to docs/
    max_runtime: 1h
    enabled: true
---

Schedule Fields:

FieldTypeRequiredDescription
namestringUnique job identifier
cronstringCron expression (e.g., 0 9 * * 1-5)
taskstringInline task description
task_filestringPath to task file (supports ${REPO_ROOT})
max_runtimestringMaximum runtime (e.g., 30m, 2h, 8h)
enabledboolDefault: true
Note: Either task or task_file must be provided.

Schedule Commands

schedule list - List All Scheduled Jobs

$CLI schedule list

Output:

📅 Scheduled Jobs:

dev (EMP_0001):
  ✓ daily-standup         0 9 * * 1-5          (30m)
  ✓ code-review           0 14 * * 1-5         (2h)
  ✓ weekly-report         0 17 * * 5           (1h)

qa (EMP_0002):
  ✓ nightly-tests         0 2 * * *            (4h)

schedule sync - Sync Schedules to Crontab

Synchronize all agent schedules to the system crontab.

# Preview changes (dry run)
$CLI schedule sync --dry-run

# Apply changes
$CLI schedule sync

This generates crontab entries like:

# === agent-manager schedules (auto-generated) ===
# dev (EMP_0001)
# daily-standup
0 9 * * 1-5 cd /path/to/repo && python3 /absolute/path/to/agent-manager/scripts/main.py schedule run dev --job daily-standup >> /tmp/agent-emp-0001-daily-standup.log 2>&1
# === end agent-manager schedules ===

schedule run - Run a Scheduled Job Manually

Manually trigger a scheduled job (useful for testing).

$CLI schedule run dev --job daily-standup

# Override timeout
$CLI schedule run dev --job daily-standup --timeout 1h

Heartbeat

Heartbeat is a special type of periodic job that sends a standard check-in message to running agents. Unlike schedules (which can have multiple jobs per agent), each agent can have 0 or 1 heartbeat configuration.

Heartbeat Configuration

Add a heartbeat dict to the agent's YAML frontmatter:

---
name: dev
description: Dev Agent
working_directory: ${REPO_ROOT}
launcher: codex
launcher_args:
  - --model=gpt-4.7
  - --dangerously-bypass-approvals-and-sandbox

heartbeat:
  cron: "*/30 * * * *"  # Every 30 minutes
  max_runtime: 5m
  session_mode: auto     # restore | auto | fresh
  mode: normal           # normal (use `timer` for delayed rescue; `full_speed` is legacy)
  enabled: true
---

Heartbeat Fields:

FieldTypeRequiredDescription
cronstringCron expression (e.g., */30 * * * *)
max_runtimestringMaximum runtime (e.g., 5m, 10m)
session_modestringSession policy: restore (default), auto (rollover when context <25%), fresh (always rollover after handoff)
modestringHeartbeat trigger mode. normal is the only active path. full_speed is a deprecated compatibility value that only preserves legacy Codex hook cleanup/readback during start; timer-driven follow-up is the supported replacement.
auto_starvation_skip_thresholdintauto mode only. Default 3; set 0 to disable the forced-dispatch starvation bypass after consecutive preflight skips
enabledboolDefault: true

full_speed should now be treated as a legacy compatibility marker, not a canonical execution path. If an older Codex Stop hook is still present, start will clean it up; new delayed follow-up / rescue flows should use timer.

Heartbeat vs Schedules

FeatureHeartbeatSchedules
Per agent0-1 heartbeat0-N schedules
Task contentFixed (standard check-in)Custom per job
BehaviorOnly checks running agentsStarts agent if needed
Use casePeriodic health checksTask automation

Heartbeat Commands

heartbeat list - List All Heartbeat Jobs

$CLI heartbeat list

Output:

💓 Heartbeats:

dev (EMP_0001):
  ✓ heartbeat           */30 * * * *         (5m session:auto)

heartbeat sync - Sync Heartbeats to Crontab

Heartbeats and schedules are synced together to the system crontab.

# Preview changes (dry run)
$CLI heartbeat sync --dry-run

# Apply changes
$CLI heartbeat sync

This generates crontab entries like:

# === agent-manager schedules (auto-generated) ===
# dev (EMP_0001)
# heartbeat [HB]
*/30 * * * * cd /path/to/repo && python3 /absolute/path/to/agent-manager/scripts/main.py heartbeat run EMP_0001 >> /path/to/.crontab_logs/agent-emp-0001-heartbeat.log 2>&1
# === end agent-manager schedules ===

heartbeat run - Run a Heartbeat Manually

Manually trigger a heartbeat (useful for testing).

$CLI heartbeat run EMP_0001

# Override timeout
$CLI heartbeat run EMP_0001 --timeout 1m

Heartbeat behavior:

  • Skips if agent is disabled
  • Skips if agent is not running (does NOT start the agent)
  • Sends standard heartbeat message to the agent
  • Optional session rollover via session_mode (handoff first, then fresh session)
  • Waits for response (up to max_runtime)
  • In auto mode, stale pending heartbeats can schedule or trigger rescue via the timer-backed recovery path

timer - Schedule Delayed Actions

Use timer for one-shot delayed actions without cron:

# Run one heartbeat in 5 seconds
$CLI timer heartbeat main --delay 5s

# Schedule one heartbeat rescue in 5 seconds
$CLI timer rescue main --delay 5s --timeout 8m --reason auto_pending_heartbeat_rescue

# Run an arbitrary agent-manager command in 5 seconds
$CLI timer command --delay 5s -- heartbeat run main --timeout 8m

# Inspect recent timers
$CLI timer list

Each run appends structured JSONL audit events to:

.claude/state/agent-manager/heartbeat-audit/{agent_id}.jsonl

Event fields (standardized for observability):

  • timestamp
  • agent_id
  • hb_id
  • stage (standard stage name, default heartbeat_attempt)
  • result (success / failure / pending)
  • duration (milliseconds, alias of duration_ms)
  • send_status
  • ack_status
  • duration_ms
  • context_left
  • failure_type
  • session_mode
  • reason_code
  • attempt
  • recovery_action
  • reason_code

Failure classification (failure_type) includes:

  • send_fail
  • no_ack
  • timeout
  • blocked

heartbeat trace - Query Heartbeat Audit Logs

# Recent events
$CLI heartbeat trace

# Filter by heartbeat id
$CLI heartbeat trace --hb-id 20260209-120001

# Filter by agent + time range (UTC)
$CLI heartbeat trace   --agent EMP_0001   --since 2026-02-09T00:00:00Z   --until 2026-02-10T00:00:00Z

# Output JSON
$CLI heartbeat trace --agent EMP_0001 --json

heartbeat slo - Daily/Weekly SLO Summary

# Daily summary (default)
$CLI heartbeat slo

# Weekly summary for one agent
$CLI heartbeat slo --window weekly --agent EMP_0001

# Explicit time window + JSON
$CLI heartbeat slo   --since 2026-02-01T00:00:00Z   --until 2026-02-08T00:00:00Z   --json

Built-in SLO checks:

  • Success rate target: >= 99%
  • Timeout rate target: <= 2%
  • Recovery p95 target: <= 120000ms

Standalone summary script (same metrics):

python3 scripts/heartbeat_slo.py --window daily
python3 scripts/heartbeat_slo.py --window weekly --agent EMP_0001 --json

Standard Heartbeat Message

The heartbeat sends this message to the agent:

Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.

Agents should respond with HEARTBEAT_OK if nothing needs attention, or take action based on their HEARTBEAT.md file contents.

Skills Integration

Agents can reference skills from .agent/skills/:

skills:
  - review-pr
  - bsc-contract-development
  - cao

When the agent starts, skill contents are injected as system prompt:

## Available Skills

### review-pr
Code review skill for GitHub PRs and local changes...

### bsc-contract-development
Comprehensive BSC smart contract development expertise...

Available Skills:

  • bsc-contract-development - BSC smart contract development
  • cao - CLI Agent Orchestrator
  • collab-pr-fix-loop - QA→Dev→QA PR iteration
  • review-pr - Code review for PRs
  • skill-creator - Creating new skills

Architecture

.agent/skills/agent-manager/
├── SKILL.md                    # This file
├── scripts/
│   ├── main.py                 # CLI entry point
│   ├── heartbeat_slo.py        # Heartbeat SLO summary script
│   ├── agent_config.py         # Agent file parser
│   ├── tmux_helper.py          # Tmux wrapper
│   └── schedule_helper.py      # Crontab management
├── providers/
│   └── __init__.py             # CLI provider configs
└── references/
    └── task_templates.md       # Optional task templates

Design Principles

  1. Zero CAO Dependency: Only tmux + Python required
  2. Provider Pattern Inspiration: Learn from CAO but implement simply
  3. Tmux-Native: Each agent in its own tmux session
  4. YAML Frontmatter: Leverage existing agent file format
  5. Environment Variables: Handle ${REPO_ROOT} expansion
  6. One Agent, One Terminal: Reject duplicate starts

Comparison with CAO

FeatureCAOAgent Manager
DependenciesCAO server, uvx, requeststmux, Python only
ComplexityHigh (HTTP API, providers)Low (direct tmux)
Session MgmtCAO serverNative tmux
MonitoringHTTP API callsNative tmux
ExtensibilityProvider systemDirect script editing
InstallationCAO server setupNo server needed
Use CaseComplex workflowsSimple agent management

Error Handling

  • tmux not installed: Clear error with install command
  • Agent not found: Lists available agents
  • Already running: Prompts to stop first
  • Not running: Prompts to start first

Runbook Checklist

For operations handoff and incident response, use:

  • agent-manager/docs/runbook-checklist.md

It includes:

  • 30-minute newcomer self-check path
  • heartbeat no-ack troubleshooting SOP
  • stuck-session recovery SOP
  • CI/QA merge-gate checklist and evidence template

Advanced Usage

Direct Tmux Interaction

# Attach to agent session (interactive)
tmux attach -t agent-dev

# Detach from session: Ctrl+b, then d

# Capture output manually
tmux capture-pane -p -t agent-dev -S -100

# List all agent sessions
tmux ls | grep ^agent-

Workflow Example

# Morning: Start agents
$CLI start dev
$CLI start qa

# Assign task to dev
$CLI assign dev <<EOF
Implement the user profile feature:
1. Profile update API
2. Profile view component
3. Integration tests
EOF

# Quick runtime snapshot
$CLI status dev

# Monitor progress
$CLI monitor dev --follow

# Send clarification if needed
$CLI send dev "Please add validation for email format"

# After dev completes, assign to QA
$CLI assign qa <<EOF
Review the user profile feature:
- Security check
- Edge cases
- Test coverage
EOF

# Evening: Stop agents
$CLI stop dev
$CLI stop qa

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

35.17%
按下载量换算97

Claude

31.61%
按下载量换算88

Cursor

18.74%
按下载量换算52

Gemini CLI

10.21%
按下载量换算28

安全审计

Gen Agent Trust Hub

可疑

Socket

可疑

Snyk

可疑

权限和风险

执行命令

安装流程涉及命令执行,可能通过 npx skills add https://github.com/fractalmind-ai/agent-manager-skill --skill agent-manager 联网下载 Skill 或依赖。用户安装前应确认命令来源、仓库内容和执行环境。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills