Claude Skills by jeffreytse

Use when you need to perform many distinct operations on a stable object structure — adding new operations without modifying the element classes by separating the operation from the data structure.

Use when assessing, cataloging, or prioritizing technical debt in an existing codebase or system

Use when designing public or partner APIs that must evolve without breaking existing integrations, or when API changes are causing client disruption

Use when designing a new REST API, adding endpoints to an existing API, or reviewing an API design for correctness, consistency, and long-term maintainability.

Use when designing a system where read and write workloads have significantly different scaling, consistency, or model requirements that a single unified model cannot serve efficiently.

Use when a centralized data platform has become a bottleneck, when data teams cannot keep up with business demand, or when designing data architecture for a large organization with multiple autonomous business domains

Use when designing systems that need loose coupling between services, asynchronous processing of high-volume events, or real-time data propagation across multiple consumers

Use when designing systems that communicate through events, including event sourcing and CQRS architectures

Use when starting a new software project or major initiative — classifying it as greenfield (no existing system or constraints), brownfield (must integrate with or replace an existing system), or retrofit (upgrading an existing system in place) before choosing an architecture and rollout strategy.

Use when decomposing a monolith or designing a new system using microservices architecture

Use when asked to design, evaluate, or document the high-level architecture of a system — including new systems, major feature additions, or scaling a system beyond its current design limits.

Use when a significant technical decision is being made or has just been made — including technology choices, architectural patterns, API contracts, data models, or security boundaries. Use before implementing a decision that would be costly to reverse.

Use when writing Solidity contracts with admin functions, upgradeable proxies, or multi-role permissions — implementing Ownable, role-based access control, and two-step ownership transfer to prevent unauthorized function execution.

Use when writing Solidity contracts that need randomness — NFT mints, lotteries, games — replacing insecure block variable entropy with Chainlink VRF or commit-reveal to prevent miner manipulation.

Use when writing DeFi smart contracts that rely on price feeds, randomness, or external data — preventing oracle manipulation via TWAP, multiple oracle sources, and circuit breakers.

Use when writing DeFi smart contracts with user-submitted transactions — implementing commit-reveal, slippage tolerance, and MEV-resistant patterns to prevent front-running and sandwich attacks.

Use when writing Solidity smart contracts that transfer ETH or call external contracts — applying the Checks-Effects-Interactions pattern and ReentrancyGuard to prevent reentrancy attacks.

Use when auditing a Solidity smart contract or reviewing a protocol before deployment — systematically checking all 10 OWASP Smart Contract Top 10 vulnerability classes with Slither/Foundry test procedures.

Use when running workloads in cloud environments — enabling GuardDuty, Security Command Center, or Microsoft Defender, and deploying Falco for Kubernetes runtime threat detection.

Use when writing serverless functions (AWS Lambda, Google Cloud Functions, Azure Functions) — validating event data from all trigger sources, preventing execution flow manipulation, and securing error handling.

Use when writing serverless functions — assigning per-function IAM execution roles with minimal permissions, disabling unused triggers, and securing function URLs and API authentication.

Use when managing secrets in serverless functions — replacing environment variable credentials with Secrets Manager or Parameter Store, auditing third-party Lambda layers, and preventing secret leakage in logs.

Use when building or refactoring cloud-native applications to ensure portability, scalability, and operability across environments

Use when estimating, forecasting, or auditing cloud infrastructure costs before provisioning, during architecture review, or at budget planning time

Use when designing cloud network architecture — structuring VPCs with public/private subnets, using VPC endpoints for AWS service access, and implementing security groups as stateful firewalls to contain blast radius.

Use when Kubernetes pods or cloud services need to access cloud APIs — replacing long-lived IAM keys with IRSA (AWS), Workload Identity (GCP), or Managed Identity (Azure) to eliminate credential leakage risks.

Use when establishing or auditing business continuity for cloud systems that must recover from catastrophic failures, data loss, or prolonged outages

Use when designing systems that must survive regional outages, minimize global latency, or meet geographic data residency requirements

Use when deploying serverless functions at scale — setting reserved concurrency, SQS visibility timeouts, recursion detection, and budget alerts to prevent denial-of-service via financial resource exhaustion.

Use when operating serverless functions in production — implementing structured logging, distributed tracing, anomaly-based alerting, and cold start monitoring to detect security incidents and performance degradation.

Use when cloud costs are growing faster than usage, when preparing for budget reviews, or when seeking to reduce infrastructure spend without degrading performance

Use when auditing a cloud-native application or infrastructure — systematically checking all 10 OWASP Cloud-Native Application Security Top 10 vulnerability classes with AWS CLI, kubectl, and Terraform commands.

Use when an organization needs an ongoing process to verify that users' system and data access remains appropriate over time — running periodic access recertification campaigns where accountable managers explicitly confirm or revoke each user's access, rather than granting access once and never systematically reviewing whether it's still needed.

Use when designing a data governance policy covering data ownership, classification, access control, lifecycle management, and regulatory compliance

Use when designing a new relational database schema, adding entities to an existing system, reviewing a schema for normalization issues, or planning migrations — before writing DDL or ORM models.

Use when designing, building, or reviewing a data pipeline for ingestion, transformation, or analytics

Use when designing a systematic data quality framework covering completeness, accuracy, consistency, timeliness, validity, and uniqueness across data pipelines and data warehouses

Use when an organization's data governance policy exists on paper but no specific person is actually accountable for a given data domain's quality, definitions, and appropriate use — assigning named data stewards to specific data domains with clear accountability, rather than leaving data quality and definitional consistency as an unowned, organization-wide responsibility.

Use when writing, reviewing, or optimizing SQL queries for correctness, performance, and maintainability

Use when starting a new API, adding a major feature to an existing API, or aligning multiple teams on an interface — to define the contract in an OpenAPI spec before writing any implementation code.

Use when replacing a large or deeply integrated component of a system incrementally without creating a long-lived feature branch, by introducing an abstraction layer that allows old and new implementations to coexist.

Use when a monorepo contains multiple independently versioned packages and each package needs its own changelog updated only when that package has actual changes.

Use when designing a project structure, framework, or tooling setup and deciding how much explicit configuration to require from developers.

Use when writing constructors, setters, or methods that accept or return mutable objects — to prevent callers from silently mutating internal state through shared object references.

Use when you notice duplicated code, logic, data, or knowledge across a codebase and need to decide whether and how to consolidate it.

Use when writing functions, modules, or services to assert internal assumptions — preconditions, postconditions, invariants — so that violated assumptions produce an immediate, loud error at the point of violation rather than propagating corrupt state downstream.

Use when contributing to a repository you cannot push to directly — to fork the repo, develop on your fork, keep it in sync with upstream, and submit changes via pull request without requiring write access to the canonical repository.

Use when a team has scheduled releases, maintains multiple supported versions simultaneously, or operates in a regulated environment requiring formal release approval gates.

Use when a team deploys continuously from a single mainline — to keep `main` always deployable, use short-lived feature branches, and ship via PR without release branches or long-lived parallel branches.

Use when deploying to multiple environments (staging, pre-production, production) and needing a branch-per-environment promotion model that is simpler than GitFlow but more structured than GitHub Flow.