AI-SKILLS

accessibility-review

Audit a UI for real accessibility, keyboard-first, with concrete failures and fixes rather than checkbox compliance. Use when reviewing or building any user interface.

accessible-forms

Build forms with associated labels, identified errors, clear instructions, and autocomplete attributes. Use when creating or auditing forms for accessibility.

alt-text-writing

Write alt text that conveys an image's purpose, marks decorative images empty, and handles functional and complex images. Use when adding images to content or auditing alt text.

Use ARIA correctly by preferring native HTML, applying roles/states/properties only where needed, and following known widget patterns. Use when making custom components accessible or fixing broken ARIA.

color-contrast

Meet WCAG contrast ratios for text and non-text, never rely on color alone, and verify with tools including in dark mode. Use when choosing colors for UI or auditing readability.

keyboard-navigation

Make interfaces fully keyboard-operable with logical focus order, no traps, skip links, and roving tabindex where needed. Use when building interactive UI or auditing keyboard accessibility.

screen-reader-testing

Test with real screen readers, verifying announcements, live regions, and navigation, not just automated checks. Use when validating accessibility of UI that automated tools cannot fully assess.

agent-memory

Design memory for an AI agent so it recalls what matters and forgets the rest, without drowning in its own history. Use when adding persistence, context recall, or long-running state to an agent.

api-design

Design HTTP and library APIs that are predictable, hard to misuse, and stable under growth. Use when creating or reviewing endpoints, public functions, or wire formats.

api-client-design

Build API clients with retries, timeouts, pagination, and error surfacing baked in, and test them properly. Use when writing a client for an external or internal API.

api-deprecation

Retire API surface with sunset headers, usage tracking, migration guides, and enforced timelines. Use when removing an endpoint, field, or version that consumers depend on.

api-pagination-design

Design pagination with cursors for stable ordering, sensible page limits, and awareness of total-count cost. Use when adding pagination to a list endpoint or fixing duplicate or skipped items under load.

Show all 100 bundled skills

api-sdk-design

Design SDKs that feel idiomatic per language, handle auth and resilience, and version cleanly. Use when building an official client library for your API.

graphql-schema-design

Design GraphQL schemas that model the domain, solve N+1 with dataloaders, and handle pagination and errors, knowing when REST wins. Use when building a GraphQL API or evaluating GraphQL against REST.

grpc-services

Design gRPC services with clean proto contracts, versioning, streaming patterns, and deadline propagation. Use when building high-performance service-to-service APIs or evaluating gRPC against REST.

openapi-contracts

Drive API development from an OpenAPI spec as the contract, with linting, codegen, and drift detection. Use when building or documenting REST APIs and wanting the spec to be the single source of truth.

api-gateway-pattern

Use an API gateway for cross-cutting edge concerns without letting it absorb business logic, including the BFF variant. Use when fronting services with a gateway or untangling a bloated one.

architecture-decision-records

Capture each significant architecture decision as a short, immutable record of context, decision, and consequences with a tracked status. Use when a choice is costly to reverse or crosses teams and the reasoning must outlive the people who made it.

architecture-diagrams

Draw architecture diagrams at consistent C4-style levels, as code, kept honest and fit to the audience. Use when documenting a system's structure or when existing diagrams mislead more than they help.

coupling-analysis

Measure and manage coupling with afferent/efferent metrics, change amplification, and one-way dependency rules. Use when a codebase is hard to change safely or you are deciding where to draw module boundaries.

event-driven-architecture

Design event-driven systems with well-shaped events, schema contracts, and honest handling of choreography's costs. Use when decoupling services through events or debugging an event system nobody can reason about.

hexagonal-architecture

Isolate domain logic behind ports it owns while frameworks, databases, and transports live in adapters that plug into those ports. Use when business rules keep getting entangled with the web framework or database and you want the core testable and swappable in isolation.

layered-architecture

Organize a system into layers with one permitted direction of dependency and enforce that direction mechanically at the import level. Use when a codebase is sliding toward tangled cross-references and you need a rule a linter can check, not a convention people forget.

microservices-boundaries

Split services along business capabilities with clear data ownership, avoiding the distributed monolith. Use when decomposing a system into services or diagnosing services that must always deploy together.

monolith-first

Build a modular monolith with clean internal seams and split to services only on proven pressure. Use when starting a system or resisting premature microservice decomposition.

scalability-planning

Plan scalability from a load model and bottleneck math, designing for realistic growth without premature over-engineering. Use when designing for scale or after a load-driven incident.

service-mesh-tradeoffs

Judge whether a service mesh's east-west traffic features justify its operational complexity, versus a library approach. Use when evaluating a service mesh or reconsidering one that added more pain than value.

