CodexAI Skills

Use for DESIGN.md visual identity contracts; author, scaffold, lint, diff, and export design contracts with the upstream spec and CLI.

Use for role-scoped FE/BE/DevOps/Admin/QA project docs under .codex/project-docs to preserve micro-context across long projects.

Use for complex coding requests that need a structured implementation plan with dependencies, checkpoints, and verification criteria.

Use when the task involves reading, creating, or editing `.docx` documents, especially when formatting or layout fidelity matters; prefer `python-docx` plus the bundled `scripts/render_docx.py` for visual checks.

Use at the start of a Codex task to inspect repo readiness, project profile, monorepo shape, role docs, spec status, knowledge index, and recommend the next workflow.

Use for flows, IA, cognitive load, empty/error/loading states, content ranges, and responsive accessibility before visual decoration.

Use for UI, frontend, styling, landing page, or component work; applies grammar (surface mode, change mode, composition, motion) instead of mandatory palettes.

Use when committing or pushing completed work; automates gate-aware conventional commits with optional signing and CI/CD checks.

Use when implementation needs isolation from the current workspace; creates git worktrees with safe directory selection and baseline verification.

Use when asking project status, next priority, sprint health, blockers, deadlines, risk register, or daily brief generation.

Use when a project has 50+ files, missing context, or explicit $codex-genome request; generates multi-layer project context to reduce hallucination.

Use for project memory, decisions, handoffs, genome, knowledge index, changelog, and patterns that must persist across sessions.

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work — guides completion of development work by presenting structured options for merge, PR, or cleanup

Use for documents, reports, memos, guides, academic papers, or formal text that needs clear structure, reliable tone, formatting, and diagrams.

Use when work needs deeper thinking, less generic output, repo evidence, tradeoffs, monitoring signals, or stronger quality discipline.

Use when work needs Scrum roles, ceremonies, backlog refinement, sprint planning, story delivery, release readiness, or role handoffs.

Use when code changes may require documentation updates; maps git diff to candidate docs without auto-editing documentation.

Use for frontend, backend, mobile, debugging, security, or specialized engineering work that needs focused domain references and strict boundaries.

Use for vague new or redesign UI prompts; decode the brief, pick visual authority, and produce three distinct directions before implementation.

Use when an approved plan has independent tasks ready for delegated execution with fresh subagents and two-stage review.

Use after intent is known to route build, fix, review, debug, docs, or Scrum requests into ordered workflow steps with exit criteria.

Use as the top-priority baseline for Codex request classification, coding quality, dependency awareness, and completion checks.

Use for security review, audit, hardening, compliance, DevSecOps, network, infrastructure, or application security with focused references.

Use after UI implementation to run mechanical source checks and independent rendered review with bounded inspect/fix loops.

Use for bugs, test failures, broken behavior, or unexpected results; enforces 4-phase root-cause debugging before fixes.

Use before completion, PR, deploy, handoff, or when verifying code changes. Runs advisory or blocking checks and reports evidence.

Use when work is ambiguous or has multiple viable paths; compares options, assumptions, evidence, tradeoffs, and the best next action.

Use before build, fix, debug, review, or docs implementation; converts prompts into structured intent JSON with goal, constraints, and routing.

Use for prototype, MVP, fullstack feature, from-scratch feature, or multi-domain work that needs a SPEC.md before planning or implementation. Do not use for tiny one-file edits.

Use before feature, bugfix, or refactor implementation when behavior can be tested; enforces Red-Green-Refactor discipline.

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs — requires running verification commands and confirming output before making any success claims; evidence before assertions always