Token导航 LogoToken导航

Agent Skill · 运维和基础设施

autonomous-orchestration(自主编排)

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

autonomous-orchestration 是运维和基础设施类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为执行命令;许可证为 MIT,第三方扫描有提醒项,按安装量在运维和基础设施类的 2,449 个 Skill 里排第 1,765。

总安装 408周安装 17GitHub Stars 6下载 136核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT

安装方式

通过对话安装

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

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

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/troykelly/claude-skills --skill autonomous-orchestration

这个 Skill 是做什么的

运维和基础设施类 Skill 处理部署、监控、日志和云资源,多数需要较高的执行权限。

多 Issue 并行处理的长期自主工作编排系统。autonomous-orchestration 属于运维和基础设施类 Skill,可作为该场景下的辅助能力补充。适合需要同时推进多个独立任务的大型项目开发场景。基于 Task 工具创建并行 worker 并通过 TaskOutput 监控进度。

依赖 GitHub CLI 和特定 worker 协议技能协同工作。使用前应配置好 CI 监控和 GitHub 身份验证等前置条件。

来源仓库内路径:skills/autonomous-orchestration

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/troykelly/claude-skills --skill autonomous-orc…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要执行命令,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

autonomous-orchestration 怎么安装?

在终端执行 npx skills add https://github.com/troykelly/claude-skills --skill autonomous-orchestration。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

autonomous-orchestration 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

autonomous-orchestration 需要什么权限?

权限级别是执行命令。安装流程涉及命令执行,可能通过 npx skills add https://github.com/troykelly/claude-skills --skill autonomous-orchestration;npx skills add troykelly/claude-skills --skill "autonomous-orchestration" 联网下载 Skill 或依赖。用户安装前应确认命令来源、仓库内容和执行环境。

autonomous-orchestration 是免费的吗?

来源标注的许可证是 MIT。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

autonomous-orchestration 用的人多吗?

公开数据是累计安装 408 次,近一周安装 17 次,下载 136 次,GitHub 6 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

autonomous-orchestration 安全吗?

第三方扫描有提醒项,说明存在需要人工确认的行为。安装前请打开源码看清它读了什么、联网到哪里。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 3 个目录同时收录,说明这个 Skill 流传比较广。
  • 许可证明确为 MIT,商用和分发边界好判断。

先想清楚的地方

  • 需要执行命令,装到常用环境前要先评估影响面。
  • 第三方扫描存在提醒项或未通过项,需要人工逐条确认。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理运维和基础设施类任务、又不想每次都手写提示词的人。

不太适合

  • 不能接受 Skill 在你机器上执行命令的人。
  • 需要厂商级技术支持和 SLA 的生产系统。

运维和基础设施类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
brainstorming

头脑风暴 · Codex、Claude

3,148,776173,131操作浏览器MIT通过
copywriting

文案写作 · Codex、Claude

1,996,72425,583需要联网MIT通过
openclaw-secure-linux-cloud

OpenClaw secure linux cloud 命令行 · Codex、Claude

1,853,08840接触敏感数据未明确未通过
xget

xget 命令行 · Codex、Claude

1,799,28040执行命令未明确未通过
requesting-code-review

代码审查请求 · Codex、Claude

1,590,144173,103权限未标注MIT通过
autonomous-orchestration

自主编排 · 本页

4086执行命令MIT有提醒

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Autonomous Orchestration

Overview

Orchestrates long-running autonomous work across multiple issues using the Task tool to spawn parallel worker agents and TaskOutput to monitor their progress.

Core principle: GitHub is the source of truth. Workers are disposable. State survives restarts.

Announce at start: "I'm using autonomous-orchestration to work through [SCOPE]. Starting autonomous operation now."

Prerequisites

  • worker-dispatch skill for spawning workers with Task tool
  • worker-protocol skill for worker behavior
  • ci-monitoring skill for CI/WAKE handling
  • GitHub CLI (gh) authenticated
  • GitHub Project Board configured

Parallel Execution Model

Workers are spawned as background agents using the Task tool:

Orchestrator
    │
    ├── Task(run_in_background: true) → Worker Agent #1 (task_id: aa93f22)
    ├── Task(run_in_background: true) → Worker Agent #2 (task_id: b51e54b)
    └── Task(run_in_background: true) → Worker Agent #3 (task_id: c72f3d1)

Monitor progress with TaskOutput:

TaskOutput(task_id: "aa93f22", block: false) → "Task is still running..."
TaskOutput(task_id: "b51e54b", block: false) → Completed with result
TaskOutput(task_id: "c72f3d1", block: false) → "Task is still running..."

CRITICAL: Spawn all workers in the SAME message for true concurrent execution.

State Management

