$ ~/registry/skill/microsoft-agents-skills-apm-issue-autopilot

SKILL

apm-issue-autopilot

Name: apm-issue-autopilot
Author: microsoft

Triage APM issues in batches and drive approved ones to mergeable PRs.

Stars

★ 3,163

Source

GitHub

Updated

2026-07-10

// securityLow risk

Prompt only, no code
Open source
Community-trusted· 3.2k

Running security audit…

Credentials
Network egress
Code execution
Data access
Supply chain

// install

Copy the install command and let the AI configure it · recommended for beginners

Please install the "apm-issue-autopilot" skill from askskill:
1. Download https://raw.githubusercontent.com/microsoft/apm/main/.agents/skills/apm-issue-autopilot/SKILL.md
2. Save it as ~/.claude/skills/apm-issue-autopilot/SKILL.md
3. Reload skills and tell me it's ready

// download

Download SKILL.mdInstall manifest ↗

// examples

Clear the issue backlog

Prompt

Please manually process this set of microsoft/apm issues: #128, #131, #145, #152. Run the apm-triage-panel rubric on each issue first, then give me one consolidated triage review for the whole batch. Escalate to the maintainer by default for any doubt, possible duplicate, design need, breaking change, auth/security/governance concern, unbounded scope, or missing brief. Only implement items that the maintainer explicitly approves and that are clear, bounded, and high-confidence.

Expected

A consolidated triage review with escalation recommendations, followed by mergeable PRs for approved items.

Drive approved issues to PRs

Prompt

The maintainer has approved these issues for acceptance: #210 (bug), #214 (docs), #219 (perf). Please drive them one by one using the shepherd-driver loop: implement the changes, fold in follow-ups from copilot and panels, watch CI status, and iterate under a bounded cap until each PR is mergeable. Do not trigger from labels or events; only process the issues provided in this session.

Expected

Iteration updates for each approved issue, handled feedback, and a mergeable PR for each.

Triage first, then decide implementation

Prompt

Please process this issue queue and treat triage as the paramount gate: #301, #302, #303, #304, #305. First produce one consolidated triage review for the whole batch, then tell me which items should be escalated to the maintainer and which can be auto-handled. Only continue to coding and a mergeable PR for accepted items that are clear, bounded, and approved by the maintainer.

Expected

First a batch triage report with escalation decisions, then development and PRs only for qualified issues.

// docs

apm-issue-autopilot - intake-to-merge issue orchestrator

This SKILL.md is the natural-language module derived from a genesis design packet; refactors re-run the genesis skill from that packet.

This skill is an A11 RECONCILIATION LOOP, MANUALLY INVOKED, over a queue of issues each driven to a terminal state under non-determinism. It generalizes batch-bug-shepherd from bugs-only to ANY issue type, and promotes the full apm-triage-panel rubric to the central front gate. It does NOT re-implement triage, panel review, or the per-PR convergence loop -- it COMPOSES existing skills.

What it composes (do not re-implement)

apm-triage-panel -- the triage rubric, run per issue in DIRECT (orchestrator-return) mode.
shepherd-driver -- the per-PR drive- to-merge convergence loop and cross-PR mergeability gate (which in turn composes apm-review-panel).
pr-description-skill -- authors the anchored, mermaid-validated body of the ONE issue PR opened at Phase 4 acceptance-close (see assets/acceptance-observer.md). The PR body is never hand-rolled.

All three are same-repo LOCAL SIBLINGS. This skill DECLARES each dependency here AND in apm.yml, and PROBES for each at its use-site (Phase 1 triage, Phase 4 PR-open, Phase 5 shepherd) with a tool call -- never an assertion from recall (A9 SUPERVISED EXECUTION).

Hard boundaries

MANUAL invocation only. No event triggers, no label triggers, no gh-aw. Labels (status/accepted, status/shepherding) are WRITTEN for bookkeeping but are NEVER the trigger.
Triage is paramount. The autopilot ESCALATES to the maintainer by default; auto-implementation is the narrow exception, reached only for a clear, bounded, high-confidence accept the maintainer approved.
ONE consolidated triage review for the whole batch, not drop-by- drop. Exactly one human checkpoint (Phase 2).
Never auto-merge. Mergeability is the terminal state; the human approves the protected merge.
Escalation NEVER auto-closes or auto-declines an issue. It surfaces the issue to the maintainer running the session and leaves it for human action (inherits batch-bug-shepherd terminal-handling).

Architecture invariants

Fan-out, not serial. Triage, solution-pipeline (and its Plan lenses + per-wave task children), and shepherd-driver all run as parallel child threads via the runtime task affordance. A single-loop variant is an anti-pattern. Subagent capacity is UNLIMITED and is NEVER a deferral reason.
Worktree isolation, with one-writer integration. Every solution- pipeline and shepherd-driver child runs in its OWN git worktree (one per issue/PR). Within Phase 4, a pipeline child further spawns ONE task child per task PER WAVE, each in its OWN worktree branched off the issue branch at the wave base; the pipeline child is the SOLE WRITER of the issue branch and integrates task branches via git merge --no-ff at the wave gate. Tasks in a wave are mutually independent and touch disjoint files by construction (planner- enforced), so integration is conflict-free -- a real conflict is a planning error and triggers a re-plan, never a hand-resolve. Do NOT fan out against one shared working tree. Triage and verifier/lens children are read-only and may share a read-only REPO_ROOT.
One persisted state table. A single plan.md ground-truth table plus a machine-readable proceed_manifest is the canonical session state (B4 PLAN MEMENTO). Reload it at every phase boundary; never keep parallel state in memory. The orchestrator is the SOLE writer (one-writer rule); children return JSON, the parent writes rows.
Escalate by default. The confidence gate (assets/confidence-gate-rubric.md)

