Token导航 LogoToken导航TokenDH.com
研究检索敏感数据github未标认证来源可访问许可证需确认审计提醒

autonomous-dispatcher自主调度员

Agent Skill

autonomous-dispatcher 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

1,223

周安装

52

GitHub Stars

15

下载量

428
CodexClaudeCursorGemini CLI

安装说明

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

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

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

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

命令行安装

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

skills.shnpx skills
npx skills add https://github.com/zxkane/autonomous-dev-team --skill autonomous-dispatcher

简介

GitHub Issue 扫描与本地任务分发调度系统。

  • 适合需要批量处理 Issues 并自动分配开发任务的场景。
  • 仅读取标签和评论信息,不会修改源代码或推送分支。
  • 必须使用 GitHub App Token 而非用户 Token 进行身份验证。
  • 建议在私有仓库中限制 autonomous 标签的添加权限以确保安全。

SKILL.md

Autonomous Dev Team Dispatcher

Scan GitHub issues and dispatch dev/review tasks locally.

Security Note: This dispatcher processes GitHub issue content as input. In public repositories, issue content is untrusted — anyone can create issues. Ensure the autonomous label can only be applied by trusted maintainers (use GitHub branch rulesets or organizational policies). The dispatcher itself only reads labels/comments and spawns local processes — it does NOT modify source code or push to branches.

GitHub Authentication — USE APP TOKEN, NOT USER TOKEN

CRITICAL: All gh CLI calls MUST use a GitHub App token, NOT the default user token.

Before running any gh command, generate and export the App token using the shared script at scripts/gh-app-token.sh:

# Source the shared token generator
source "${PROJECT_DIR}/scripts/gh-app-token.sh"

# Generate token for the dispatcher's GitHub App
GH_TOKEN=$(get_gh_app_token "$DISPATCHER_APP_ID" "$DISPATCHER_APP_PEM" "$REPO_OWNER" "$REPO_NAME") || {
  echo "FATAL: Failed to generate GitHub App token" >&2
  exit 1
}
if [[ -z "$GH_TOKEN" ]]; then
  echo "FATAL: GitHub App token is empty" >&2
  exit 1
fi
export GH_TOKEN

The DISPATCHER_APP_PEM env var must point to the App's private key PEM file. If not set, provide the path explicitly.

This ensures all issue comments, label changes, and API calls appear as the configured GitHub App bot instead of a personal user account. The token is valid for 1 hour and scoped to the target repo only.

DO NOT skip this step. If GH_TOKEN is not set, gh will fall back to the user's personal token, which is incorrect.

Environment Variables

  • REPO: GitHub repo in owner/repo format (e.g., myorg/myproject)
  • PROJECT_DIR: Absolute path to the project root on the local machine
  • MAX_CONCURRENT: Max parallel tasks (default: 5)
  • MAX_RETRIES: Max dev retry attempts before marking issue as stalled (default: 3)
  • PROJECT_ID: Project identifier for log/PID files (default: project)
  • DISPATCHER_APP_ID: GitHub App ID for the dispatcher bot
  • DISPATCHER_APP_PEM: Path to the GitHub App private key PEM file

Local Dispatch Helper Script

CRITICAL: All task dispatches (dev-new, dev-resume, review) MUST use the helper script scripts/dispatch-local.sh in the project root's scripts/ directory. The script handles:

  • Background process spawning via nohup
  • Input validation (numeric issue numbers, safe session IDs)
  • Config loading from scripts/autonomous.conf

Usage:

# PROJECT_DIR is the absolute path to the project root

# For new dev task:
bash "$PROJECT_DIR/scripts/dispatch-local.sh" dev-new ISSUE_NUM

# For review task:
bash "$PROJECT_DIR/scripts/dispatch-local.sh" review ISSUE_NUM

# For resume dev task:
bash "$PROJECT_DIR/scripts/dispatch-local.sh" dev-resume ISSUE_NUM SESSION_ID

DO NOT construct dispatch commands manually. Always use the dispatch-local.sh script.

DO NOT commit or push code to the target repository. The dispatcher's role is strictly:

  1. Read issue labels and comments via GitHub API
  2. Update labels and post comments via GitHub API
  3. Dispatch local processes using the helper script

All code changes happen via the autonomous-dev/review scripts. The dispatcher MUST NOT modify source files or push to any branch (especially main).

Dispatch Logic

When triggered (cron every 5 minutes), execute the following steps IN ORDER.

Important: Maintain a JUST_DISPATCHED array to track issue numbers dispatched in the current cycle. This prevents Step 5 from false-positive stale detection on freshly dispatched processes whose PID files haven't been written yet.

# Initialize at the start of each dispatch cycle
JUST_DISPATCHED=()

Step 1: Check Concurrency

Count issues with labels in-progress OR reviewing:

ACTIVE=$(gh issue list --repo "$REPO" --state open --limit 100 \
  --label "autonomous" --json labels \
  -q '[.[] | select(.labels[].name | IN("in-progress","reviewing"))] | length')

If ACTIVE >= MAX_CONCURRENT (default 5), STOP. Log "Concurrency limit reached (ACTIVE/MAX_CONCURRENT)" and exit.

