Swe Skills

Babysits an open pull request end-to-end by polling every minute, triaging new comments and reviews, handling CI failures, iterating on reviewer scores, and stopping only when the PR is ready to merge. Use when a user says `babysit this PR`, `watch this PR until it's merge-ready`, `handle review feedback on my PR`, or `keep iterating on this PR until reviewers are happy`. Do NOT use for a one-shot PR risk review, merged PR production monitoring, or repo-wide CI debugging with no scoped PR.

Audits a repository's code and docs to find important conventions, workflows, and architectural decisions that are missing from agent-facing guidance, then drafts review-ready updates. Use when a user says `capture repo knowledge`, `document implicit conventions`, `turn repo patterns into agent rules`, or asks what future agents should remember about a codebase. Do NOT use for a generic repo tour, onboarding walkthrough, or architecture summary that does not need reusable guidance updates.

Plans the narrowest trustworthy validation path for a scoped code change or diff. Use when a user asks what to run before merging, how to validate a specific change, whether the current checks are enough, or wants a bounded command order from narrow to broad. Do NOT use for writing tests, fixing the code change itself, broad QA sweeps, or generic debugging that needs root cause analysis.

Creates or revises `swe:` skills for this repository using a repeatable authoring workflow: define concrete use cases, tune trigger boundaries, apply progressive disclosure, add matching eval assets, and validate the package. Use when adding a new skill, tightening an existing skill that over- or under-triggers, or distilling an external workflow into a repo-ready skill. Do NOT use for generic documentation edits or for executing the workflow the skill would describe.

Audits a repository for human-facing or operational documentation that drifted from code, config, interfaces, workflows, or repo structure changes. Use when a user says `check docs drift`, `docs are stale`, `update the runbook after this change`, or `what documentation is missing after this change`. Do NOT use for agent-guidance updates, generic documentation rewrites, or writing docs without evidence that they are stale.

Audits post-incident engineering follow-through after a sev or incident to verify whether the durable follow-up happened: regression tests, monitors, docs, runbooks, ownership updates, tickets, rollback learnings, and remaining backlog. Use when a user asks whether incident follow-up is complete, what still needs to be done after a postmortem, or how to close the engineering loop. Do NOT use for live incident response, root-cause analysis, or a generic bug hunt unrelated to an incident.

Initializes an optional repo-local agent collaboration preference file at `.ai/swe.json` by running a short interview or a zero-question quick mode. Use when a user says `initialize agent settings for this repo`, `set up my local agent prefs here`, `run quick init for this project`, or `create .ai/swe.json for how I like to work`. Do NOT use for `npm init`, project scaffolding, dependency installation, or environment bootstrap.

Reviews recently merged pull requests, confirms whether they reached production, compares pre- and post-deploy signals, and summarizes observable impact. Use when a user says `monitor merged PRs`, `did this deploy hurt prod`, `check production impact of yesterday's merges`, or asks for a post-deploy readout tied to merged GitHub PRs. Do NOT use for a pre-merge code review, incident analysis with no PR scope, or generic dashboard triage disconnected from merged changes.

Inspects services, jobs, and code paths for missing or weak logs, metrics, traces, alerts, dashboards, or deployment-linked telemetry, then returns a tightly scoped backlog of observability gaps. Use when a user says `find observability gaps`, `audit telemetry coverage`, `what logs or metrics are missing`, `check alerting coverage`, or asks for a recurring telemetry review. Do NOT use for live incident response, root-cause analysis, generic performance tuning, or a broad code review.

Maps engineering ownership risk in a repository using repo evidence such as git history, churn, bus factor, CODEOWNERS coverage, test density, and orphaned or unclear-owner surfaces. Use when a user says `map ownership risk`, `find bus factor hotspots`, `which files look orphaned`, `high-change low-test areas`, or asks for a recurring maintenance pass that identifies risky surfaces before they become incidents. Do NOT use for org charts, HR ownership assignments, or generic maintainer lists without repo evidence.

Hunts for concrete performance bottlenecks in a scoped repository surface using profiler output, benchmarks, query plans, traces, bundle analysis, or repo evidence, then returns the smallest high-value follow-up experiments or fixes. Use when a user says `find performance bottlenecks`, `why is this slow`, `profile this flow`, `hunt hot paths`, or asks for a recurring performance review. Do NOT use for live incident response, generic observability audits, speculative micro-optimization, or broad architecture rewrites with no bottleneck evidence.

Reviews open or draft pull requests for engineering risk before merge, focusing on missing validation, hidden coupling, rollout and rollback gaps, migrations, feature flags, and other agent-safe next actions. Use when a user says `review this PR for risk`, `pre-merge review`, `is this PR safe to merge`, or asks for a risk-focused PR review. Do NOT use for post-merge production monitoring, broad code smell review, or commit-scoped bug hunting.

Scans recent commits in one or more repositories, identifies likely bugs using concrete repo evidence only, and proposes tightly scoped remediation sessions. Use when a user says `scan recent commits for bugs`, `what did I probably break`, `review yesterday's changes for regressions`, or asks for a commit-scoped bug hunt. Do NOT use for a broad code health review, full security audit, or speculative bug hunting with no repo or time scope.

Reviews a repository and returns a short, best-first backlog of small, low-risk refactor tickets with clear write boundaries and validation paths. Use when a user says `find refactor opportunities`, `what small cleanup tickets should we hand to agents`, `give me parallelizable refactors`, or asks for narrow maintainability wins in an existing repo. Do NOT use for a broad architecture redesign, style-only cleanup sweep, or bug hunt focused on functional regressions.

Inspects an unfamiliar software repository and produces a concrete orientation report covering structure, tooling, entry points, boundaries, active surfaces, and safe places to start work. Use when a user says `help me understand this repo`, `map this codebase before I edit it`, `where should I start`, or asks for an engineering walkthrough before planning or delegation. Do NOT use when the user already knows the target change and wants implementation, or when they need a specific bug diagnosis rather than repo orientation.

Audits a repository, workspace, or monorepo for dependency vulnerabilities, outdated security-sensitive packages, license issues, and dependency hygiene gaps, then compiles one evidence-backed report. Use when a user says `run a security audit`, `check dependencies and licenses`, `audit this monorepo for vulnerable packages`, or asks for a package-level security review. Do NOT use for a general secure-code review, threat model, or speculative vulnerability hunt without manifests, lockfiles, or package surfaces to inspect.

Identifies and prioritizes the highest-value test coverage gaps in a repository or workspace, then incrementally adds or strengthens tests using the local test stack and cleanly scoped subagent work when available. Use when a user says `improve test coverage`, `find weak tests`, `add missing test cases`, `run a recurring test-improvement pass`, or asks for a language-agnostic workflow to strengthen mocks, fixtures, and test structure without chasing raw coverage numbers. Do NOT use for first-time framework selection, broad test-stack migrations, or large production refactors.