Claude Skills by jeffreytse

Use when preparing a mobile app for production release — especially apps handling financial data, DRM content, or anti-cheat systems — to raise the bar against reverse engineering, tampering, and runtime manipulation.

Use when implementing cryptographic operations in a mobile app — encrypting data, hashing passwords, generating keys, signing data, or establishing secure communication channels between the app and backend.

Use when storing sensitive data on a mobile device — credentials, tokens, PII, health data, financial data, or any data that should not be accessible to other apps or readable from device backups.

Use when diagnosing performance problems in a mobile app or conducting a systematic mobile performance review

Use when building a mobile app that collects, processes, or transmits user data — implementing data minimization, purpose limitation, consent management, and user data controls required by app store policies and privacy regulations.

Use when designing a mobile or web application that must function without a reliable network connection

Use when writing copy for push notifications or designing a push notification permission and delivery strategy

Use when assessing network security posture before a production launch, after a security incident, during compliance assessment, or on a periodic security review cycle

Use when designing network architecture for systems that handle sensitive data, require regulatory compliance, or need to contain blast radius from breaches

Use when users report slow response times, when SLO latency budgets are breached, or when investigating the network layer as a performance bottleneck

Use when investigating JavaScript bundle size, slow Time to Interactive, or preparing a performance budget for a web application

Use when a system is slow, latency has regressed, CPU or memory usage is unexpectedly high, or before optimizing any code — to measure first, identify real bottlenecks, and prioritize fixes by impact.

Use when provisioning infrastructure for a new system, preparing for anticipated traffic growth, or ensuring headroom before a major product launch

Use when designing or auditing HTTP caching, CDN configuration, or application-level cache policies for a web service

Use when a process shows continuously growing memory usage that doesn't stabilize, when OOM kills are occurring in production, or when heap dumps are needed to identify object accumulation

Use when diagnosing web performance problems or preparing a performance audit for a website or web application

Use when validating system performance before a launch, during capacity planning, after significant code or infrastructure changes, or when investigating SLO latency budget breaches

Use when designing an A/B test or online controlled experiment to evaluate a product change

Use when a new feature, product, or significant change needs to be defined before engineering begins — including greenfield features, major redesigns, API changes, or cross-team initiatives. Trigger when a problem or opportunity is validated and stakeholders need alignment before scoping work.

Use when defining a new product, feature, or service before committing resources to build it — especially for initiatives with unclear customer value, competing solution approaches, or significant investment required. Trigger before writing a PRD or technical spec for any initiative above a certain size threshold.

Use when writing user-facing release notes for a software product release

Use when writing user stories, acceptance criteria, or backlog items for product features

Use when a project's cost or schedule depends on multiple uncertain estimates — running a Monte Carlo simulation across many randomized combinations of those estimates to produce a probability distribution of likely outcomes, rather than relying on a single-point estimate that hides how much uncertainty actually surrounds it.

Use when managing a project with meaningful uncertainty — logging identified risks in a structured register, scoring each by probability and impact, assigning an owner and a response, and reviewing the register regularly, rather than tracking risks informally in conversation or memory where they get forgotten or under-prioritized.

Use when running a sprint retrospective — to surface what went well, what didn't, and produce a short list of actionable improvements with owners that the team commits to next sprint.

Use when starting a new sprint — to review the backlog, set the sprint goal, select stories, estimate capacity, and assign work before the team begins execution.

Use when investigating the root cause of a defect, incident, or recurring failure and need to move beyond symptoms to the underlying systemic cause.

Use when evaluating a system, process, or design for potential failure modes before they occur — systematically scoring each potential failure by severity, occurrence likelihood, and detectability to prioritize which failure modes most urgently need a design change or additional control, rather than addressing failures reactively only after they've already happened.

Use when reviewing error budget consumption, setting burn rate alerts, or making reliability investment decisions based on budget status

Use when establishing reliability targets for services, defining error budgets for engineering teams, or negotiating service commitments with customers

Use when defining or reviewing service reliability targets, error budgets, or SLI/SLO/SLA structures for a service

Use when validating system reliability before a major launch, when SLO breach investigations reveal unknown failure modes, or when establishing a proactive reliability practice

Use when validating incident response capabilities, onboarding new engineers to on-call, preparing for a major launch, or after significant architecture changes

Use when writing or updating an on-call runbook, incident response playbook, or alert-to-action guide

Use when your application consumes external or third-party APIs — configuring HTTP clients, validating TLS certificates, handling secrets, and sanitizing responses from upstream services.

Use when building any API endpoint — especially authentication endpoints, resource-creation endpoints, and any operation with a per-user or per-tenant cost — to protect against abuse, brute force, and resource exhaustion.

Use when implementing access control decisions — determining which users can perform which actions on which resources — in any API, web application, or service.

Use when deploying a web application that serves HTML — especially one with user-generated content, third-party scripts, or inline JavaScript — to restrict what resources the browser may load or execute.

Use when building an API or web service that needs to be called from browser JavaScript on a different origin — including public APIs, microservices accessed from SPAs, and third-party integrations.

Use when storing sensitive data at rest — PII, health records, financial data, cryptographic keys, or any data that must remain confidential if storage media is compromised.

Use when building or securing a GraphQL API — limiting query depth and complexity, disabling introspection in production, enforcing field-level authorization, and preventing batching abuse.

Use when implementing JWT-based authentication or authorization — covering token generation, algorithm selection, validation, expiry, and revocation for stateless APIs.

Use when designing encryption key lifecycle — generating, storing, rotating, and retiring cryptographic keys for application secrets, database encryption, and API signing keys.

Use when building microservices that communicate with each other — implementing service-to-service mTLS, JWT propagation for user identity, and API gateway authentication to prevent lateral movement between services.

Use when implementing OAuth 2.0 or OpenID Connect flows — building an authorization server, integrating a third-party identity provider, or securing API access delegation between services.

Use when storing user passwords or credentials in a database — covers algorithm selection, work factor configuration, and migration from legacy hashing schemes.

Use when configuring a new application, framework, or service — ensuring security is enabled out of the box by setting restrictive defaults for cookies, headers, database connections, and framework security features.

Use when configuring any web server or application that serves HTTP responses to browsers — covers the full set of security response headers that harden against common attacks.

Use when configuring HTTPS on a web server, API gateway, or load balancer — covers cipher suites, TLS version enforcement, certificate management, and HSTS.

Use when you need to verify that a CORS policy is actually enforced correctly — after configuring CORS, before shipping an API, or during a security review. Tests origin reflection, null origin, subdomain bypass, wildcard-with-credentials, and preflight correctness.