287 skills
Diagnose eBPF program verification failures from the PREVAIL verifier. Use this skill for linux-compatible eBPF programs verified in the standalone PREVAIL repo (external/ebpf-verifier). For programs using Windows-specific features (bpf2c pipeline, Windows helpers, ebpf-for-windows headers), use the 'verify-bpf' skill instead.
Build and verify eBPF programs for the ebpf-for-windows project. Use this skill when asked to compile a .c BPF source to .o, verify a .o ELF file with bpf2c, or diagnose verification failures. Covers the full clang→bpf2c pipeline.
Download and analyze crash dumps from CI failures using CDB/WinDbg. Use this skill when asked to debug crashes, analyze dump files, set up WinDbg/CDB, investigate fault injection failures, or start mcp-windbg.
Build and test the PREVAIL verifier (external/ebpf-verifier) standalone. Use this skill when asked to build, test, or iterate on the PREVAIL verifier, run YAML verification tests, or work with the verifier's cmake build system.
Build the eBPF for Windows repository — entire solution or specific components. Use this skill when asked to build, compile, rebuild, restore, or clean the project or any of its components (drivers, libraries, tools, tests, etc.).
Guides root-cause investigations with debugging capabilities by setting breakpoints, starting a debug session, stepping through execution, inspecting variables, and tracing symptoms back to their origin. Prefer it for runtime bugs, failing tests, exceptions, crashes, hangs, wrong/null values, and unexpected output when live inspection is practical. Use this skill instead of modifying source code with temporary logs, print statements, or console output.
Use ONLY when the user's message contains the exact command `/special-debug tool-trace` (optionally with `--full`); run the task normally, then write `tool_trace.json` summarizing tool/action/connector calls in order. Sensitive values (secrets, tokens, PII/PHI) are redacted by default; `--full` keeps them verbatim for an authorized admin.
Refine the user's existing plan, decision, or draft through relentless refinement. Use when the user wants to sharpen or stress-test their thinking.
Build a personalized, day-by-day study plan for an upcoming exam, certification, or test. Use this skill whenever someone mentions studying for an exam, prepping for a certification, needs a study schedule, is trying to pass a test by a certain date, or asks for help organizing exam prep, even if they don't use the word "plan" explicitly (e.g. "I have my PMP in 6 weeks and don't know where to start", "help me study for the bar", "I need to prep for the AZ-900"). Also use when someone wants to revise or adjust an existing study plan because their timeline changed, they fell behind, or their con
Play and operate a deterministic, resumable Colossal Cave text adventure with verbatim game output and an OOC escape. Use when a user asks to start, continue, inspect, reset, or smoke-test the Classic Text Adventure; treat unprefixed messages as game commands while a session is active.
Quarantines or disables flaky/problematic tests using the QuarantineTools utility
Use when asked to test a microsoft/aspire pull request, including CLI, hosting, dashboard, component, template, and VS Code extension changes. Also covers testing PRs that change CI infrastructure — GitHub Actions (workflows, actions, gh-aw agentic workflows, CI scripts under .github/ and eng/) and Azure DevOps pipelines (eng/pipelines, eng/common).
Investigates GitHub issues in microsoft/aspire by gathering issue context, routing to specialized skills, preparing the right reproduction environment, reproducing behavior, and drafting evidence-backed findings or insufficient-info comments for user approval. Use when asked to investigate, reproduce, validate, debug, triage, or root-cause an Aspire issue.
Reproduces and fixes flaky or quarantined tests. Tries local reproduction first (fast), then falls back to CI reproduce workflow (reproduce-flaky-tests.yml). Use this when asked to investigate, reproduce, debug, or fix a flaky test, a quarantined test, or an intermittently failing test.
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.
Use when creating, modifying, debugging, or reviewing Aspire CLI end-to-end tests that use Hex1b terminal automation under tests/Aspire.Cli.EndToEnd.Tests/.
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.
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.
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.
**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
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.
