agent-skills

Use when designing or changing REST, gRPC, GraphQL, webhook, event, DTO, SDK, OpenAPI, protobuf, or public interface contracts. Focus on compatibility, validation, error semantics, pagination, versioning, and generated artifacts.

Use when designing or changing backend APIs, services, repositories, workers, jobs, external clients, auth flows, configs, or service boundaries. Focus on contracts, ownership, data access, reliability, tests, and operations.

Use when designing or changing database schemas, migrations, indexes, ORM models, query patterns, transactions, consistency, data retention, partitioning, backfills, or storage choices for backend or ML systems.

Use when implementing or reviewing deep learning training, fine-tuning, evaluation, inference, GPU performance, batching, quantization, checkpointing, distributed training, model packaging, or deployment behavior.

Use when work involves retries, idempotency, queues, events, workflows, consistency, timeouts, cancellation, circuit breakers, backpressure, rate limits, duplicate delivery, partial failure, or cross-service reliability.

Use when designing, reviewing, or changing machine learning systems, recommendation/ranking/search models, prediction services, feature pipelines, training pipelines, model serving, evaluation, monitoring, drift handling, or ML rollout strategy.

Use when designing or reviewing ML/data pipelines, feature pipelines, data validation, schema drift, train/serve skew, labels, backfills, lineage, monitoring, model registry flows, or data-quality incidents.

Use when investigating bugs, production issues, flaky tests, regressions, logs, metrics, traces, dashboards, alerts, runbooks, or when adding instrumentation to make backend, performance, or ML behavior diagnosable.

Use when investigating or improving latency, throughput, CPU, memory, database queries, N+1 issues, caching, pagination, batching, concurrency, cold starts, benchmark regressions, or model inference speed. Requires measurement-first optimization.

Use for language-agnostic clean code, safe refactoring, simplification, renaming, extraction, reducing duplication, reducing complexity, improving readability, or cleaning code while preserving behavior. Do not use for feature changes unless requested.

Use for defensive security and privacy review of backend, API, data, ML, logging, secrets, auth/authz, tenant isolation, input validation, dependency, and deployment changes. Focus on finding and fixing risks, not offensive exploitation.

Use for system design, architecture proposals, ADRs, service decomposition, scale planning, storage/queue/cache choices, reliability trade-offs, rollout plans, and design reviews. Do not use for small local code edits.

Use when planning, adding, reviewing, or selecting tests for backend, clean-code refactors, API contracts, database changes, distributed systems, performance-sensitive paths, data pipelines, ML models, or deep-learning training/inference.

Use when Codex needs to create, validate, propose, or perform git commits; stage files; split changes; write Conventional Commit messages; prepare commit/PR summaries; or decide commit type and scope. Covers staging hygiene, commit boundaries, message format, and final reporting.

Use when Codex needs to document a software feature, API, service behavior, architecture decision, user workflow, release note, migration guide, or troubleshooting guide from source evidence, and when asked to draft, update, or publish technical documentation to Confluence. Applies to repo-grounded feature docs, developer docs, internal runbooks, and stakeholder-facing technical summaries.

Use when working in Go services to make idiomatic scoped code changes, preserve API/worker contracts, manage generated artifacts, and choose focused gofmt/go test/build/proto/swagger validation.

Use when working in Python services to make scoped code changes, clean imports/formatting, review FastAPI/Pydantic/SQLAlchemy/worker/client boundaries, preserve API contracts, and choose focused uv/pytest validation.

Use when Codex is asked to design or review architecture, choose or apply design patterns, assess module/service boundaries, plan refactors, inspect coupling, evaluate ownership, or make changes that may cross domain, application, infrastructure, API, worker, database, external-client, or deployment boundaries. Covers pragmatic pattern selection, boundary checks, and over-engineering safeguards.

Review code changes before merge or handoff. Use when the user asks to review a PR, branch, commit, diff, working tree, agent-written code, human-written code, bug fix, refactor, or implementation for correctness, regression risk, architecture fit, maintainability, security, reliability, performance, UX/API contracts, and test coverage.