code-review
Review a GitHub pull request for problems. Use when asked to review a PR, do a code review, check a PR for issues, or review pull request changes. Focuses only on identifying problems — not style nits or praise.
⌘ K
Newest skills
1211 skills
cli-e2e-testing
Use when creating, modifying, debugging, or reviewing Aspire CLI end-to-end tests that use Hex1b terminal automation under tests/Aspire.Cli.EndToEnd.Tests/.
cli-channel-debugging
Emulates any Aspire CLI build identity (channel, version, commit, package source) from a locally built CLI using ASPIRE_CLI_* environment variables and the install sidecar, so a reported bug can be reproduced and fixed locally without going through the install/PR loop. Use this when asked to reproduce channel/version/quality-specific CLI behavior, simulate a daily/staging/stable/PR build locally, or decide which override knobs to set for a given scenario.
ci-test-failures
Guide for diagnosing GitHub Actions test failures, extracting failed tests from runs, and creating or updating failing-test issues. Use this when asked to investigate GitHub Actions test failures, download failure logs, create failing-test issues, or debug CI issues.
backport-pr
Backports a merged PR to a release branch by triggering the /backport bot, waiting for the bot-created PR, and filling in the shiproom template (Customer Impact, Testing, Risk, Regression?). Use when asked to: backport a PR, port a fix to a release branch, fill in a backport template, prepare a backport for shiproom review.
api-review
Reviews .NET API surface area PRs for design guideline violations. Analyzes api/*.cs file diffs, applies review rules from .NET Framework Design Guidelines and Aspire conventions, and attributes findings to the developer who introduced each API (via git blame). Use this when asked to review API surface area changes.
pr-review
**AUTHOR SKILL (internal to microsoft/aspire-skills).** Reviews pull requests *into this repo* for problems only — bugs, regressions, missing eval coverage, frontmatter or routing damage, plugin-manifest drift, hook safety, and other concrete issues. Drives a six-step workflow: identify the PR, ensure the branch is available locally, gather context, categorize changes, review, present findings for triage, and post selected comments as a review. USE FOR: review this PR, review the current branch, review pull request, gh pr view, gh pr diff, "what should I check before merging", PR review of cha
apm-triage-panel
Use this skill to triage one microsoft/apm issue selected by the daily sweep, an advisory re-triage request, or manual dispatch, even when the request only asks whether one proposal is ready for discussion. Return one advisory recommendation and a proposed scope brief, never human approval. Do not implement the issue or manage the backlog.
python-architecture
Activate when creating new modules, refactoring class hierarchies, introducing design patterns, or making changes spanning 3+ files in the APM CLI codebase.
docs-impact-localizer
Use this skill to translate a classifier's in-place verdict into a precise, page-by-page work plan for the docs-sync panel. Activate after docs-impact-classifier returns verdict in_place; reads the candidate page list, fetches the actual page contents, narrows scope to specific sections within each page, and emits the per-page task brief the panel fans out against.
cut-release
Use this skill to cut an APM release from the current worktree: assess whether the cycle since the last tag warrants a patch or minor bump (semver discipline against the merged-since-last-tag diff), sanitize the [Unreleased] CHANGELOG block into a dated version block with one concise "so what" entry per merged PR (drop internal-only churn, consolidate duplicates), bump pyproject.toml + uv.lock, run the CI-mirror lint chain, and open the release PR. Activate on "ship a release", "cut v0.x", "release prep", "bump and PR", "open release PR", "what kind of release do we need", or any phrasing that
python-architecture
Activate when creating new modules, refactoring class hierarchies, introducing design patterns, or making changes spanning 3+ files in the APM CLI codebase.
batch-bug-shepherd
Use this skill to drive a batch of suspected bugs in microsoft/apm from raw issue list to mergeable PR queue. Fan out one triage subagent per issue (LEGIT / UNCLEAR / FIXED-AT-HEAD), gate every legit bug against PRINCIPLES.md via an apm-ceo strategic-alignment pass, cross-reference legit issues against open PRs, then open a fix PR (TDD + mutation-break gate) for greenfield bugs. Drive every PR -- community in-flight and own fix alike -- to mergeable by composing the shepherd-driver skill: one driver per PR runs the review panel, folds non-blocking recommendations, pushes (preserving author), a
amplifier-smart-tools-catalog
Find Amplifier Smart Tools for a task, check local availability, and learn how to use them. Use for tool discovery, tool-owned installation guidance, or help creating an Amplifier Smart Tool and contributing it to the catalog.
system-type-web-service
Domain patterns for web service architecture — API design (REST/GraphQL/gRPC), scaling, data layer, observability, failure modes, and anti-patterns. Use when designing or evaluating a web service, API, or request/response system.
system-type-edge-offline
Domain patterns for edge computing and offline-first systems — sync protocols, conflict resolution under partition, local-first architecture, constrained resources, intermittent connectivity, and failure modes. Use when designing or evaluating mobile apps, IoT systems, field-deployed software, or any system that must work without reliable network access.
verification-discipline
Use when verifying that completed work actually works. Auto-surface during /verify mode, post-implementation review, or before claiming a task is done. Teaches testing outcomes vs implementation, the unit/integration/smoke gradient, and what "done" actually means.
skillify
Capture a repeatable process from the current session into a reusable Amplifier SKILL.md skill file. Use when the user wants to create a skill, save a workflow as a skill, turn a process into a reusable skill, or mentions "skillify", "create skill", "make a skill", "save as skill", "capture workflow", "turn this into a skill", "new skill", or wants to automate a repeatable process they just performed.
session-debug
Diagnose issues in the current Amplifier session — misconfigured tools, failing operations, unexpected behavior. Use when something isn't working right.
second-opinion
Independent review of current work or a past session. USE WHEN a user wants a second opinion. DO NOT USE WHEN ordinary code review is wanted — use code-review.
outcomist
Outcome-clarity reviewer that asks whether you have defined what you're trying to achieve and validated that the problem is real. Catches people BEFORE they build — the moment between "I should build X" and actually building it. Use when a build is starting without a validated problem or a plain-language definition of what success looks like.
monitor
Run a bounded, self-checking polling loop (sleep -> check -> decide, repeat) WITHOUT ENDING THE TURN. The turn ends only when the watched thing is done, has failed, or genuinely needs the user's attention — which is what makes Amplifier's end-of-turn notification fire correctly and honestly. Primarily invoked explicitly via `/monitor <thing to watch>`, e.g. `/monitor the CI run for PR 412, check every 2m, stop after 1h`. May also be self-invoked in the rare case you are about to tell the user "I'll keep working and let you know" for something with a genuinely checkable, bounded condition — see
code-review
Review changed code for reuse, quality, and efficiency, then fix any issues found.
ten-lane-highway
Become the Highway Manager: drive many parallel /goal lanes continuously toward a defined outcome, refilling lanes on every wake so none sit idle. Use when the user wants continuous parallel throughput toward an outcome: "run the highway", "/highway", "10-lane highway", "keep N lanes full", "keep re-feeding lanes as they drain", "drive this for me in parallel", "do them all and monitor", "keep the lanes full", "work the whole list in parallel until done". NOT for a one-shot batch that launches once and drains together — use goal-batch. NOT for bounded edits that each end in their own PR — use