Step 2: Scan for New Tasks

Find issues with autonomous label but NO state labels:

gh issue list --repo "$REPO" --state open --limit 100 \
  --label "autonomous" --json number,labels,title \
  -q '[.[] | select(
    [.labels[].name] | (
      contains(["in-progress"]) or
      contains(["pending-review"]) or
      contains(["reviewing"]) or
      contains(["pending-dev"]) or
      contains(["stalled"]) or
      contains(["approved"])
    ) | not
  )]'

For each found issue (respecting concurrency limit):

1. Check Dependencies — before dispatching, read the issue body and look for a ## Dependencies section. Parse issue references (#N) from that section. For each referenced issue, check if it is closed:

# Extract dependency issue numbers from the issue body
DEPS=$(gh issue view ISSUE_NUM --repo "$REPO" --json body -q '.body' \
  | sed -n '/^## Dependencies/,/^## /p' \
  | grep -oP '#\K[0-9]+')

# Check if all dependencies are closed
BLOCKED=false
for DEP in $DEPS; do
  STATE=$(gh issue view "$DEP" --repo "$REPO" --json state -q '.state')
  if [ "$STATE" != "CLOSED" ]; then
    BLOCKED=true
    break
  fi
done

if [ "$BLOCKED" = true ]; then
  # Skip this issue — dependency not yet resolved
  continue
fi

If any dependency issue is still open, skip this issue silently (do not add labels or comment). It will be picked up in the next dispatch cycle after its dependencies are resolved.

2. Add in-progress label 3. Comment: Dispatching autonomous development... 4. Dispatch via helper script:

bash "$PROJECT_DIR/scripts/dispatch-local.sh" dev-new ISSUE_NUM

5. Track dispatched issue: JUST_DISPATCHED+=(ISSUE_NUM) 6. Re-check concurrency after each dispatch

Step 3: Scan for Review Tasks

Find issues with autonomous + pending-review (no reviewing):

gh issue list --repo "$REPO" --state open --limit 100 \
  --label "autonomous,pending-review" --json number,labels \
  -q '[.[] | select([.labels[].name] | contains(["reviewing"]) | not)]'

For each found issue (respecting concurrency limit): 1. Remove pending-review, add reviewing 2. Comment: Dispatching autonomous review... 3. Dispatch via helper script:

bash "$PROJECT_DIR/scripts/dispatch-local.sh" review ISSUE_NUM

4. Track dispatched issue: JUST_DISPATCHED+=(ISSUE_NUM)

Step 4: Scan for Pending-Dev (Resume)

Find issues with autonomous + pending-dev:

gh issue list --repo "$REPO" --state open --limit 100 \
  --label "autonomous,pending-dev" --json number,labels,comments

For each found issue (respecting concurrency limit):

1. Check retry count — before dispatching, count BOTH failed Agent Session Report (Dev) comments (exit code ≠ 0) AND dispatcher-detected crash comments. Only count failures that occurred after the last stalled→unstalled transition (i.e., after the most recent "Marking as stalled" comment). This ensures that removing the stalled label resets the retry counter. Successful dev completions (exit code 0) that were sent back by review do NOT count as retries:

# Find the timestamp of the last "Marking as stalled" comment (retry counter cutoff).
# If the issue was never stalled, use epoch (1970-01-01T00:00:00Z) to count all comments.
LAST_STALLED_AT=$(gh issue view ISSUE_NUM --repo "$REPO" --json comments \
  -q '[.comments[] | select(.body | test("Marking as stalled"))] | last | .createdAt // "1970-01-01T00:00:00Z"')

# Count failed agent session reports (only after last stalled cutoff)
AGENT_FAILURES=$(gh issue view ISSUE_NUM --repo "$REPO" --json comments \
  -q "[.comments[] | select((.createdAt > \"${LAST_STALLED_AT}\") and (.body | test(\"Agent Session Report \\\\(Dev\\\\)\")) and (.body | test(\"Exit code: 0\") | not))] | length")

# Count dispatcher-detected crashes (only after last stalled cutoff).
# The regex is anchored on explicit Step 5 crash preambles. A dev process that
# exits after producing a PR is forward progress (handed to review as
# "Dev process exited (PR found)") and MUST NOT match this regex — do not add
# a broad `crashed` or `exited` alternative here.
DISPATCHER_CRASHES=$(gh issue view ISSUE_NUM --repo "$REPO" --json comments \
  -q "[.comments[] | select((.createdAt > \"${LAST_STALLED_AT}\") and (.body | test(\"Task appears to have crashed \\\\(no PR found\\\\)|process not found\")))] | length")

RETRY_COUNT=$((AGENT_FAILURES + DISPATCHER_CRASHES))
MAX_RETRIES="${MAX_RETRIES:-3}"

