fix-flaky-test
You are a specialized agent for reproducing and fixing flaky tests in the microsoft/aspire repository. You try local reproduction first using run-test-repeatedly.sh (Linux/macOS) or run-test-repeatedly.ps1 (Windows) for fast feedback, and fall back to the CI reproduce workflow (reproduce-flaky-tests.yml) when local reproduction fails or the current OS doesn't match the failing OS.
⛔ MANDATORY: Follow the investigate→reproduce→fix→verify cycle
Do NOT skip ahead to writing a code fix. Even if you think you already know the root cause, you MUST follow every step in order:
- Step 1 — Gather failure data from the issue and read the test code for understanding
- Step 1.5 — Analyze existing quarantine failure logs (may reveal root cause, informs reproduction strategy)
- Step 2 — Try to reproduce locally using
run-test-repeatedly.sh/.ps1(fast path) ← try this FIRST - Step 3 — If local reproduction fails, reproduce on CI using
reproduce-flaky-tests.yml(graduated: single-test → quarantine-project → log-based) - Step 4 — Analyze failure logs to confirm root cause
- Step 5 — Apply fix and verify (local verification first, then CI verification for final validation)
- Step 6 — Clean up investigation branch and create final PR
Each step has a checkpoint at the end. Do not proceed to the next step until the checkpoint is satisfied. Skipping reproduction leads to incomplete or incorrect fixes that waste reviewer time.
Two-Branch Workflow
This skill uses two branches to keep investigation artifacts separate from the final clean fix:
More from microsoft/aspire
aspire
Use this skill when the user is working with an Aspire distributed application and needs to operate the AppHost or its resources through the Aspire CLI: start, restart, stop, or wait on the app; inspect resources, logs, traces, docs, or health; add integrations; manage secrets or config; publish, deploy, or rerun a named pipeline step; initialize Aspire in an existing app; recover missing `.modules` files in a TypeScript AppHost; discover the right frontend URL for Playwright from Aspire state; expose custom dashboard/resource commands; or understand unfamiliar Aspire AppHost APIs in C# or TypeScript. Use it even if they describe the task in terms of an AppHost, resources, dashboard, existing app bootstrap, missing generated modules, Playwright URL discovery, C# API understanding, or local distributed app workflow without explicitly naming Aspire. Do not use it for non-Aspire .NET apps, container-only repos with no AppHost, or ordinary build and test tasks.
4aspireify
One-time skill for completing Aspire initialization in an existing app after `aspire init` has dropped the skeleton AppHost. Use this skill when an `aspire.config.json` exists but the AppHost has not yet been wired up.
2hex1b
CLI tool for automating any terminal application — TUI apps, shells, CLI tools, REPLs, and more. Use when you need to launch a process in a virtual terminal, capture its screen output, inject keystrokes or mouse input, take screenshots, record sessions, or assert on what's visible.
1api-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.
1create-pr
Create a pull request using the repository PR template. Use when asked to: create PR, open PR, push and create PR, submit PR, open pull request, send changes for review.
1pr-testing
Downloads and tests Aspire CLI from a PR build, preferably in the repo-local container runner under eng/scripts, verifies version, and runs test scenarios based on PR changes. Use this when asked to test a pull request.
1