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
This skill should be used when the user asks to train, debug, scale, or improve ML models. PROACTIVELY activate for: (1) PyTorch, TensorFlow/Keras, JAX, Flax, Hugging Face Trainer/Accelerate training loops, (2) distributed training, DDP/FSDP/DeepSpeed, TPU/GPU setup, (3) mixed precision AMP/bf16, gradient accumulation, checkpointing, seeding, (4) overfitting, imbalance, loss functions, regularization, LR schedules, warmup, (5) memory optimization, gradient checkpointing, offloading, quantization-aware training. Provides: reproducible training best practices across deep learning and classical ML.
development
This skill should be used when the user asks to productionize, track, version, govern, monitor, or automate ML systems. PROACTIVELY activate for: (1) MLflow, Weights & Biases, Neptune, Comet, ClearML experiment tracking, (2) model registry, model versioning, artifact lineage, reproducibility, (3) Kubeflow, SageMaker Pipelines, Vertex AI Pipelines, Azure ML pipelines, Databricks workflows, (4) CI/CD, continuous training/evaluation, A/B tests, canary/shadow deployments, (5) drift detection, model monitoring, data validation, responsible AI governance. Provides: end-to-end MLOps architecture and operational safeguards.
development
This skill should be used when the user asks to optimize, export, serve, compress, or accelerate ML inference. PROACTIVELY activate for: (1) latency, throughput, p95/p99, batching, concurrency, KV cache, memory, or cost issues, (2) quantization INT8/INT4, GPTQ, AWQ, bitsandbytes, pruning, sparsity, distillation, (3) ONNX export, ONNX Runtime, TensorRT, TorchScript, torch.compile, XLA, OpenVINO, Core ML, TFLite, (4) Triton, TorchServe, TF Serving, BentoML, Seldon, KServe configuration, (5) edge deployment, CPU/GPU/TPU/Inferentia serving. Provides: hardware-aware inference optimization and safe benchmarking.
testing
This skill should be used when the user asks to tune hyperparameters, run sweeps, optimize search spaces, or use AutoML. PROACTIVELY activate for: (1) Optuna, Ray Tune, FLAML, AutoGluon, Hyperopt, Nevergrad, KerasTuner, W&B sweeps, (2) grid search, random search, Bayesian optimization, TPE, Gaussian processes, evolutionary search, (3) ASHA, Hyperband, successive halving, multi-fidelity optimization, population-based training, (4) learning-rate finder, batch-size search, early stopping, pruning, (5) reproducible sweep design and experiment analysis. Provides: budget-aware hyperparameter search strategy.