CRITICAL: All persistent state is stored in GitHub. Task IDs are ephemeral session state.

State StorePurposeUsed For
Project Board StatusTHE source of truthReady, In Progress, In Review, Blocked, Done
Issue CommentsActivity logWorker assignment, progress, deviations
LabelsLineage onlyspawned-from:#N, depth:N, epic-*
MCP MemoryActive marker + task trackingActive orchestration detection, active task_ids
Orchestrator memoryEphemeral session stateMap of issue# → task_id for monitoring

See: reference/state-management.md for detailed state queries and updates.

Context Compaction Survival

CRITICAL: Orchestration must survive mid-loop context compaction.

On Start: Write Active Marker

# Write to MCP Memory when orchestration starts
mcp__memory__create_entities([{
  "name": "ActiveOrchestration",
  "entityType": "Orchestration",
  "observations": [
    "Status: ACTIVE",
    "Scope: [MILESTONE/EPIC/unbounded]",
    "Tracking Issue: #[NUMBER]",
    "Started: [ISO_TIMESTAMP]",
    "Repository: [owner/repo]",
    "Phase: BOOTSTRAP|MAIN_LOOP",
    "Last Loop: [ISO_TIMESTAMP]"
  ]
}])

On Each Loop Iteration: Update Marker

mcp__memory__add_observations({
  "observations": [{
    "entityName": "ActiveOrchestration",
    "contents": ["Last Loop: [ISO_TIMESTAMP]", "Phase: MAIN_LOOP"]
  }]
})

On Complete: Remove Marker

mcp__memory__delete_entities({
  "entityNames": ["ActiveOrchestration"]
})

On Session Resume (After Compaction)

Session-start skill checks for active orchestration:

# Check MCP Memory for active orchestration
ACTIVE=$(mcp__memory__open_nodes({"names": ["ActiveOrchestration"]}))

if [ -n "$ACTIVE" ]; then
  echo "⚠️ ACTIVE ORCHESTRATION DETECTED"
  echo "Scope: [from ACTIVE]"
  echo "Tracking: [from ACTIVE]"
  echo ""
  echo "Resuming orchestration loop..."
  # Invoke autonomous-orchestration skill to resume
fi

This ensures: Even if context compacts mid-loop, the next session will detect the active orchestration and resume it.

Immediate Start (User Consent Implied)

The user's request for autonomous operation IS their consent. No additional confirmation required.

When the user requests autonomous work:

  1. Identify scope - Parse user request for milestone, epic, specific issues, or "all"
  2. Announce intent - Briefly state what you're about to do
  3. Start immediately - Begin orchestration without waiting for additional input
## Starting Autonomous Operation

**Scope:** [MILESTONE/EPIC/ISSUES or "all open issues"]
**Workers:** Up to 5 parallel
**Mode:** Continuous until complete

Beginning work now...

Do NOT ask for "PROCEED" or any confirmation. The user asked for autonomous operation - that is the confirmation.

Automatic Scope Detection

When the user requests autonomous operation without specifying a scope:

Priority Order

  1. User-specified scope - If user mentions specific issues, epics, or milestones
  2. Urgent/High Priority standalone issues - Issues with priority:urgent or priority:high labels not part of an epic
  3. Epic-based sequential work - Work through epics in order, completing all issues within each epic
  4. Remaining standalone issues - Any issues not part of an epic
detect_work_scope() {
  # 1. Check for urgent/high priority standalone issues first
  PRIORITY_ISSUES=$(gh issue list --state open \
    --label "priority:urgent,priority:high" \
    --json number,labels \
    --jq '[.[] | select(.labels | map(.name) | any(startswith("epic-")) | not)] | .[].number')

  if [ -n "$PRIORITY_ISSUES" ]; then
    echo "priority_standalone"
    echo "$PRIORITY_ISSUES"
    return
  fi

  # 2. Get epics in order (by creation date)
  EPICS=$(gh issue list --state open --label "type:epic" \
    --json number,title,createdAt \
    --jq 'sort_by(.createdAt) | .[].number')

  if [ -n "$EPICS" ]; then
    echo "epics"
    echo "$EPICS"
    return
  fi

  # 3. Fall back to all open issues
  ALL_ISSUES=$(gh issue list --state open --json number --jq '.[].number')
  echo "all_issues"
  echo "$ALL_ISSUES"
}

Continuous Operation Until Complete

Autonomous operation continues until ALL of:

  • No open issues remain in scope
  • No open PRs awaiting merge
  • No issues in "In Progress" or "In Review" status

The operation does NOT pause for:

  • Progress updates
  • Confirmation between issues
  • Switching between epics
  • Any user input (unless blocked by a fatal error)

PR Resolution Bootstrap Phase

CRITICAL: Before spawning ANY new workers, resolve all existing open PRs first.

