Claude Skills by jeffreytse

Use when designing APIs, evolving existing interfaces, or planning a change to system behavior — to account for the fact that all observable behavior will be depended upon by someone, regardless of what the documented contract says.

Use when writing or reviewing code in a specific language or ecosystem — especially when contributors from different language backgrounds write in conflicting styles, or when code compiles but feels foreign to native speakers of the language.

Use when reviewing or writing code that feels unnecessarily complex, clever, or hard to follow — to simplify implementation without losing correctness.

Use when onboarding new engineers, tackling high-complexity problems, debugging subtle issues, or when code quality and knowledge sharing are priorities over individual throughput

Use when evolving a public API, shared interface, or data schema in a way that must remain backward-compatible with existing consumers during the migration period.

Use when writing or reviewing functions and modules — especially when callers encounter surprising side effects, error handling is inconsistent, or debugging requires tracing hidden state changes.

Use when deciding how to handle a change in a code review workflow — to categorize each change as Ship (merge without review), Show (merge then notify), or Ask (open for discussion before merging), reducing review bottlenecks without eliminating oversight.

Use when preparing a pull request or planning a feature branch — to keep changes small, focused, and independently reviewable so reviews are faster, more thorough, and easier to roll back.

Use when teams want to increase deployment frequency, reduce merge conflicts, or adopt continuous integration and delivery practices

Use when deciding whether to add a feature, abstraction, configuration option, or generalization that isn't required by a current, concrete requirement.

Use when a test or behavior that previously worked is now broken and the commit that introduced the regression is unknown — to use `git bisect` to binary-search the commit history and identify the exact commit that caused it.

Use when choosing or designing a Git branching model for a team or project

Use when establishing or improving a team's code review workflow, when reviews are causing bottlenecks, or when quality issues are escaping review into production

Use when building a gRPC service — to define the proto contract first, apply field numbering and naming conventions, model errors with google.rpc.Status, handle streaming patterns, and maintain backward compatibility across versions.

Use when establishing naming conventions for a new artifact type — APIs, database tables, files, functions, CLI commands, event names, skill libraries, or any identifier namespace that multiple contributors will add to over time.

Use when designing HTTP API endpoints — choosing resource names, HTTP methods, status codes, versioning strategy, and response shapes.

Use when a bug, test failure, crash, or unexpected behavior is reported — before proposing any fix. Use when behavior diverges from specification and the root cause is unknown.

Use when the user asks to commit or wants a git commit message drafted — for any staged changes, whether or not they know the Conventional Commits format.

Use when reviewing code for style consistency, readability, or adherence to a team or language style guide

Use when asked to review a pull request, diff, or code change — whether reviewing as an AI assistant or guiding a human reviewer on what to check and how to give feedback.

Use when a software project enforces Conventional Commits and wants automated changelog generation and semantic version bumping without manual writing at each release.

Use when a bug report is filed — to reproduce it, assess severity and priority, capture required context, and assign it before any diagnosis begins.

Use when writing or updating a CHANGELOG for a software project before a release

Use when changing a database schema — adding or removing columns, creating tables, adding indexes, or altering constraints.

Use when writing or reviewing an OpenAPI 3.x specification — to apply naming conventions, schema reuse, error modeling, pagination, security schemes, and examples that make the spec complete, consistent, and usable as a contract.

Use when fixing any bug — to write a failing automated test that reproduces the bug before implementing the fix, ensuring the fix is verified and the bug cannot silently recur.

Use when writing code review comments — to phrase feedback in a way that is kind, clear, and actionable; distinguishes blocking from optional suggestions; and helps the author improve without feeling attacked.

Use when writing Dockerfiles, configuring container runtimes, or deploying containerized workloads — to harden containers against privilege escalation, image vulnerabilities, and container escape.

Use when you need to separate code deployment from feature release, enable A/B testing, implement gradual rollouts, or allow rapid disabling of features in production without a rollback deployment.

Use when writing Terraform, CloudFormation, Pulumi, or Bicep templates — to detect misconfigurations, enforce least privilege IAM, and prevent insecure defaults before infrastructure reaches production.

Use when deploying workloads to Kubernetes — configuring RBAC, network policies, pod security standards, secrets management, and admission controls to prevent privilege escalation and lateral movement.

Use when detecting, auditing, or remediating drift between declared infrastructure configuration and actual deployed state

Use when designing or improving a continuous integration pipeline for a software project

Use when designing or hardening CI/CD pipelines — securing secret injection, restricting pipeline permissions, signing artifacts, and preventing supply chain attacks in GitHub Actions, GitLab CI, or Jenkins.

Use when selecting or designing a deployment strategy for releasing software to production safely

Use when designing a GitOps workflow where Git is the single source of truth for infrastructure and application configuration, with automated reconciliation to the desired state

Use when an organization's technology investment decisions are made ad hoc by whichever team has the loudest voice or the most urgent request — establishing an IT steering committee with defined authority to prioritize technology investments against business strategy and evaluate major project proposals, rather than letting technology spending decisions happen without a structured, cross-functional decision process.

Use when designing an internal developer platform (IDP) to reduce cognitive load on product teams, standardize infrastructure access, and improve developer experience at scale

Use when a production incident is declared or suspected, when building an incident response runbook, or when running a post-incident review that needs a structured process.

Use when auditing a Kubernetes cluster or reviewing a deployment for security — systematically checking all 10 OWASP Kubernetes Top 10 (2022) vulnerability classes with test commands and remediation guidance.

Use when an incident, outage, or significant production failure has occurred and needs to be documented — including partial outages, data pipeline failures, degraded performance events, or security incidents. Trigger once the incident is resolved and engineers are ready to analyze it.

Use when creating quality standards for a knowledge repository, skill library, documentation site, or any artifact collection that will accept external contributors over time — including when the current standard has grown inconsistent or unenforced.

Use when a non-trivial engineering change needs to be documented before implementation — including new services, significant refactors, API design, database schema changes, cross-team dependencies, or any work estimated above 1 week. Trigger before the sprint that contains implementation work.

Use when designing the props interface, composition model, or public API for a reusable React or UI component

Use when creating a new UI component, refactoring an existing one into something reusable, or reviewing a component design for composability, accessibility, and maintainability before implementation.

Use when preparing IoT devices for production deployment — removing default credentials, disabling debug interfaces, encrypting stored data, and implementing physical tamper detection.

Use when designing IoT device network interfaces — disabling unnecessary services, enforcing TLS for all communication, segmenting devices on isolated VLANs, and securing management APIs.

Use when building IoT fleet management infrastructure — designing secure device provisioning, certificate lifecycle, remote management, and decommissioning processes.

Use when designing firmware update mechanisms for IoT devices — implementing code signing, secure boot chains, and rollback protection to prevent malicious firmware from running on deployed hardware.

Use when auditing an IoT product or deployment — systematically checking all 10 OWASP IoT Top 10 vulnerability classes with test procedures, firmware analysis commands, and network scanning.