Deepak Gupta markE-Books

Chapter 16 of 206 min readBy Deepak GuptaPublished

Appendix B: Skills Library

Fifteen skills ready to drop into .claude/skills/<name>/SKILL.md. Each is Pattern A (instructions only) so you can install it in seconds and extend it later. Adjust the descriptions to match the words your team actually uses.

B.1 commit-message

---
name: commit-message
description: Writes commit messages in Conventional Commits format. Use whenever
  committing, or when the user says commit, save progress, or checkpoint.
---
1. Read `git diff --staged`. If nothing is staged, ask what to stage.
2. Type: feat, fix, refactor, perf, test, docs, build, ci, chore.
3. Subject: imperative, under 72 chars, no period. Scope = top-level module.
4. Body only when the why is not obvious. Wrap at 72.
5. Add `BREAKING CHANGE:` footer for incompatible API changes.

B.2 pr-description

---
name: pr-description
description: Drafts pull request titles and bodies. Use when opening, drafting,
  or describing a PR, or when the user says ship it or write up the changes.
---
1. Read `git log main..HEAD` and `git diff main...HEAD`.
2. Sections: Summary, Why, Changes, How tested, Risks, Rollback.
3. Under Risks: migrations, auth or permission changes, config, new deps.
4. Link the spec or plan file if one exists. Never invent test results.

B.3 security-check

---
name: security-check
description: Quick security pass on current changes. Use before commits or pushes,
  and whenever changes touch auth, input handling, uploads, payments, or secrets.
---
1. Run `/security-review` on pending changes.
2. For auth or permission changes, also delegate to the security-reviewer agent.
3. Grep the diff for keys, tokens, and passwords; check new deps for necessity.
4. Summarize findings by severity. Fix Critical and High before continuing.

B.4 dependency-audit

---
name: dependency-audit
description: Audits dependencies for risk. Use when adding, upgrading, or removing
  packages, or when the user asks about vulnerable, outdated, or unused deps.
---
1. Run the ecosystem audit (`npm audit`, `pip-audit`, `govulncheck`, `cargo audit`).
2. For each new package: purpose, existing alternative in repo, maintainers,
   release cadence, install scripts, license. Flag names resembling popular packages.
3. List unused deps. Propose upgrades with changelog notes for breaking changes.

B.5 test-cases

---
name: test-cases
description: Generates test cases from code or specs. Use when the user asks for
  test cases, test scenarios, coverage gaps, edge cases, or a test plan.
---
1. Identify features and entry points in scope.
2. Per feature: happy path, invalid input, boundaries, auth states, errors, concurrency.
3. Output table: ID, area, preconditions, steps, expected, priority (P0 to P3).
4. Produce 10 at a time and pause for feedback before continuing.
5. List ambiguous requirements as questions.

B.6 migration-plan

---
name: migration-plan
description: Plans large refactors, upgrades, and data or code migrations. Use for
  framework upgrades, library swaps, schema changes, or changes across many files.
---
1. Inventory affected files and usages with counts.
2. Write docs/plans/<name>.md: goal, approach, phases, rollback, verification.
3. Prefer expand-migrate-contract for schemas and dual paths behind flags for code.
4. Define a per-file instruction that headless runs can apply mechanically.
5. Do not start edits until the user approves the plan.

B.7 incident-postmortem

---
name: incident-postmortem
description: Drafts blameless postmortems. Use after incidents, outages, or when the
  user mentions postmortem, RCA, incident review, or timeline.
---
1. Build a timeline with timestamps and sources.
2. Sections: Summary, Impact, Timeline, Root cause, Contributing factors,
   What went well, Action items (owner, due date).
3. Blameless language: systems and conditions, not individuals.
4. Mark any inference that lacks direct evidence.

B.8 docs-sync

---
name: docs-sync
description: Keeps documentation in sync with code. Use after API, config, CLI, or
  behavior changes, or when the user asks to update docs or the README.
---
1. From the diff, list user-facing changes.
2. Find docs referencing changed names, flags, endpoints, or env vars.
3. Update them in the existing style. Add a changelog entry under Unreleased.
4. Never document behavior that is not in the code.

B.9 a11y-audit

---
name: a11y-audit
description: Audits UI for accessibility against WCAG 2.2 AA. Use for UI changes,
  new components, or when the user mentions accessibility, a11y, or screen readers.
---
1. Check semantics, labels, alt text, focus order, visible focus, keyboard access.
2. Check contrast against design tokens. Check motion respects reduced-motion.
3. Run axe or the project's a11y tests if configured.
4. Report issues with WCAG criterion, location, and fix.

B.10 perf-profile

---
name: perf-profile
description: Investigates performance problems. Use when the user mentions slow,
  latency, timeouts, memory, CPU, bundle size, or performance regressions.
---
1. Reproduce and measure first. No optimization without a baseline number.
2. Profile with the stack's tool. Identify the top 3 hotspots with evidence.
3. Propose changes ranked by expected gain and risk.
4. Re-measure after each change and report before and after.

B.11 query-optimizer

---
name: query-optimizer
description: Optimizes SQL and ORM queries. Use for slow queries, N+1 problems,
  indexes, query plans, or database latency, even if not asked directly.
---
1. Capture the actual SQL (enable ORM query logging if needed).
2. Run EXPLAIN (ANALYZE only on non-production data).
3. Look for sequential scans, N+1 patterns, missing composite indexes, over-fetching.
4. Propose fixes with expected effect. Index changes go through a migration.

B.12 terraform-review

---
name: terraform-review
description: Reviews Terraform changes and plans. Use for any .tf change, terraform
  plan output, or infrastructure review request.
---
1. Run fmt, validate, and plan. Never apply.
2. List every destroy and replace with reason and data-loss risk.
3. Check tags, encryption, public exposure, IAM wildcards, and hardcoded values.
4. Run checkov or tfsec and summarize findings.

B.13 k8s-validate

---
name: k8s-validate
description: Validates Kubernetes manifests and Helm charts. Use for any change to
  manifests, charts, Kustomize overlays, or deployment configuration.
---
1. Render with kustomize or helm template; validate with kubeconform.
2. Check requests/limits, probes, non-root, read-only root FS, dropped capabilities.
3. Check image tags are pinned and no secrets appear in plain manifests.
4. Never run kubectl apply, delete, or edit.

B.14 api-contract

---
name: api-contract
description: Checks API changes for contract breaks. Use for any change to routes,
  request or response shapes, OpenAPI specs, GraphQL schemas, or protobufs.
---
1. Diff the spec or inferred contract against main.
2. Classify: additive, deprecating, or breaking.
3. Breaking changes need a version bump or migration path. Flag them loudly.
4. Update the OpenAPI or schema file and examples to match.

B.15 release-notes

---
name: release-notes
description: Generates release notes between two refs. Use when preparing a release,
  tagging a version, or when the user asks what changed or for a changelog.
---
1. Read commits and merged PRs between the two refs.
2. Group: New, Improved, Fixed, Breaking, Security.
3. Write for users, not engineers. Hide internal refactors.
4. List migration steps for breaking changes.