codex-skills

Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Codex's capabilities with specialized knowledge, workflows, or tool integrations.

Use when asked to update, refresh, synchronize, converge, or forward-port a maintained downstream fork against its upstream repository, including recurring upstream snapshot integrations and guarded fork cutovers. Do not use for an ordinary feature-branch merge, a one-off cherry-pick, or discussion of an upstream API that does not change the fork's upstream baseline.

Use JetBrains IDE inspections through the local inspection plugin; trigger for code changes, readiness checks, PR/push validation, IDE warnings, inspection triage, worktree-safe inspection routing, or when code quality should be driven toward zero actionable IDE findings.

Use for Launchplane-managed product/runtime state, secrets, config, deployments, rollout direction, product ownership boundaries, merge-train flow, and audited operator mutations. Use with github-plan when Launchplane work needs to stay aligned with a durable plan, issue graph, blockers, or rollout sequence. If authority is unknown or discovering private infrastructure access, use docs-lookup first.

Comprehensive GitHub Expert persona for repository execution and hygiene: PRs, branches, Actions, reviews, merge/deploy state, issue comments, and safe cleanup. For durable planning, roadmaps, blockers, Projects, or workstream graphs, use github-plan.

Use for Google Search Console, Bing Webmaster Tools, IndexNow, PageSpeed Insights, Lighthouse, Core Web Vitals, sitemap/indexing checks, SEO performance reports, and shared search tooling setup across sites.

Use when the user explicitly asks about local LLMs, LM Studio, local model inventory, local model chat, local model benchmarking, model role curation, or configuring private/local model endpoints. Provides public-safe mechanics and model index guidance for locally hosted or trusted-network OpenAI-compatible models without deciding when other domain skills should use a local model.

Babysit a GitHub pull request by continuously polling review comments, CI checks/workflow runs, and mergeability state until the PR is merged/closed or user help is required. Diagnose failures, retry likely flaky failures up to 3 times, auto-fix/push branch-related issues when appropriate, and keep watching open PRs so fresh review feedback is surfaced promptly. Use when the user asks to monitor a PR, watch CI, handle review comments, keep an eye on failures/feedback, or when PR diagnosis, update/rebase/rerun work, safe-to-exit checks, or merge confirmation turns into ongoing CI/review/merge follow-through.

Produce read-only GitHub work rollups across configurable repositories, owners, subjects, labels, and time windows. Use when the user asks what is active, blocked, waiting, recently completed, needs attention, or changed recently across GitHub work, including daily reports, activity summaries, standup briefs, or configurable work digests.

Use for infrastructure operations across private docs, local automation, hosts, ingress, network, storage, media, and managed service APIs. Trigger for read-only inventory, health checks, guarded pilot writes, rollback/snapshot planning, operator helper routing, and production-impacting infra changes after docs/access paths are known.

Resolve named humans, collaborators, users, reviewers, assignees, managers, clients, contacts, GitHub handles, nicknames, aliases, or likely misspellings into private local identity and contact context when identity may affect communication, routing, memory cleanup, rollout friction, GitHub planning, reviews, summaries, or follow-up. Use the optional global people index under Code home plus repo-local `.local/people.yaml` overlays when available, and continue normally when no local people context is configured.

Use only when the user explicitly asks to audit rollout/session files, runout files, session traces, or agent workflow friction. Never use implicitly or for ordinary debugging.

Use when the user asks for a plan, what's next / what is next in a plan or workstream, how work fits the plan, plan direction/alignment, durable work tracking, roadmap, workstream planning, GitHub issue-backed planning, issue graphs, parent issues, sub-issues, blockers, milestones, Projects, or replacing local plans with GitHub issues. Think in chat first, then keep long-running work aligned over time by updating Current Status, blockers, relationships, and issue graph state as reality changes.

Use when the user asks how to build with OpenAI products or APIs and needs up-to-date official documentation with citations, help choosing the latest model for a use case, or model upgrade and prompt-upgrade guidance; supersedes docs-lookup for OpenAI-specific questions; prioritize OpenAI docs MCP tools, use bundled references only as helper context, and restrict any fallback browsing to official OpenAI domains.

Use when the user asks whether a change, branch, PR, or workstream is ready to review, merge, ship, pause, or hand off, or asks to run gates, validate changes, check CI/PR readiness, inspect IDE warnings, verify UI, or identify blockers. Orchestrates local, GitHub, inspection, and browser evidence into a concise readiness report.

Use when the user asks to wrap up, clean up, close out, pause, park, hand off, determine what remains before stopping, preserve plan direction for the next session, update or remove stale plans/handoffs, reconcile issue graph state, remove transient artifacts, or asks whether they can exit. Coordinates GitHub plan cleanup, safe git/worktree hygiene, artifact cleanup, and final state summaries. Safe-to-exit and closeout final answers must include a Love Gate section with explicit `Love:` and `Do not love:` entries before the safe-to-exit verdict.

Allows you to view the user's screen as well as several hours of history. Use when the user makes a reference to their recent work, for which it'd be helpful to see the screen. Use this skill only when screen context is the best way to resolve ambiguity in a user request. Do not use it for ordinary repo, GitHub, filesystem, or memory-context questions that can be answered from those sources directly. You must also use this skill if the user asks about any question regarding Chronicle or asks what you can see from the screen.

Use a real browser to open pages, click, type, scroll, inspect visible UI state, and capture screenshots when evidence is useful. Use when a task depends on interacting with a webpage instead of guessing from code or HTML alone.

Use only when the user explicitly asks to audit, clean, prune, archive, reset, or distill Codex memories into skills, repo docs/issues, or local config. Never use implicitly or for ordinary repo work.

Use when the answer depends on external docs or environment-specific operational context rather than local repo code alone; includes discovering source-of-truth docs and access paths for private operations such as DNS or Cloudflare records, but not performing infrastructure actions or mutations.

Use only when the user explicitly requests security work such as a security review, audit, threat model, secure-by-default guidance, auth/authorization review, secrets check, tenant isolation review, webhook safety review, supply-chain/release risk review, or asks whether code is safe from a security perspective. Do not trigger for ordinary code review, debugging, readiness checks, or non-security implementation work.

Create and scaffold plugin directories for Codex with a required `.codex-plugin/plugin.json`, optional plugin folders/files, and baseline placeholders you can edit before publishing or testing. Use when Codex needs to create a new local plugin, add optional plugin structure, or generate or update repo-root `.agents/plugins/marketplace.json` entries for plugin ordering and availability metadata.

Use when the user wants UI/UX design collaboration, Claude Design, Codex or Every Code design tools, first/second design passes, mockups, visual direction, critique, or an outside collaborator to draft or review UI before implementation. Use github-plan issues as the durable design record.

Legacy local plan files only. Use only when explicitly requested; use github-plan for GitHub-backed planning.

Use for Python repo tasks involving setup, commands, scripts, tests, dependencies, lockfiles, packaging, builds, releases, PyPI/TestPyPI, or environment management. Steer toward uv and repo-defined entrypoints instead of system Python, pip, or ad hoc virtualenv commands.