technical-vision

Write a north-star architecture document that sequences migrations and guides decisions without pretending to be a roadmap. Use when a team's technical direction is unclear or every design debate restarts from zero.

api-error-responses

Return structured problem+json errors with stable codes, retryability signals, and correlation ids. Use when standardizing API error shapes or making failures debuggable across services.

api-versioning

Version APIs so existing clients keep working while the contract evolves, with a real sunset process. Use when choosing a versioning scheme or planning a breaking API change.

background-jobs

Run asynchronous work through queues with safe retries, poison-message handling, and idempotent jobs. Use when moving work out of the request path or fixing duplicated, stuck, or lost jobs.

file-storage-design

Store user files in object storage with presigned transfers, validation, and lifecycle rules. Use when building upload/download features or moving file handling off application servers.

graceful-shutdown

Drain servers on SIGTERM so deploys and scale-downs drop zero requests and corrupt no jobs. Use when implementing shutdown handling or chasing errors that spike during every deploy.

health-checks

Design liveness, readiness, and startup probes that heal real failures without amplifying outages. Use when wiring health endpoints or debugging restart loops and drained fleets.

idempotency-keys

Implement idempotency keys so retried requests produce one effect and one canonical response. Use when making POST endpoints retry-safe, especially payments and order creation.

message-queues

Choose between queues and streams, and configure ordering, consumer groups, and dead letters correctly. Use when introducing async messaging or debugging lost, duplicated, or reordered messages.

multi-tenancy

Isolate tenants in data, code, and capacity, choosing the right isolation model per tier. Use when designing SaaS data models or containing noisy-neighbor and cross-tenant risks.

request-validation

Validate requests at the boundary with schemas, reject unknown fields, and return errors clients can act on. Use when hardening API input handling or standardizing validation across endpoints.

rest-endpoint-design

Model REST endpoints around resources with correct status codes, partial updates, and bulk operations. Use when designing or reviewing HTTP APIs and their URL, method, and response conventions.

timeouts-and-retries

Set timeout budgets per hop and retry policies that cannot amplify an outage, with circuit breakers where they pay. Use when calling downstream services or diagnosing cascading latency and retry storms.

transactional-outbox

Publish events reliably by writing them in the same transaction as state changes and relaying asynchronously. Use when a service must update its database and emit a message without losing either.

webhooks-design

Deliver webhooks with signatures, retries, and ordering rules consumers can actually build against. Use when adding webhooks to a product or hardening delivery and verification on either side.

architecture-review-board

Run an Architecture Review Board that filters proposals by blast radius, reviews them through fixed lenses, issues binding decisions recorded as ADRs, and honors an appeals path. Use when a technical choice crosses team boundaries and needs a durable, accountable decision instead of hallway consensus.

bar-raiser-interviewing

Interview as an Amazon-style bar raiser who holds an independent veto and judges each candidate against the long-term hiring bar. Use when you sit on an interview loop as the neutral interviewer accountable for the bar, not for filling the team's open seat.

canary-analysis

Judge a canary release against a concurrent baseline using pre-set metric gates, automatic rollback, and statistically honest windows. Use when a deploy is rolling out to a slice of production traffic and you must decide pass, hold, or revert.

chaos-gameday

Run a game day that injects a real failure on purpose under safety rails, then captures what monitoring, runbooks, and responders actually did. Use when you want to prove resilience before an incident tests it for you, or to rehearse a team on a failure it has never handled.

deprecation-program

Run a deprecation from usage telemetry through a hard sunset date, with migration tooling and staged comms, so a system retires without stranding its callers. Use when you own an API, endpoint, library, or service that must be turned off while other teams still depend on it.

design-critique

Run a design critique with a clear presenter contract, feedback rules that attack the work not the person, and captured decisions. Use when a designer brings work in progress to a group for structured feedback rather than approval.

design-doc-google-style

Write a Google-style design doc that argues a decision through context, goals, and rejected alternatives before code is written. Use when a change is large enough that picking the wrong approach is expensive to undo.

dogfooding-program

Run an internal dogfooding program with staged cohorts, one feedback intake, and numeric exit criteria to general availability. Use when a pre-release product needs real internal use to surface bugs and adoption risk before it ships to customers.

exec-briefing

Brief executives with the answer first, the whole thing on one page, risks paired with the decision you need, and no surprises. Use when you must get a decision or an update in front of leadership who have five minutes and no context.

hiring-loop-design

Design a hiring loop where each interview gathers distinct signal against an anchored rubric and the debrief resists groupthink. Use when standing up or fixing an interview panel and you want a decision based on evidence, not overlapping impressions.

