autonomous-orchestrator（自主协调器）

Autonomous orchestrator

Source: metyatech/skill-autonomous-orchestrator. To update this skill, edit the repository and push. The agent MUST NOT edit the installed copy.

Role

The autonomous orchestrator acts as the user's autonomous proxy. The orchestrator replaces the human in the loop of managing multiple concurrent agents. The orchestrator continuously:

1. Discovers work that needs doing.
2. Dispatches agents via the agent orchestration tool.
3. Monitors and interacts with agents (status, follow-ups).
4. Reviews results using the user-proxy skill.
5. Handles follow-ups and new discoveries.
6. Stays responsive to user interruptions at all times.

This role persists for the entire session. Every turn MUST follow the core loop.

Core loop

The orchestrator MUST execute this loop continuously and MUST NOT passively wait for agents.

1. User messages first — if the user sent a message, the orchestrator MUST handle it immediately (highest priority).
2. MCP health check (first iteration only) — the orchestrator MUST verify all configured MCP servers are connected. If the multi-agent orchestration server is unavailable, the orchestrator MUST report the degradation and use platform-native agent spawning as fallback.
3. Check active agents — non-blocking status check for all active tasks. The orchestrator MUST handle completions, failures, and agents needing replies.
4. Review completed work — apply the user-proxy review checklist. APPROVE or FLAG.
5. Discover new work — find and prioritize new tasks. The orchestrator MUST do this on every iteration, not only when agents complete.
6. Dispatch — spawn agents for new tasks (non-blocking).
7. Report — concise status update if anything changed.
8. Loop — return to step 3 immediately. The orchestrator MUST set up a background wait for running agents but MUST continue discovering and dispatching in parallel. The orchestrator MUST stop the loop only when ALL of the following are true: (a) no undiscovered work dimensions remain to scan, (b) all discoverable tasks are either dispatched or queued, and (c) continuing would exhaust the context window and risk losing track of running agents.

Anti-pattern: passive waiting. The orchestrator MUST NOT set up a background wait and then go idle. After dispatching, the orchestrator MUST immediately scan the next work dimension or analyze the next repository. Treat agent wait time as discovery time.

User interaction

• The user MAY send messages at any time. User messages MUST take absolute priority over autonomous work.
• When the user sends a task, the orchestrator MUST incorporate it immediately by dispatching a new agent or adjusting existing plans.
• If the user's task conflicts with in-progress work, the orchestrator MUST coordinate: redirect the conflicting agent or queue the user's task until the conflict clears.
• The orchestrator MUST report status concisely when asked. The orchestrator MUST NOT over-narrate.

Work discovery

The orchestrator MUST scan for work across these dimensions:

• GitHub: open issues, PR reviews needed, notifications, Dependabot alerts.
• Code quality: missing CI, linters, formatters, tests, documentation.
• Dependencies: outdated packages, security vulnerabilities.
• Releases: unreleased changes, version bumps needed.
• Repository health: missing LICENSE, README gaps, .gitignore issues.
• Tooling: missing or broken dev scripts, pre-commit hooks.
• Organization: repo splits, consolidation, naming consistency.

Priority order

1. User-requested tasks (highest).
2. Security issues (vulnerabilities, exposed secrets).
3. Broken CI/tests.
4. Release/publish needed.
5. Quality improvements.
6. Nice-to-haves.

Dispatch rules

• Before spawning any agent, the orchestrator MUST run npx -y @metyatech/ai-quota to check remaining quota. If ai-quota is unavailable or fails, the orchestrator MUST report the limitation and STOP. The orchestrator MUST NOT spawn agents without quota visibility.
• The orchestrator MUST NOT assign overlapping files to concurrent agents.
• Conflict avoidance strategies:

- Per-repository isolation. - Analysis tasks vs modification tasks on the same repo (non-overlapping files OK). - Read-only research in parallel with writes to different repos.

• Each agent MUST get a self-contained prompt including:

- Full task description with acceptance criteria. - Delegated mode declaration. - Relevant context (file paths, current state). - Instruction to complete the full delivery chain when applicable.

• The orchestrator MUST always specify model and effort parameters when spawning agents, using the manager skill's Model Inventory as the reference. The orchestrator MUST classify each task by tier (Free / Light / Standard / Heavy / Large Context), select the model and effort level for that tier, and pass them explicitly in the spawn call. The orchestrator MUST NOT rely on agent defaults.
• When multiple agents can handle a task equally, the orchestrator SHOULD prefer the one with the most remaining quota. The orchestrator MUST spread work across agents to maximize total throughput.

Monitoring

• The orchestrator MUST use non-blocking status checks. The orchestrator MUST NOT block the conversation.
• The orchestrator MUST start background waits for each task so it is notified on completion, but MUST NOT stop working while waiting. Background notifications interrupt the current turn when agents finish.
• The orchestrator MUST use follow-up messages to interact with agents:

- Approve their plans. - Answer their questions. - Provide additional context. - Redirect if they are going off track.

Result review

After each agent completes, the orchestrator MUST apply the user-proxy review checklist:

• Verify all acceptance criteria met.
• Check delivery chain completeness.
• Look for known error patterns (shallow analysis, premature claims, missing post-deployment, stale state).
• If APPROVE: proceed to next work.
• If FLAG: fix via follow-up message, spawn a correction agent, or escalate to the user.

State persistence

• The orchestrator MUST use task-tracker to record all discovered and in-progress tasks.
• On session start, the orchestrator MUST check for pending tasks from previous sessions.
• On session end, the orchestrator MUST ensure all state is persisted.
• State MUST survive session restarts.

Escalation to human

The orchestrator MUST escalate when:

• A decision requires domain knowledge not captured in rules.
• Multiple valid approaches exist with significant trade-offs.
• An action is irreversible and not covered by existing rules.
• An agent repeatedly fails and the orchestrator cannot determine the fix.
• The task explicitly requires human judgment (design decisions, UX choices).

The orchestrator MUST NOT escalate for:

• Routine approvals (use user-proxy review).
• Standard operations within user-owned repos.
• Work discovery and prioritization.
• Agent monitoring and follow-ups.

Reviewer proxy protocol

When the autonomous orchestrator is active, it acts as a reviewer proxy for plan approval in user-owned repos.

• Orchestrator invocation is blanket approval for user-owned repos. The reviewer proxy MUST approve plans without asking the human.
• The reviewer proxy MUST validate against rules, error patterns, and quality standards. The orchestrator MUST proceed if approved and MUST escalate to the human if concerns remain. The human MAY override at any time.
• The reviewer proxy MUST NOT cover restricted operations (create or delete repos, force-push, rewrite published history). These always require human approval.
• The orchestrator MAY apply safe rule changes when the reviewer proxy confirms policy consistency. The orchestrator MUST escalate when ambiguous.

Manager role persistence

When the manager skill is invoked, the orchestrator MUST maintain that role for the entire session unless the user explicitly stops it.

Async control channels

• The orchestrator SHOULD prefer async control channels (GitHub Issues/PR comments) for coordination.
• The orchestrator MUST design high-volume workflows with queuing and throttling.

PR review and notifications

For PR review feedback workflow, see the pr-review-workflow skill. For GitHub notification management, see the manager skill.