pimenov/codex-first-skills-pack

Designs stable API, interface, schema, event, CLI, module, and service contracts before implementation so callers, consumers, and future agents can depend on them safely. Use when creating or changing public/internal APIs, SDK surfaces, webhooks, GraphQL/REST/RPC routes, database or message contracts, module boundaries, config formats, CLI commands, or any interface where compatibility, versioning, errors, auth, observability, or Hyrum's Law matters.

Reviews code changes across correctness, tests, readability, architecture, security, and performance before they are merged, shipped, or called done. Use when the user asks for a code review, when reviewing a PR/diff/commit/agent-produced code, after implementation or bugfix before final confidence, when deciding whether a change is ready, or when large/unclear changes need findings with severity and verification gaps.

Curates focused project and session context before answering, planning, editing, debugging, reviewing, deploying, or handing off work. Use when starting or resuming work in a repo/workspace, switching tasks, output quality degrades, the codebase is unfamiliar or large, source-of-truth is unclear, docs/code/runtime may conflict, or Codex needs a bounded context pack before taking action.

Guides systematic root-cause debugging and recovery instead of guessing fixes. Use when tests fail, builds break, commands error, logs or consoles show errors, runtime behavior differs from expectation, a bug is reported, a prior fix did not work, CI/deploy/smoke checks fail, or something worked before and stopped working. Also use when Codex encounters an unexpected tool, package, API, network, infrastructure, or vendor error during a task.

Plans safe deprecation, migration, sunset, replacement, and removal of old systems, APIs, features, schemas, flags, cron jobs, integrations, configs, libraries, UI flows, and operational processes. Use when retiring legacy code, replacing an implementation, removing a public/internal interface, migrating consumers, consolidating duplicate systems, deciding maintain-vs-sunset, writing deprecation notices, proving zero usage before deletion, or when Hyrum's Law, compatibility, rollback, data safety, production risk, or consumer communication matters.

Runs an adversarial review gate for non-trivial or high-stakes decisions before they stand. Use when Codex is about to claim something is safe, correct, reversible, production-ready, scalable, idempotent, secure, or compliant; when work touches production, auth, permissions, secrets, billing, public APIs, migrations, irreversible cleanup, customer data, external agent CLIs, or unfamiliar code with meaningful blast radius; or when a confident answer would be cheaper to challenge now than to debug later.

Breaks large or multi-file implementation work into small verified slices that keep the project working after each step. Use when building a feature, bugfix, refactor, migration, integration, UI flow, or operational change that could become a large diff; when more than one file/module is touched; when scope is fuzzy; when review or rollback would be hard; when Codex is tempted to code for a long time before testing; or when the user asks to work in small verified steps, slices, маленькими проверяемыми шагами, по шагам с проверкой, or после каждого шага проверяй.

Turns ambiguous, large, multi-step, or handoff-prone work into sequenced tasks with outcomes, dependencies, stop-lines, acceptance criteria, and the right durable layer. Use when planning a feature, bugfix campaign, refactor, migration, deploy prep, client/internal work packet, Linear issue set, or when the user asks to break down, plan, scope, make tasks, prepare execution, or decide the next safe steps before implementation.

Grounds framework, library, SDK, API, CLI, and cloud-service implementation decisions in current official sources before code or recommendations. Use when building, debugging, reviewing, or explaining version-sensitive technical work; when the user asks for latest/current/correct/documented behavior, актуальные docs, current docs, official docs, or как сейчас правильно; when a dependency, SDK, product API, config format, cloud provider, or platform feature may have changed; or when Codex would otherwise rely on memory for framework-specific code. Use alongside domain skills such as Cloudflare, Netlify, OpenAI, Supabase, React, or Next.js when the domain answer depends on current docs.

Defines the implementation contract before planning or coding so work is built against explicit goals, users, scope, non-goals, assumptions, acceptance criteria, and verification. Use when creating or changing a feature, product workflow, API, integration, migration, user-facing behavior, cross-team handoff, or any task where Codex could implement the wrong thing correctly; when the user asks for a spec, requirements, PRD, contract, acceptance criteria, or "what exactly are we building".

Drives behavior changes through tests or explicit focused checks before implementation. Use when implementing new logic, fixing a bug, changing behavior, adding edge-case handling, modifying validation, refactoring behavior-sensitive code, or after debugging identifies a root cause that needs a regression guard. Also use when Codex is about to say a bug is fixed or behavior works but no proof exists yet.