launch-review

Run a launch review that gates a release behind a readiness checklist, named sign-offs, and a clear no-go authority. Use when a user-facing launch is about to ship and a bad release would be costly to walk back.

okr-cascade

Cascade OKRs so team and individual goals ladder up to company strategy without sandbagged targets or scoring that rewards easy wins. Use when setting quarterly or annual objectives across more than one team and you want alignment, not a spreadsheet of restated tasks.

oncall-handoff

Hand off an on-call rotation by transferring open incidents, watch items, and the tribal context runbooks miss. Use at the end of a shift or rotation when the pager passes to the next responder and continuity of understanding matters.

open-source-review-board

Run an open source review board that gates incoming dependencies on license compatibility, sets the policy for contributing back, and requires a security review before adoption. Use when an organization needs consistent control over which OSS it pulls in and what it publishes.

perf-calibration

Run a performance calibration meeting so ratings across a group rest on comparable evidence and a consistent bar, not one manager's advocacy. Use when managers are finalizing performance ratings for a team or org and you need consistency and bias control before results are delivered.

postmortem-review-board

Run an org-level board that grades incident postmortems against a quality bar, promotes cross-cutting fixes to owned work, and reads across incidents for trends. Use when your organization writes enough postmortems that reviewing them one at a time hides the systemic pattern.

prfaq-working-backwards

Write an Amazon PR-FAQ that starts from a launch-day press release and hard customer questions so an idea is tested on the customer before it is built. Use when proposing a new product or feature and you need to prove it is worth building.

promo-packet

Assemble a promotion packet that proves sustained impact at the next level, with calibrated scope claims and evidence a committee can verify. Use when you or someone you manage is going up for promotion and you need a case, not a list of tasks.

quarterly-planning

Run quarterly planning with honest capacity, negotiated cross-team dependencies, and an explicit cut line that names what will not get done. Use when a team commits to a quarter of work and needs the plan to survive contact with reality.

rfc-process

Run a Request for Comments process so a proposal reaches the right audience, collects objections inside a bounded window, and records a decision people can point to later. Use when a change affects teams beyond the author's and needs durable buy-in.

security-development-lifecycle

Apply Microsoft's Security Development Lifecycle so threat modeling, tooling, and sign-off are built into each phase instead of bolted on before ship. Use when building or shipping software that takes untrusted input or handles sensitive data and you need a repeatable security process, not a one-time audit.

six-pager-narrative

Write an Amazon six-pager, a narrative memo read in silence at the start of a meeting so a decision rests on reasoning rather than a presenter's charisma. Use when running an operating, strategy, or investment review that must reach a real decision.

tech-radar

Maintain a tech radar that sorts technologies into adopt, trial, assess, and hold against a real evidence bar, and pairs each adoption with a sunset. Use when an organization needs a shared, current view of which tools and techniques to reach for and which to retire.

war-room-protocol

Run a war room for a live incident with defined roles, a steady cadence, a decision log, and explicit stand-down criteria. Use when a high-severity outage or crisis needs coordinated response across teams and the improvised version is descending into chaos.

accessibility-specialist-role

Operate as an accessibility specialist who audits against WCAG, trains teams to stop shipping the same defects, and owns the compliance sign-off. Use when a product needs to be usable with a keyboard, a screen reader, or magnification and someone must certify it before launch.

backend-engineer-role

Operate as a backend engineer who designs stable API contracts, guards data integrity, and ships services that are operable on day one. Use when building or reviewing a service, API, or data path and you want production-grade engineering discipline.

cloud-architect-role

Operate as a cloud architect who lays the landing zone, governs cost, and sequences migration for an organization. Use when asked to stand up a cloud foundation, put guardrails and cost controls in place, or plan how workloads move to the cloud.

cto-advisor-role

Operate as a CTO-level advisor who turns business goals into build-or-buy calls, org design, technology bets, and a named risk posture. Use when a leader needs a technology strategy that a board and a finance team will both accept.

data-engineer-role

Operate as a data engineer who ships pipelines to a freshness SLA, enforces schema contracts at the source, and owns data quality end to end. Use when building or reviewing a pipeline, warehouse table, or ingestion path that other teams will trust.

data-scientist-role

Operate as a product data scientist who frames falsifiable hypotheses, analyzes experiments, and reports results without flattering the launch. Use when asked to design an A/B test, read out an experiment, or turn a metric question into a decision.

devops-engineer-role

Operate as a DevOps engineer who owns the delivery pipeline, keeps environments identical, and makes every deploy reversible. Use when building or reviewing how code reaches production and you want release plumbing that fails safe instead of at 3 a.m.

