Implements and debugs browser WebMCP integrations in JavaScript or TypeScript web apps. Use when exposing imperative tools through document.modelContext (with a navigator.modelContext fallback), annotating HTML forms for declarative tools, handling agent-invoked form flows, or validating WebMCP behavior in the current Chrome preview. Don't use for server-side MCP servers, REST tool backends, or non-browser providers.

Installs, configures, audits, and operates Agent Package Manager (APM) in repositories. Use when initializing apm.yml, installing or updating packages, validating manifests, managing lockfiles, compiling agent context, browsing MCP servers, setting up runtimes, or packaging resolved context for CI and team distribution. Don't use for writing a single skill by hand, generic package managers like npm or pip, or non-APM agent configuration systems.

Implements and debugs browser Proofreader API integrations in JavaScript or TypeScript web apps. Use when adding Proofreader availability checks, monitored model downloads, proofread flows, correction metadata handling, or permissions-policy checks for built-in proofreading. Don't use for generic prompt engineering, server-side LLM SDKs, or cloud AI services.

Implements and debugs browser Translator API integrations in JavaScript or TypeScript web apps. Use when adding Translator support checks, language-pair availability flows, model download UX, session creation, translate() or translateStreaming() calls, input-usage measurement, or permissions-policy handling for on-device translation. Don't use for server-side translation SDKs, cloud translation services, or generic multilingual content pipelines.

Review one linked Oracle Forms legacy-evidence package produced by leg-spec-from-code-oracle for semantic relationships, cross-fact ambiguities, apparent conflicts, missing runtime context, and source-supported reconciliations. Use after Oracle code evidence extraction and before target requirement curation when the master specification and its operation, decoded-source, and database children need a human-readable semantic review overlay without modifying extracted evidence or generating target requirements, UI designs, tests, or implementation decisions.

Creates a draft GitHub pull request with a plain-text conventional-commit title and a succinct description of the branch. Use when the user asks to open, raise, or create a pull request or PR.

Answer questions about live production system behavior — current variable values, execution durations, hit counts, and value distributions — by instrumenting running services with Lightrun MCP tools. Use when the question requires live runtime data rather than static code analysis (e.g. "show recent requests to this endpoint", "show the runtime distribution for this operation", "what values appear for this expression in production?", "which branch runs for customer X?"). Do not use for incident diagnosis, pull-request review, code changes, setup, or deployment. Route latency, timeout, deadline, SLO, or hang diagnosis to lightrun-slow-execution-diagnosis when available; route other diagnosis, or fallback when that skill is unavailable, to lightrun-live-runtime-debugging when available. If neither diagnosis skill is available, report the scope gap.

Creates and edits trusted local Letta Code mods, including tools, slash commands, local-only model providers, lifecycle/turn events, scoped conversation helpers, panels, and capability-gated behavior. Use when asked to make a mod, add an agent-callable tool, add a slash command, add a local provider/model adapter, transform turns, react to app events, or add lightweight mod UI outside the dedicated /statusline flow.

Add authentication to a new app. Use for "add auth", "add login", Neon Auth (Managed Better Auth), identity routing, sign-up, sign-in, password reset, email OTP, magic links, organizations, phone OTP, OAuth, passkeys, MFA, trusted domains, invalid domain, and @neondatabase/auth. No existing identity: default to Managed Better Auth. Keep working Better Auth, Clerk, Supabase Auth, or another IdP. User asked to migrate from Supabase Auth: Managed Better Auth. A required plugin outside Managed support: self-managed Better Auth on a Neon Function or the existing app host. Also use for auth APIs in @neondatabase/neon-js.

Add fast, local, typed decisions to any project with Laya, an open-source non-generative decision model (pip install laya). It classifies, routes, scores and answers yes/no questions about a piece of text, returning calibrated probabilities in roughly 20-35 ms on a laptop GPU, with no LLM call and no data leaving the machine. Use this skill whenever the user wants to classify or route text, triage tickets or emails, detect spam, phishing, toxicity or intent, put a guardrail in front of an agent or LLM, score something against a rubric, or replace an LLM-based classifier to cut latency or cost. Also use it when they mention Laya, Jev, a "System 1 model", "typed decisions" or a "decision model", even if they never name Laya.

Creates Architecture Decision Records (ADRs) in MADR format and arc42 documentation. Generates plan-context.md as the context bridge to Claude Code. Use this skill when the user mentions "architecture", "ADR", "arc42", "Architecture Decision", "tech stack", "solution design", "system design", "architecture review", "plan-context", or similar. Also when requirements exist and the next step is technical structuring. This skill creates PROPOSALS. Claude Code makes the final decisions based on the real state of the codebase.

Author an engineering-change Product Requirements Document (PRD) that requires inspecting a code repository — verifying the requester's claims against the actual codebase, interviewing them down the design tree, deciding module and interface boundaries, then filing the result as a GitHub or GitLab issue. Use when the deliverable is a repo-grounded implementation spec for engineers. Trigger on "spec this feature out", "turn this idea into an issue", "engineering PRD", "write this change up before we build it", "plan this against the codebase", or a rough feature idea that must become an actionable engineering spec. Runs five phases (INTAKE, VERIFY, INTERVIEW, MODULES, WRITE + FILE) gated on a decision ledger. Boundary — for PM-facing product requirements aimed at stakeholders (Lean PRD, one-pager, AARRR or HEART metrics) use `prd-generator` instead.

