Claude Skills by khuynh22

Designs an interface that others will depend on: endpoints, function signatures, events, schemas, and their versioning and error contracts. Use before publishing an API, when adding a public function or endpoint, or when changing something callers already use. Treats every observable behavior as a promise.

Records a non-obvious technical choice as an ADR with context, options, the decision, consequences, and the condition that should reopen it. Use when choosing between technologies or designs, when a decision is expensive to reverse, or when someone will ask in six months why it was done this way. Also use to review a proposed design.

Runs a tracker ticket through the whole lifecycle without stopping at each stage boundary - requirements, plan, build, review, release plan - with escalations routed to a terminal tier instead of to a waiting human. Use when a ticket already carries enough intent to work unattended, when nobody is available to answer stage-by-stage questions, or when the ask is to work an issue end to end and report back. Refuses to deploy, refuses to push, and refuses to resolve product intent on the human's...

Confirms a user-interface change actually works by loading it in a real browser and checking rendering, interaction, keyboard access, console output, network calls, and responsive behavior. Use after any visual or interactive change, when a test passes but the page might not, or before claiming a UI change is done.

Reviews a diff, branch, or pull request across correctness, security, architecture, readability, and performance, returning ranked findings with file and line references and a concrete fix for each. Use before merging, when checking code written by someone or something else, or when a change needs a quality gate.

Answers a question from data honestly: define the metric and its denominator up front, verify the data is fresh and complete, reconcile against a number somebody already trusts, segment before concluding, rule out the boring explanations, and ship the caveat alongside the number. Use when asked why signups, revenue, or conversion dropped last week, why a metric moved, what a number really means, or whether a dashboard can be believed.

Designs the warehouse tables analysts read: grain declared before any column, staging and mart layers kept apart, one home per metric definition, slowly changing dimensions that keep their history, a uniqueness test on every key, and reconciliation against a total somebody already believes. Use when building or refactoring a dbt or SQL transformation, when a join fans out, or when one metric is computed three different ways.

Builds an ingestion or ELT job that can be safely re-run: declared contract and grain, idempotent writes, an explicit rule for late and duplicate records, an incremental path proven against a full recompute, and freshness alerting on rows rather than on task exit codes. Use when building or fixing a pipeline, when planning a backfill or replay of historical rows into a warehouse table, when a schema change needs a backfill, or when a job produced duplicate rows.

Adds the checks that catch a silently broken table: freshness, volume against a trailing band, uniqueness on the grain, completeness, validity, and reconciliation against an upstream total, each alerting a named owner. Use when a table has no tests, when a wrong number reached a dashboard, when a scheduled job exited successfully but wrote zero rows, or before trusting data enough to act on it.

Writes documentation for one reader doing one task: READMEs, quickstarts, how-to guides, API reference, runbooks, and changelogs. Use when docs are missing, stale, or unreadable, when a change made existing docs wrong, or when someone new cannot get the project running. Verifies every command and example before publishing.

Implements microcontroller firmware within hard limits: static memory, bounded interrupt handlers, a testable HAL boundary, measured stack and flash budgets, and on-target verification. Use for embedded work on an MCU, driver or RTOS task code, or a change that must be proven on hardware rather than in a test runner.

Implements user interface work state by state: empty, loading, error, partial, and degenerate content, with native elements, derived state, and keyboard support. Use when building or changing a component, page, form, or flow, or when a UI change needs to hold up outside the happy path.

Runs a live production failure: set severity, check what changed, mitigate before diagnosing, communicate on a clock, then write a blameless postmortem. Use when production is broken right now, when an outage or degradation needs coordinating, or when writing the postmortem afterwards.

Executes a multi-task plan one task at a time, keeping every commit atomic and green before starting the next. Use when working through a task list, when a change is large enough to need checkpoints, when commit hygiene matters for bisect, or when tempted to build several things at once. Refuses to begin the next task while the previous one is unverified.

Takes a model to production without fooling anyone: measure a non-learned baseline first, split by time, hunt leakage, compute features once for training and serving, evaluate the worst slice, roll out behind a shadow or canary, monitor input and prediction drift, and pin a rollback to the previous version. Use when shipping, retraining, or debugging a model whose live quality has degraded.

Fixes measured slowness by setting a budget, profiling to find where time actually goes, changing one thing, and measuring again. Use for a latency regression, an N+1 query, memory growth, a slow build or test suite, or a Core Web Vitals miss. Refuses to optimize anything without a baseline number.

Plans a deployment so every step is independently reversible and the result is observable: rollback first, then sequencing, feature flags, canary or percentage rollout, abort criteria, and alerting. Use before shipping to production, when a release involves a migration or a flag, or when a change has no rollback path yet.

Extracts what someone actually needs by asking one question at a time, separating the problem from the solution they proposed. Use when a request is vague, when you are about to guess at intent, when scope keeps shifting, or when nobody has said what done means. Ends with written requirements and acceptance criteria.

Audits a change or a system for reachable vulnerabilities by tracing untrusted input to its sinks and checking authorization at every new path. Use when code touches authentication, secrets, cryptography, file paths, shell execution, deserialization, or any input crossing a trust boundary, and before exposing anything to the internet.

Removes complexity that is not paying for itself: dead code, needless abstraction, duplicated logic, and configuration nobody sets. Use when code is harder to read than the problem is hard, before extending a messy area, or when a diff can be made smaller without losing behavior. Never changes behavior.

Turns gathered requirements into a written specification that an implementer can build from without asking follow-up questions. Use when requirements are known but not written down, before starting a feature that spans several tasks, or when a spec needs reviewing for gaps and contradictions. Produces a committed document, not a chat message.

Finds the actual cause of a defect by reproducing it, narrowing the search space by bisection, and proving the diagnosis before changing code. Use for a crash, a stack trace, a flaky or intermittently failing suite, or behaviour that differs from expectation and resists an obvious fix. Refuses to change code before the cause is proven.

Writes the failing test first, watches it fail for the right reason, then makes it pass with the smallest change. Use before implementing any feature or bug fix, when adding a regression test, or when a change needs proof it works. Refuses to write implementation code before a red test exists.

Hands work up to a higher tier, or down to a lower one, with a structured packet so no context is lost. Use when a task exceeds the current agent's ceiling, when a brief is too vague to execute, when two agents disagree, or when decomposing work for someone else to do. Escalating correctly is a successful outcome, not a failure.

Routes an incoming engineering request to the right team member and the right workflow, and explains the tier system. Use at the start of any development work when it is unclear who should do it, which skill applies, or how much process a task deserves. Also use when a task turns out to be bigger than it looked and needs re-routing.

Splits a spec into an ordered list of tasks, each with a single verifiable outcome, an assigned tier, and a delegation brief. Use when a spec exists but there is no plan, when work must be divided across agents or people, or when a task is too large to verify in one step. Produces a plan file, not code.