Bootstrap Flow: Get open PRs (exclude release/*, release-placeholder, do-not-merge) → For each: Check CI → Verify review → Merge if ready → Then start main loop

Bootstrap Implementation

resolve_existing_prs() {
  echo "=== PR RESOLUTION BOOTSTRAP ==="

  # Get all open PRs, excluding release placeholders
  OPEN_PRS=$(gh pr list --json number,headRefName,labels \
    --jq '[.[] | select(
      (.headRefName | startswith("release/") | not) and
      (.labels | map(.name) | index("release-placeholder") | not)
    )] | .[].number')

  if [ -z "$OPEN_PRS" ]; then
    echo "No actionable PRs to resolve. Proceeding to main loop."
    return 0
  fi

  echo "Found PRs to resolve: $OPEN_PRS"

  for pr in $OPEN_PRS; do
    echo "Processing PR #$pr..."

    # Get CI status
    ci_status=$(gh pr checks "$pr" --json state --jq '.[].state' 2>/dev/null | sort -u)

    # Get linked issue
    ISSUE=$(gh pr view "$pr" --json body --jq '.body' | grep -oE 'Closes #[0-9]+' | grep -oE '[0-9]+' | head -1)

    if [ -z "$ISSUE" ]; then
      echo "  ⚠ No linked issue found, skipping"
      continue
    fi

    # Check if CI passed
    if echo "$ci_status" | grep -q "FAILURE"; then
      echo "  ❌ CI failing - triggering ci-monitoring for PR #$pr"
      # Invoke ci-monitoring skill to fix
      handle_ci_failure "$pr"
      continue
    fi

    if echo "$ci_status" | grep -q "PENDING"; then
      echo "  ⏳ CI pending for PR #$pr, will check in main loop"
      continue
    fi

    if echo "$ci_status" | grep -q "SUCCESS"; then
      # Verify review artifact
      REVIEW_EXISTS=$(gh api "/repos/$OWNER/$REPO/issues/$ISSUE/comments" \
        --jq '[.[] | select(.body | contains("<!-- REVIEW:START -->"))] | length' 2>/dev/null || echo "0")

      if [ "$REVIEW_EXISTS" = "0" ]; then
        echo "  ⚠ No review artifact - requesting review for #$ISSUE"
        gh issue comment "$ISSUE" --body "## Review Required

PR #$pr has passing CI but no review artifact.

**Action needed:** Complete comprehensive-review and post artifact to this issue.

---
*Bootstrap phase - Orchestrator*"
        continue
      fi

      # All checks pass - merge
      echo "  ✅ Merging PR #$pr"
      gh pr merge "$pr" --squash --delete-branch
      mark_issue_done "$ISSUE"
    fi
  done

  echo "=== BOOTSTRAP COMPLETE ==="
}

Release Placeholder Detection

PRs are excluded from bootstrap resolution if:

ConditionExample
Branch starts with release/release/v2.0.0, release/2025-01
Has release-placeholder labelManual exclusion
Has do-not-merge labelExplicit hold

Orchestration Loop

Main Loop Flow: Monitor workers (TaskOutput) + Check CI/PRs + Spawn workers (Task) → Evaluate state (complete/sleep/continue)

Loop Steps

  1. Monitor Active Workers - Use TaskOutput(block: false) for each active task_id
  2. Handle Completed Workers - Check GitHub for PR/completion status
  3. Check CI/PRs - Monitor for merge readiness, verify review artifacts
  4. MERGE GREEN PRs - Any PR with passing CI is merged IMMEDIATELY
  5. Spawn Workers - Up to 5 parallel workers using Task(run_in_background: true)
  6. Evaluate State - Determine next action (continue, sleep, complete)
  7. Brief Pause - 30 second interval between iterations

Worker Monitoring with TaskOutput

Each loop iteration checks all active workers:

## Monitor Active Workers

For each task_id in active_workers:
  TaskOutput(task_id: "[ID]", block: false, timeout: 1000)

Interpret results:
- "Task is still running..." → Continue monitoring
- Completed → Check GitHub for PR, update project board, remove from active list
- Error → Handle failure, potentially spawn replacement

Spawning Parallel Workers

Spawn multiple workers in ONE message for concurrent execution:

## Dispatch Workers

1. Count available slots: 5 - len(active_workers)
2. Get Ready issues from project board
3. For each issue to dispatch:

Task(
  description: "Issue #123 worker",
  prompt: [WORKER_PROMPT],
  subagent_type: "general-purpose",
  run_in_background: true
)

4. Store returned task_id → issue mapping

CRITICAL: Merge Green PRs Immediately

Every loop iteration must check for and merge passing PRs:

# In each loop iteration
for pr in $(gh pr list --json number,statusCheckRollup --jq '.[] | select(.statusCheckRollup | all(.conclusion == "SUCCESS")) | .number'); do
  # Check for do-not-merge label
  if ! gh pr view "$pr" --json labels --jq '.labels[].name' | grep -q "do-not-merge"; then
    echo "Merging PR #$pr (CI passed)"
    gh pr merge "$pr" --squash --delete-branch

    # Get linked issue and mark done
    ISSUE=$(gh pr view "$pr" --json body --jq '.body' | grep -oE 'Closes #[0-9]+' | grep -oE '[0-9]+' | head -1)
    if [ -n "$ISSUE" ]; then
      # Update project board status to Done
      mark_issue_done "$ISSUE"
    fi
  fi
done

Do NOT:

  • Report "PRs are ready for merge" and stop
  • Wait for user to request merge
  • Summarize completed work and ask for next steps

The loop continues until scope is complete. Green PR = immediate merge.

Scope Types

Milestone

gh issue list --milestone "v1.0.0" --state open --json number --jq '.[].number'

Epic

gh issue list --label "epic-dark-mode" --state open --json number --jq '.[].number'

Unbounded (All Open Issues)

gh issue list --state open --json number --jq '.[].number'

Do NOT ask for "UNBOUNDED" confirmation. The user's request is their consent.

Failure Handling

Workers that fail do NOT immediately become blocked:

Attempt 1 → Research → Attempt 2 → Research → Attempt 3 → Research → Attempt 4 → BLOCKED

Only after 3+ research cycles is an issue marked as blocked.

See: reference/failure-recovery.md for research cycle implementation.

Blocked Determination

An issue is only marked blocked when:

  • Multiple research cycles completed (3+)
  • Research concludes "impossible without external input"
  • Examples: missing credentials, requires human decision, external service down

SLEEP/WAKE

Entering SLEEP

Orchestration sleeps when:

  • All issues are either blocked or in review
  • No work can proceed without external event

State is posted to GitHub tracking issue (survives crashes).

WAKE Mechanisms

  • SessionStart hook - Checks CI status on new Claude session
  • Manual - claude --resume [SESSION_ID]

Checklist

Before starting orchestration:

  • Scope identified (explicit or auto-detected)
  • GitHub CLI authenticated (gh auth status)
  • Tracking issue exists with orchestration-tracking label
  • Project board configured with Status field
  • Active marker written to MCP Memory

Bootstrap phase:

  • Existing open PRs detected
  • Release placeholders excluded (release/*, release-placeholder, do-not-merge labels)
  • CI status checked for each PR
  • Review artifacts verified before merge
  • PRs merged or flagged for attention
  • Bootstrap complete before spawning workers

During orchestration:

  • Workers spawned using Task(run_in_background: true)
  • Task IDs stored for each worker (issue# → task_id mapping)
  • Worker status monitored with TaskOutput(block: false)
  • Completed workers detected and handled
  • Project board status updated (In Progress, In Review, Done)
  • CI status monitored for open PRs
  • Green PRs merged IMMEDIATELY
  • Review artifacts verified before PR merge
  • Failed workers trigger research cycles
  • Handovers spawn replacement workers
  • SLEEP entered when only waiting on CI
  • Deviation resolution checked each loop
  • Status posted to tracking issue

Review Enforcement

CRITICAL: The orchestrator verifies review compliance:

  1. Before PR merge:

- Review artifact exists in issue comments - Review status is COMPLETE - Unaddressed findings = 0

  1. Child issues (from deferred findings):

- Follow full issue-driven-development process - Have their own code reviews - Track via spawned-from:#N label

  1. Deviation handling:

- Parent status set to Blocked on project board - Resumes only when all children closed

Integration

This skill coordinates:

SkillPurpose
worker-dispatchSpawning workers
worker-protocolWorker behavior
worker-handoverContext passing
ci-monitoringCI and WAKE handling
research-after-failureResearch cycles
issue-driven-developmentWorker follows this
comprehensive-reviewWorkers must complete before PR
project-board-enforcementALL state queries and updates

Reference Files

  • reference/state-management.md - State queries, updates, deviation handling
  • reference/loop-implementation.md - Full loop code and helpers
  • reference/failure-recovery.md - Research cycles, blocked handling, SLEEP/WAKE

平台分布

Claude Code

29.14%
按下载量换算40

Antigravity

21.78%
按下载量换算30

Gemini CLI

18.9%
按下载量换算26

Cursor

10.91%
按下载量换算15

kiro-cli

7.15%
按下载量换算10

windsurf

3.16%
按下载量换算4

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

可疑

权限和风险

执行命令

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

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在提醒或未通过项,安装前请自行复核。

继续浏览同类 Skills