engineering-manager-role

Operate as an engineering manager who grows people, protects delivery health, hires deliberately, and shields the team from noise. Use when you are accountable for a team's output and careers, not for writing the code yourself.

Web & Frontend Listed

frontend-engineer-role

Operate as a frontend engineer who defends UX quality, enforces performance budgets, and partners with design instead of just closing tickets. Use when building or reviewing a user-facing web feature and you want an engineer's operating discipline, not raw code.

growth-engineer-role

Operate as a growth engineer who moves a funnel metric through instrumented, fast experiments and refuses to win with dark patterns. Use when your job is to raise activation, retention, or conversion with measured changes, not guesses.

ml-engineer-role

Operate as an ML engineer who takes a research model to reliable production behind eval gates and keeps it healthy across its lifecycle. Use when asked to productionize a model, build a training or serving pipeline, or set promotion criteria.

mobile-engineer-role

Operate as a mobile engineer who plans around release trains, a real device matrix, and app-store rules that a web engineer never faces. Use when building or reviewing an iOS or Android feature and you need mobile-specific release and compatibility discipline.

open-source-maintainer-role

Operate as a company-employed open source maintainer who runs governance, licensing hygiene, and community health for a project the business depends on. Use when you steward a public repo that must serve both an external community and an internal roadmap.

performance-engineer-role

Operate as a performance engineer who sets budgets, gates regressions in CI, and runs profiling as a service other teams rely on. Use when latency, throughput, memory, or GPU utilization matters and you want measured wins, not folklore optimizations.

platform-engineer-role

Operate as a platform engineer who builds golden paths for internal developers and earns adoption on merit. Use when asked to design an internal developer platform, pave a common workflow, or prove a platform is being adopted.

ci-cd

Build CI/CD pipelines that are fast, trustworthy, and safe to deploy from. Use when creating or fixing continuous integration, delivery workflows, or release automation.

code-documentation

Write code comments and API docs that carry what the code cannot say, and nothing it already does. Use when documenting functions, modules, or tricky passages.

Code & Development Listed

code-review

Review code changes for correctness, security, and maintainability with severity-ranked, evidence-based findings. Use when asked to review a diff, a pull request, or a file before merge.

commit-messages

Write commit messages that explain change and intent so history stays useful. Use when committing work or asked to draft a commit message for a diff.

containerization

Write container images and compose setups that are small, reproducible, and safe to run. Use when writing Dockerfiles, docker-compose files, or debugging container behavior.

debugging

Find the root cause of a bug with a hypothesis-driven loop instead of guess-and-patch. Use when something fails, crashes, or behaves wrongly and the cause is not yet known.

design-systems

Build and maintain a design system that keeps a product visually consistent and fast to build. Use when creating design tokens, component libraries, or UI guidelines.

error-handling

Design error handling that fails loudly, recovers deliberately, and tells the person exactly what to do. Use when writing failure paths, retries, or user-facing errors.

frontend-state

Decide where frontend state lives and how it flows, so UIs stay predictable as they grow. Use when structuring components, adding state, or untangling prop-drilling and sync bugs.

mcp-server

Design a Model Context Protocol server that exposes tools and data to AI agents safely and legibly. Use when building an MCP server or deciding what to expose to an agent.

observability

Instrument software so production questions get answered from signals, not guesses. Use when adding logging, metrics, tracing, or alerts, or when a system is hard to debug in production.

prompt-engineering

Build prompts that get accurate, reliably-shaped output from any LLM, choosing the right technique for the task. Use when writing, improving, or debugging a prompt.

refactoring

Improve code structure in small, always-green steps without changing behavior. Use when asked to clean up, simplify, restructure, or de-duplicate working code.

research-synthesis

Turn multiple sources into a defensible, source-attributed answer that separates fact from inference. Use when researching a question across documents, articles, or search results.

schema-design

Design database schemas that stay correct under growth and change. Use when creating tables, modeling relationships, or planning schema migrations.

security-review

Review code for the vulnerabilities that actually get exploited, ranked by real risk with concrete attack scenarios. Use when reviewing changes that touch input handling, auth, secrets, files, queries, or network calls.

staying-on-task

Keep an AI agent anchored to the actual goal through long or messy work. Use at the start of any multi-step task, and whenever work begins to drift, balloon, or stall.

technical-writing

Write documentation, READMEs, and guides that respect the reader's time and answer their actual question. Use when drafting or editing any technical document.

Testing & QA Listed

testing-strategy

Decide what to test, at which level, and what to skip, so tests catch real regressions without freezing the design. Use when writing tests or planning coverage for a change.