// Analyze a PR to determine which files still need approval and from whom, based on CODEOWNERS and website/config/custom.js. Use when the user asks "who needs to approve", "why is the PR blocked", "who blocks this PR", or similar.
Add a Fleet-maintained app (FMA) for macOS (Homebrew) and/or Windows (winget). Use when asked to "add X as a macOS/Windows FMA", "add a Fleet-maintained app", or to debug FMA validator failures. Emphasizes verifying installer metadata with real tools (msitools, plist) instead of guessing.
Format release retro notes for a Fleet working group into a Slack recap post and ~timebox GitHub issues. Use when asked to "post retro recap", "format retro notes", "create release retro", or after a retrospective when feedback needs to land in Slack and action items need to be tracked.
Cherry-pick a merged PR onto a release candidate branch and open a new PR. Use when asked to cherry-pick, backport, or port a PR to an rc-minor or rc-patch branch.
Open a new Fleet feature request GitHub issue using the official fleetdm/fleet feature-request template. Use this skill whenever someone says "new feature request", "submit a feature request", "open a feature request", "create a feature request", "I want to request a feature", "feature request for...", or any similar phrasing indicating they want to file a new feature idea or product improvement with the Fleet team. Always use this skill — never construct issue body text yourself or link to the template without a pre-filled title and body.
Cherry-pick a merged PR into the current RC branch. Use when asked to "cherry-pick", "cp into RC", or after merging a PR that needs to go into the current release.
Bump a database migration's timestamp to the current time. Required when a PR's migration is older than one already merged to main. Use when asked to "bump migration", "update migration timestamp", or when a migration ordering conflict is detected.
| name | who-blocks-this-pr |
| description | Analyze a PR to determine which files still need approval and from whom, based on CODEOWNERS and website/config/custom.js. Use when the user asks "who needs to approve", "why is the PR blocked", "who blocks this PR", or similar. |
Quickly determine which reviewers are still needed for a PR and which files they own.
Run these in parallel:
gh pr view <number> --json mergeStateStatus,mergeable,reviewDecision to check if it's actually blockedgh api repos/<owner>/<repo>/pulls/<number> --jq '.requested_reviewers[].login' to get who GitHub is still waiting ongh pr view <number> --json reviews --jq '.reviews[] | select(.state == "APPROVED") | .author.login' to see who already approvedgh pr view <number> --json files --jq '.files[].path' to get changed filesIf the PR is not blocked, just report that and stop.
IMPORTANT: Distinguish between blocking and non-blocking reviewers.
githubRepoDRIByPath and githubRepoMaintainersByPath auto-request reviewers but do NOT block merges. These are courtesy requests.For each still-requested reviewer, check whether they are required by a CODEOWNERS pattern that matches a changed file. If they only appear in custom.js, they are requested but not blocking.
Output two sections:
Blocking (CODEOWNERS-required):
Requested but not blocking (custom.js DRI):
Also note who has already approved and what they covered.
Do NOT give a full breakdown of every file's ownership. Only show what's relevant to the still-requested reviewers.