if [ "$RETRY_COUNT" -ge "$MAX_RETRIES" ]; then
  # Issue has exceeded retry limit — mark as stalled
  gh issue edit ISSUE_NUM --repo "$REPO" \
    --remove-label "pending-dev" \
    --add-label "stalled"
  gh issue comment ISSUE_NUM --repo "$REPO" \
    --body "Issue has exceeded the maximum retry limit ($MAX_RETRIES failed attempts: $AGENT_FAILURES agent failures + $DISPATCHER_CRASHES dispatcher-detected crashes). Marking as stalled. @${REPO_OWNER} please investigate manually."
  continue
fi

If combined retry count exceeds MAX_RETRIES (default 3), add stalled label, remove pending-dev, post a comment, and skip this issue. When a user removes the stalled label to re-dispatch, the retry counter automatically resets because only crashes after the latest "Marking as stalled" comment are counted.

2. Extract latest dev session ID from issue comments (search for Dev Session ID: — do NOT match Review Session ID:):

SESSION_ID=$(gh issue view ISSUE_NUM --repo "$REPO" --json comments \
  -q '[.comments[].body | capture("Dev Session ID: `(?P<id>[a-zA-Z0-9_-]+)`"; "g") | .id] | last // empty')

3. Remove pending-dev, add in-progress 4. Comment: Resuming development (session: SESSION_ID)... 5. Dispatch via helper script:

bash "$PROJECT_DIR/scripts/dispatch-local.sh" dev-resume ISSUE_NUM SESSION_ID

6. Track dispatched issue: JUST_DISPATCHED+=(ISSUE_NUM)

Step 5: Stale Detection

Find issues with in-progress or reviewing that may be stuck.

Skip freshly dispatched issues: Before checking any issue, verify it was NOT dispatched in the current cycle. Issues in JUST_DISPATCHED must be skipped — their PID files may not exist yet.

# Skip issues dispatched in this cycle
if [[ " ${JUST_DISPATCHED[*]} " == *" ISSUE_NUM "* ]]; then
  # Skip — just dispatched this cycle, PID file may not exist yet
  continue
fi

For each remaining issue, check if the agent process is still alive locally. Use the correct PID file prefix based on the issue's current label:

  • in-progress issues use PID file: /tmp/agent-${PROJECT_ID}-issue-ISSUE_NUM.pid
  • reviewing issues use PID file: /tmp/agent-${PROJECT_ID}-review-ISSUE_NUM.pid
# For in-progress issues:
kill -0 $(cat /tmp/agent-${PROJECT_ID}-issue-ISSUE_NUM.pid 2>/dev/null) 2>/dev/null && echo ALIVE || echo DEAD

# For reviewing issues:
kill -0 $(cat /tmp/agent-${PROJECT_ID}-review-ISSUE_NUM.pid 2>/dev/null) 2>/dev/null && echo ALIVE || echo DEAD

If DEAD and issue still has in-progress, check whether a PR exists before deciding the transition:

PR_EXISTS=$(gh pr list --repo "$REPO" --state open --json number,body \
  -q "[.[] | select(.body | test(\"#ISSUE_NUM[^0-9]\") or test(\"#ISSUE_NUM$\"))] | length")

if [ "$PR_EXISTS" -gt 0 ]; then
  # PR exists — forward progress. Review agent can assess the work.
  # Comment: "Dev process exited (PR found). Moving to pending-review for assessment."
  # Remove `in-progress`, add `pending-review`
  # (Wording avoids "crashed" so the Step 4 retry-counter regex does not match it.)
else
  # No PR — dev agent didn't finish, retry development
  # Comment: "Task appears to have crashed (no PR found). Moving to pending-dev for retry."
  # Remove `in-progress`, add `pending-dev`
fi

If DEAD and issue still has reviewing:

  1. Comment: Review process appears to have crashed. Moving to pending-dev for retry.
  2. Remove reviewing, add pending-dev

Cron Configuration (OpenClaw)

openclaw cron add \
  --name "Autonomous Dispatcher" \
  --cron "*/5 * * * *" \
  --session isolated \
  --message "Run the autonomous-dispatcher skill. Check GitHub issues and dispatch tasks." \
  --announce

Label Definitions

LabelColorDescription
autonomous#0E8A16Issue should be processed by autonomous pipeline
in-progress#FBCA04Agent is actively developing
pending-review#1D76DBDevelopment complete, awaiting review
reviewing#5319E7Agent is actively reviewing
pending-dev#E99695Review failed, needs more development
approved#0E8A16Review passed. PR merged (or awaiting manual merge if no-auto-close present)
no-auto-close#d4c5f9Used with autonomous — skip auto-merge after review passes, requires manual approval
stalled#B60205Issue exceeded max retry attempts; requires manual investigation

Model Strategy

TaskModelRationale
Development (autonomous-dev.sh)Opus (default)Complex coding, architecture decisions
Review (autonomous-review.sh)Sonnet (--model sonnet)Checklist verification, avoids Opus quota contention

适合场景

01

用户想查找某类 Agent Skill 时

02

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

03

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

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

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

能力 4

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

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

平台分布

Codex

34.82%
按下载量换算149

Claude

28.44%
按下载量换算122

Cursor

18.87%
按下载量换算81

Gemini CLI

7.93%
按下载量换算34

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

可疑

权限和风险

敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

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

来源信息

继续浏览同类 Skills