…

View full docs ↗

Assess PR documentation impact and produce actionable update guidance every time.

microsoftGet→

$ loading_

Please install the "apm-issue-autopilot" skill from askskill: 1. Download https://raw.githubusercontent.com/microsoft/apm/main/.agents/skills/apm-issue-autopilot/SKILL.md 2. Save it as ~/.claude/skills/apm-issue-autopilot/SKILL.md 3. Reload skills and tell me it's ready

// examples

Clear the issue backlog

Prompt

Please manually process this set of microsoft/apm issues: #128, #131, #145, #152. Run the apm-triage-panel rubric on each issue first, then give me one consolidated triage review for the whole batch. Escalate to the maintainer by default for any doubt, possible duplicate, design need, breaking change, auth/security/governance concern, unbounded scope, or missing brief. Only implement items that the maintainer explicitly approves and that are clear, bounded, and high-confidence.

Expected

A consolidated triage review with escalation recommendations, followed by mergeable PRs for approved items.

Drive approved issues to PRs

Prompt

The maintainer has approved these issues for acceptance: #210 (bug), #214 (docs), #219 (perf). Please drive them one by one using the shepherd-driver loop: implement the changes, fold in follow-ups from copilot and panels, watch CI status, and iterate under a bounded cap until each PR is mergeable. Do not trigger from labels or events; only process the issues provided in this session.

Expected

Iteration updates for each approved issue, handled feedback, and a mergeable PR for each.

Triage first, then decide implementation

Prompt

Please process this issue queue and treat triage as the paramount gate: #301, #302, #303, #304, #305. First produce one consolidated triage review for the whole batch, then tell me which items should be escalated to the maintainer and which can be auto-handled. Only continue to coding and a mergeable PR for accepted items that are clear, bounded, and approved by the maintainer.

Expected

First a batch triage report with escalation decisions, then development and PRs only for qualified issues.

// docs

apm-issue-autopilot - intake-to-merge issue orchestrator

This SKILL.md is the natural-language module derived from a genesis design packet; refactors re-run the genesis skill from that packet.

What it composes (do not re-implement)

apm-triage-panel -- the triage rubric, run per issue in DIRECT (orchestrator-return) mode.
shepherd-driver -- the per-PR drive- to-merge convergence loop and cross-PR mergeability gate (which in turn composes apm-review-panel).
pr-description-skill -- authors the anchored, mermaid-validated body of the ONE issue PR opened at Phase 4 acceptance-close (see assets/acceptance-observer.md). The PR body is never hand-rolled.

Hard boundaries

MANUAL invocation only. No event triggers, no label triggers, no gh-aw. Labels (status/accepted, status/shepherding) are WRITTEN for bookkeeping but are NEVER the trigger.
Triage is paramount. The autopilot ESCALATES to the maintainer by default; auto-implementation is the narrow exception, reached only for a clear, bounded, high-confidence accept the maintainer approved.
ONE consolidated triage review for the whole batch, not drop-by- drop. Exactly one human checkpoint (Phase 2).
Never auto-merge. Mergeability is the terminal state; the human approves the protected merge.
Escalation NEVER auto-closes or auto-declines an issue. It surfaces the issue to the maintainer running the session and leaves it for human action (inherits batch-bug-shepherd terminal-handling).

Architecture invariants

Fan-out, not serial. Triage, solution-pipeline (and its Plan lenses + per-wave task children), and shepherd-driver all run as parallel child threads via the runtime task affordance. A single-loop variant is an anti-pattern. Subagent capacity is UNLIMITED and is NEVER a deferral reason.
Worktree isolation, with one-writer integration. Every solution- pipeline and shepherd-driver child runs in its OWN git worktree (one per issue/PR). Within Phase 4, a pipeline child further spawns ONE task child per task PER WAVE, each in its OWN worktree branched off the issue branch at the wave base; the pipeline child is the SOLE WRITER of the issue branch and integrates task branches via git merge --no-ff at the wave gate. Tasks in a wave are mutually independent and touch disjoint files by construction (planner- enforced), so integration is conflict-free -- a real conflict is a planning error and triggers a re-plan, never a hand-resolve. Do NOT fan out against one shared working tree. Triage and verifier/lens children are read-only and may share a read-only REPO_ROOT.
One persisted state table. A single plan.md ground-truth table plus a machine-readable proceed_manifest is the canonical session state (B4 PLAN MEMENTO). Reload it at every phase boundary; never keep parallel state in memory. The orchestrator is the SOLE writer (one-writer rule); children return JSON, the parent writes rows.
Escalate by default. The confidence gate (assets/confidence-gate-rubric.md)

…

View full docs ↗