plugins/tsql-master/skills/execution-plan-analysis/SKILL.md
This skill should be used when the user asks to analyze SQL Server execution plans, .sqlplan files, ShowPlan XML, actual vs estimated plans, plan warnings, or operator costs. PROACTIVELY activate for: .sqlplan triage, ShowPlan XML inspection, high-cost operator ranking, scan vs seek review, residual predicate analysis, CONVERT_IMPLICIT warnings, bad row estimates, cardinality-estimation warnings, partition elimination verification, missing-index suggestions, unused-index warnings, spills, key lookups, sorts, hash joins, and plan-regression evidence gathering. Provides: plan triage workflow, operator-cost ranking heuristics, warning interpretation rubric, and rewrite/index recommendation gating.
npx skillsauth add JosiahSiegel/claude-plugin-marketplace execution-plan-analysisInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Use this skill to triage SQL Server actual or estimated execution plans, especially .sqlplan ShowPlan XML. Treat the plan as evidence, not a verdict: validate schema, data types, indexes, row counts, partitioning, parameter values, and local-vs-linked-server execution before recommending rewrites or indexes.
Ask for the smallest set needed to verify the plan:
Use ../_shared/optimization-intake.md and ../_shared/assumption-tracker.md for intake and assumption status tracking.
Record whether the plan is actual or estimated. Actual plans expose runtime row counts, warnings, spills, memory grant use, and actual partition access. Estimated plans can still reveal access paths, conversions, missing index requests, and join choices, but cannot prove runtime misestimates or spills.
Capture:
Sort operators by estimated subtree or operator cost to find likely work centers, but do not tune solely by percentage. A 90% operator in a tiny query may not matter; a low-percentage operator inside a repeated nested loops branch can dominate runtime.
For each candidate operator, record:
| Evidence | What to capture | |---|---| | Operator | Physical and logical operation | | Object | Table, index, or remote source | | Cost | Estimated operator/subtree cost and relative percentage | | Rows | estimated rows, actual rows, executions, rows read | | Predicates | seek predicates, residual predicates, probes, join predicates | | Warnings | spills, conversions, missing indexes, no join predicate, cardinality issues |
A seek is not automatically good and a scan is not automatically bad. Verify how much data was read vs returned.
SeekPredicates vs Predicate. A seek that reads millions and filters later may need a better key order, computed column, filtered index, or rewrite.Search ShowPlan for CONVERT_IMPLICIT, PlanAffectingConvert, and scalar operators around indexed columns. Prioritize conversions on the column side of predicates and joins because they can block seeks or distort estimates.
Classify each conversion:
Recommended fixes must preserve semantics: align parameter types, temp-table types, literals, computed columns, or source column definitions when schema change is allowed.
Large estimate errors can explain bad join order, memory grants, spills, and wrong join algorithms.
Flag when any operator has:
Tie recommendations to root cause: update statistics, create filtered statistics/indexes, use temp tables for phased cardinality, address parameter sensitivity, or rewrite predicates.
For partitioned objects, prove whether the plan eliminates partitions.
Check:
Warn against unsafe partition predicates such as wrapping the partition column in functions, comparing mismatched types, or filtering on a related date column that is not the partitioning column unless a trusted constraint proves equivalence.
Missing-index warnings are suggestions for one compiled statement, not a design. Convert them into candidate indexes only after comparing with existing indexes, workload patterns, write cost, and constraints.
Also inspect unused or duplicate indexes if the plan shows update overhead or if index maintenance is part of the ask. Do not recommend dropping indexes from a single plan; require workload evidence.
Use this format:
For ShowPlan XML attributes, XPath-style lookups, and operator-cost interpretation, see references/showplan-xml-checklist.md.
development
Use for Clerk sessions, tokens, webhooks, orgs, and security. PROACTIVELY activate for session tokens, JWT templates, getToken(), custom claims, pending sessions, multi-session UX, organizations, roles, permissions, system vs custom permissions, features/plans, MFA/passkeys/password policy/bot protection, Clerk webhooks, Svix signatures, verifyWebhook(), user/org sync, retries/replays, environment variables, custom domains, secret rotation, logs, and auth security reviews. Provides token semantics, webhook idempotency, authorization defaults, and hardening checklist.
tools
Use for Clerk in Next.js. PROACTIVELY activate for @clerk/nextjs setup, App Router auth()/currentUser(), clerkMiddleware(), proxy.ts/middleware.ts, createRouteMatcher(), protected pages/layouts/Route Handlers/Server Actions/API routes/tRPC, auth.protect() role/permission/token checks, ClerkProvider placement, server-only clerkClient, Link prefetch, redirects, 401/404 auth failures, custom domains, __clerk proxy paths, and deployment gotchas. Provides file patterns, server/client boundary rules, matcher templates, and production checks.
development
Use for Clerk frontend auth flows. PROACTIVELY activate for React, JavaScript, Vue, Nuxt, Astro, Expo, React Router, TanStack React Start, or SPA setup; ClerkProvider and publishable-key wiring; SignIn/SignUp/UserButton/UserProfile/OrganizationSwitcher; custom useUser/useAuth/useClerk/useSignIn/useSignUp/useSession/useOrganization flows; multi-session UX; cross-origin getToken() fetches; loading states, redirects, routing, CORS/cookies, or hydration bugs. Provides SDK selection, UI patterns, token-fetch templates, and frontend gotchas.
development
Use for Clerk dev/prod readiness, deployment, and multi-language implementation planning. PROACTIVELY activate for environment variables, pk_test/sk_test vs pk_live/sk_live, local dev, preview/staging/prod instances, domains/DNS, redirects, OAuth credentials, custom domains/proxy, authorizedParties, CSP, CORS/cookies, webhooks/tunnels, Vercel/Netlify/Cloudflare/API gateways, monitoring/troubleshooting, and backends in Node/Express/Fastify, Python/FastAPI/Django/Flask, Go, Ruby/Rails, Java/Spring, .NET, PHP/Laravel. Provides checklists, rollout plans, and language-portable patterns.