Produce a rigorous, verified, fully-cited research report on ANY topic by running a disciplined five-stage pipeline: CLARIFY the question, PLAN (an editable research plan), FAN-OUT parallel search subagents, VERIFY every key claim (source-grounded + adversarial + cross-model), then SYNTHESIZE a cited report. Use this WHENEVER the user wants real research rather than a quick answer — "research X", "do a deep dive on Y", "write me a report / brief / literature review on Z", "compare A vs B and back it with sources", "what's the state of the art in …", "investigate …", "find evidence for/against …", "give me a market/landscape/competitor analysis", or any question where being wrong is costly and the answer needs citations. Trigger even when the user does not say the word "research" but clearly needs multi-source, fact-checked, cited output. This is the general-topic web-research orchestrator — not the codebase-to-wiki `deep-research` skill. For a fast single-fact lookup, answer directly instead.

Deep, read-only code comprehension mode — understand how a codebase actually works by tracing real execution before any design, decision, or change. Produces a fixed deliverable set (high-level execution flow, call graph, call hierarchy tree, per-method dependency table, data flow, external interactions, error propagation, important methods, hotspots, and safe extension points), then STOPS and waits for approval. Use whenever the user wants to understand, map, trace, or explain existing code rather than modify it — "how does X work", "trace the execution of", "map the call graph", "walk me through this feature", "what calls this method", "where are the entry points", "how does data flow", "find the hotspots", "where can I safely extend this", or "understand this codebase before I touch it". Also triggers on "code understanding mode" and "analyze the actual code execution". Read-only by design — it never proposes implementation or refactoring, only understanding.

Use when the user wants to hold work to a higher engineering bar, not a fast agreeable answer. Four modes. (1) ADVERSARIAL REVIEW — "grill me on these changes", "be my reviewer", "poke holes", "don't open a PR until I pass your test" — become a skeptical gatekeeper, not a rubber stamp. (2) PROVE-BY-DIFF — "prove to me this works", "show me it works", "diff behavior between main and my branch" — demonstrate the change empirically by exercising both branches, don't just assert it. (3) ELEGANT REWRITE — "scrap this and implement the elegant solution", "redo this properly", "stop patching, start over" — throw away the mediocre patch and rebuild from a clean design. (4) SPEC-FIRST — "spec this out first", "reduce the ambiguity before you start", or any vague hand-off — converge on a precise, unambiguous spec before touching code. Trigger whenever the user is deliberately raising the standard on a code change — challenging, proving, redoing, or de-risking — even if they don't name a mode.

Architecture and hard-won debugging lessons for customization enablement (plugins, MCP servers, agents, skills, instructions) in the agent host. Use when changing how customizations are discovered, published, enabled/disabled, or handed to a provider SDK; when a customization shows the wrong enabled state in the UI; or when a disabled MCP server or plugin is still reaching the model.

Use when validating an upstream pull request or dependency fix against VS Code tests using GitHub Actions CI build artifacts instead of building locally. Covers finding compatible binaries, verifying PR and merge-commit provenance, selecting a candidate runtime or build, comparing unchanged regression tests, and restoring the baseline.

Generic checklist for reviewing DevTools CLs (your own before upload, or someone else's on Gerrit). Covers test correctness (tautological/vacuous tests, cleanup, leaks), code clarity, CL hygiene, and points to the specialized skills to consult for imports, UI, testing, strings, models, and verification. Use when asked to review a CL, a diff, a patch, or to self-review before `git cl upload`.

Automatically fix Azure SDK CI/CD pipeline failures by applying code changes and verifying locally. USE FOR: "fix pipeline failure", "fix CI", "fix failing tests", "auto-fix and commit the fix", "fix build error", "fix mypy/pylint/type-check/lint errors", "auto-fix pipeline", "resolve pipeline failure". DO NOT USE FOR: pipeline analysis (instead use azsdk-common-pipeline-analysis), API design review, SDK publishing. INVOKES: azure-sdk-mcp:azsdk_package_build_code, azure-sdk-mcp:azsdk_package_run_check, azure-sdk-mcp:azsdk_package_run_tests, azure-sdk-mcp:azsdk_verify_setup.

Run PowerToys UITest.Next suites in persistent Hyper-V VMs over PowerShell Direct. Validate full default and constrained suites on Windows 10 and Windows 11, plus applicable ARM64 guests, then automatically hand implementation tasks to ui-tests-pipeline-ci for commit/push and CI validation. Local green is not end-to-end completion. Use for agentic UI-test iteration, reusable standard-user desktops, payload staging, evidence export, VM customization, clean baselines, or hosts without nested virtualization. Keywords: Hyper-V, local VM, virtual machine, PowerShell Direct, Copy-VMFile, VMBus, checkpoint, unattend, autounattend, ISO, Windows 10 LTSC, Windows 11, ARM64, Windows on ARM, UI tests, UITest.Next, winappcli, TRX, CI handoff.