codex-howto

Build or modify backend APIs, services, jobs, persistence, and integrations while preserving contracts, authorization, data integrity, and failure behavior. Use for server-side features, database changes, background processing, backend defects, and service refactors; do not use for frontend-only or infrastructure-only work.

Build or modify frontend interfaces using repository-native components while preserving accessibility, responsive behavior, state handling, and visual verification. Use for UI features, design implementation, forms, client-side defects, and frontend refactors; do not use for backend-only or infrastructure-only work.

Drive an authorized repository change through a verified local loop: baseline, reproduce, implement, test, review, and report evidence. Use for end-to-end features or fixes that should continue autonomously until observable acceptance criteria pass; do not use for explanation-only, review-only, or production operations.

Maintain a review-first Markdown knowledge base for Codex practices with source provenance, engineering capture, citation-aware queries, explicit archive and promotion, and deterministic linting. Use when asked to capture a durable engineering lesson, ingest Codex research, query or archive what the repository knows, check wiki health, reconcile conflicting guidance, or promote verified knowledge.

Plan and implement infrastructure, CI/CD, container, deployment, observability, and operational configuration changes with least privilege, staged validation, and rollback awareness. Use for pipelines, infrastructure as code, Kubernetes, containers, release automation, monitoring, and production-readiness work; do not use to perform destructive production actions without explicit authorization.

Coordinate complex engineering work across bounded subagents while protecting the main context, preventing edit conflicts, and measuring whether delegation was worthwhile. Use when the user asks to delegate, parallelize, orchestrate, use subagents, fan out a review, or handle a large task with independent workstreams; do not use for small, tightly coupled, or inherently sequential tasks.

Review code changes for correctness defects, regressions, security risks, data-integrity problems, concurrency hazards, and missing meaningful tests. Use for pull requests, branches, commits, patches, or working-tree reviews; do not use for implementation unless the user separately requests fixes.

Review application and infrastructure changes for exploitable security risks by tracing assets, trust boundaries, attacker-controlled input, authorization, sensitive data, and dangerous sinks. Use for security reviews, threat-focused PR reviews, authentication or authorization changes, input handling, secrets, dependencies, and infrastructure permissions; do not use to exploit live systems or modify code unless separately requested.

Design, implement, and evaluate risk-based software tests across unit, integration, contract, end-to-end, and regression layers. Use when adding tests, reproducing bugs, improving coverage, diagnosing flaky tests, or defining a test strategy; do not use to change production behavior unless the user also requests implementation.