A practical set of Codex skills for working on real software projects.
Codex is already good at writing code. The harder part is helping it understand a large repository, choose the right approach, keep parallel changes from colliding, and know when the result is actually ready to ship.
This repository gives Codex repeatable ways to handle those jobs. It includes 13 skills for repository analysis, debugging, migrations, design, web and mobile development, documentation, testing, releases, and multi-agent work.
You can install only the skill you need. They also work together when a task grows into something larger.
| What are you trying to do? | Start here |
|---|---|
| Understand an unfamiliar repository or see what a change might affect | repository-intelligence |
| Split known work between agents without overlapping edits | multi-agent-work-coordinator |
| Send well-defined tasks to specialized reader and writer agents | delegate-with-mission-cards |
| Upgrade a framework, dependency, database schema, API, or runtime | codebase-evolution-controller |
| Track down a bug when the cause is still unclear | debugging-investigator |
| Decide what needs testing or whether a change is ready to release | verification-and-release |
| Update guides, API docs, examples, configuration, and runbooks after a change | documentation-synchronizer |
| Work out how a product should look, feel, and behave | product-design-director |
| Turn a screenshot or visual reference into a responsive interface | screenshot-to-interface |
| Build or improve a production web application | production-web-builder |
| Choose between Flutter, Expo/React Native, native, or another mobile approach | mobile-architecture-director |
| Build an app after Flutter has already been chosen | flutter-production-builder |
| Build an app after Expo or React Native has already been chosen | expo-react-native-builder |
You do not need to run a whole chain for every task. Use the smallest skill that matches the decision in front of you.
This is the skill to use before changing a repository you do not fully understand. It maps applications, packages, dependencies, ownership clues, generated files, risky hotspots, and the likely reach of a proposed change. Its job is to explain the codebase with file-level evidence; it does not implement the change or assign work to agents.
This skill takes work that is already understood and turns it into a safe execution plan. It identifies dependencies, gives every writer a separate area of ownership, groups independent tasks into parallel waves, and defines the order in which results should be integrated. It coordinates work, but it does not choose custom models or replace the parent agent's final review.
This is the Mission Control skill. It decides which specialized reader or writer should receive each approved task, gives that agent a precise mission card, and requires evidence before accepting the result. It is useful when parallel work will genuinely save time; it deliberately stays out of small, tightly coupled, or poorly defined tasks.
Use this for changes that move a codebase from one known state to another: framework upgrades, dependency migrations, API versions, database schemas, runtimes, or serialization formats. It checks compatibility, plans temporary adapters or dual-running periods, defines rollout and rollback, and states when old paths can finally be removed. It is not a general feature builder or a bug investigator.
This skill handles failures whose cause is not yet known. It starts by reproducing or tightly bounding the problem, ranks possible explanations, adds only the instrumentation needed to test them, and traces the evidence until one cause remains. The result should include the smallest sensible fix and a regression test—not a speculative list of things to try.
This skill asks, “What do we need to prove before this ships?” It builds a test plan around the actual risks, checks whether CI and other evidence cover those risks, and gives a clear READY, CONDITIONAL, or BLOCKED decision. Builders still test their own features; this skill owns the final, integrated release judgment.
Use this after behavior, configuration, APIs, deployment steps, or user-facing interfaces change. It finds every affected documentation surface—guides, examples, generated references, migration notes, screenshots, runbooks, and changelogs—then keeps them consistent with the code. It does not invent product behavior that the implementation has not defined.
This skill works out what an experience should communicate and how it should feel before implementation begins. It turns product goals, user needs, existing brand material, and platform constraints into flows, hierarchy, states, typography, color roles, spacing, motion, responsive behavior, and accessibility direction. Use it for design decisions, not for literal screenshot copying or routine frontend coding.
This skill rebuilds an interface from screenshots or other visual references. It studies layout, spacing, typography, assets, component boundaries, and clues about responsive behavior, then guides implementation through repeated visual comparison. The goal is a maintainable and accessible interface that is faithful to the reference—not a brittle pile of hard-coded coordinates.
This is the main implementation skill for web applications. It works inside the project's existing stack and covers component boundaries, rendering, data loading, forms, mutations, authentication boundaries, responsive behavior, accessibility, performance, tests, observability, SEO, and a final browser pass. It does not begin by installing a fashionable package list; new dependencies must solve a real need in the repository.
Use this when the mobile technology has not been chosen yet. It compares Flutter, Expo/React Native, native development, Kotlin Multiplatform, web containers, and other realistic options against the product, team, offline, security, device, performance, accessibility, and release requirements. It records disqualifiers and recommends small proof projects when the answer cannot be trusted on paper alone.
This skill takes over once Flutter is already the chosen platform. It covers application structure, state, routing, networking, serialization, local data, offline behavior, platform integration, adaptive UI, accessibility, tests, performance, observability, signing, and release preparation. Package choices are made from the project's needs and existing conventions instead of being prescribed in advance.
This is the equivalent builder for Expo and React Native projects. It handles routing, development builds, native modules, state and server data, secure and offline storage, background work, animation, gestures, accessibility, device testing, performance, EAS Build, over-the-air update rules, and store release. It treats Expo Go as a useful playground, not as proof that a production binary is ready.
See everything available in the repository:
npx skills add https://github.com/cmdr-chara/codex-toolkit --listThen install the one you want:
npx skills add https://github.com/cmdr-chara/codex-toolkit --skill "repository-intelligence" -gReplace repository-intelligence with any name from the table above. Start a fresh Codex task after installing so Codex can load it.
You can ask normally, or name the skill directly:
Use $repository-intelligence to map this monorepo before we change authentication.
Use $mobile-architecture-director to help us choose between Flutter and Expo.
Use $production-web-builder to build this checkout flow and verify it in a browser.
Here is one possible path through the toolkit:
flowchart LR
RI["Understand the repository"] --> DECIDE{"What comes next?"}
DECIDE -->|"There is a bug"| DEBUG["Find the cause"]
DECIDE -->|"Something must be upgraded"| EVOLVE["Plan the migration"]
DECIDE -->|"The product needs direction"| DESIGN["Shape the experience"]
DECIDE -->|"The mobile stack is undecided"| MOBILE["Choose the platform"]
DESIGN --> WEB["Build for the web"]
DESIGN --> SHOT["Rebuild from a screenshot"]
MOBILE --> FLUTTER["Build with Flutter"]
MOBILE --> EXPO["Build with Expo / React Native"]
RI --> COORD["Split the work safely"]
COORD --> MC["Send missions to agents"]
DEBUG --> VERIFY["Test and release"]
EVOLVE --> VERIFY
WEB --> DOCS["Update the docs"]
SHOT --> DOCS
FLUTTER --> DOCS
EXPO --> DOCS
DOCS --> VERIFY
For example, a large modernization might start with repository-intelligence, move through codebase-evolution-controller, use multi-agent-work-coordinator to divide the work, and finish with verification-and-release.
A smaller bug fix may only need debugging-investigator and the relevant builder.
Mission Control is the optional multi-agent part of the toolkit. It adds six custom agents and the delegate-with-mission-cards skill.
Install it with:
npx --yes github:cmdr-chara/codex-toolkitOn Windows, you can also clone the repository and run:
.\scripts\install-mission-control.ps1The installer backs up conflicting Mission Control files under ~/.codex/backups before replacing them.
| Role | Model | Good fit for |
|---|---|---|
pathfinder-reader |
GPT-5.6 Luna | Quickly finding files, symbols, and narrow facts |
patcher-writer |
GPT-5.6 Luna | Small, isolated edits that are easy to verify |
investigator-reader |
GPT-5.6 Terra | Debugging, tracing behavior, reviews, and comparisons |
builder-writer |
GPT-5.6 Terra | Features, tests, fixes, documentation, and configuration |
sentinel-reader |
GPT-5.6 Sol | Security, privacy, migrations, and other high-risk analysis |
architect-writer |
GPT-5.6 Sol | Architecture changes and difficult, failure-sensitive work |
multi-agent-work-coordinator decides how the work should be divided. Mission Control chooses the right agent for each approved piece of work. This keeps planning and model selection separate.
These skills are more than short prompt templates. Depending on the job, a skill may include:
- clear examples of when it should and should not be used;
- a step-by-step working process;
- rules for preserving uncommitted work and avoiding risky changes;
- checklists for handoffs, failures, and stopping points;
- current web, Flutter, and Expo package research;
- small read-only scripts for inspecting a repository;
- tests for confusing cases where two skills might otherwise compete.
The package guidance is conditional. A skill should inspect the existing project before suggesting a new dependency, and it should prefer built-in tools when they are enough.
The repository includes two local checks. One checks the structure, links, metadata, research dates, licenses, and Python scripts. The other runs every helper against temporary sample projects and confirms that none of them changes the input files.
python scripts/validate_skill_pack.py . --as-of 2026-07-17
python scripts/run_smoke_tests.py . --as-of 2026-07-17After installing the skills, evaluations/post-install-routing-smoke.md provides a short live routing test. The full test notes are in evaluations/README.md.
agents/ The six optional Mission Control agents
docs/ Design notes, skill boundaries, and research sources
evaluations/ Routing cases and realistic workflow checks
scripts/ Installers, validators, and read-only test helpers
skills/ The 13 installable Codex skills
You can also browse the compact skill catalog in skills/llms.txt and see release history in CHANGELOG.md.
The web and mobile package research was last checked on 2026-07-17. Those references include review dates because frameworks and package recommendations change. Always compare them with the versions in the project you are working on.
product-design-director and screenshot-to-interface build on ideas from Leonxlnx's MIT-licensed Taste Skill project. THIRD_PARTY_NOTICES.md contains the original license, source mapping, and a summary of the changes made here.
MIT © 2026 cmdr-chara