Codex CLI Skills: Create and Reuse a Working Procedure

Codex CLI skills are named, reusable procedures that Codex CLI can run on demand. Instead of explaining a multi-step workflow each time—"run tests, check for type errors, then summarize what failed"—you write that procedure once as a skill and invoke it by name in future sessions. Tools like fenbs store the approved procedures and the lessons learned behind them, so they travel across projects and can be shared with teammates' AI apps.

Skills become most useful once a procedure has been tested enough to trust. The creation step is quick; the value comes from the verification work that turns a first draft into a procedure you can rely on.

What a skill looks like

A Codex CLI skill has three parts: a name, a short description and the procedure steps. The name is what you use to invoke it. The description helps Codex CLI—and you—identify the right skill when several are available. The steps are what Codex CLI executes.

A minimal example for a pre-commit check procedure:

Skill: pre-commit-check
Description: Run tests and type checks before a commit and summarize failures.
Steps:
1. Run the project's test suite.
2. Run the type checker.
3. If both pass, confirm ready to commit.
4. If either fails, list the failures by file and line. Do not proceed to the commit.

Keep steps specific enough that Codex CLI cannot misread them. "Check the tests" is too vague—it does not say which test command to run. "Run pnpm test in the project root" is not. See Codex CLI commands for the commands available in each context.

How skill discovery works

Codex CLI finds skills from a designated file or directory in the project. When you list available skills, Codex CLI reads their names and descriptions and presents them. The description is what it uses to match a skill to a request if you do not invoke it by exact name.

Write descriptions that are specific enough to be unambiguous. "Code check" could match many skills. "Pre-commit test and type check" points to exactly one. A good description prevents Codex CLI from invoking the wrong skill when you make a loose request.

Testing a skill before you rely on it

Run the skill on a project where you know the expected outcome. A pre-commit check skill should fail when there are failing tests—verify that it does, and check that it fails for the right reason rather than silently skipping steps.

Test the failure path as well as the success path. Introduce a deliberate type error and run the skill. It should report the error clearly. If it claims success when there are failures, the step that runs the type checker is either wrong or being ignored.

After the skill passes both tests, mark it as verified and record what you tested. That note becomes the basis for a lesson—if the skill breaks later, you have a record of what the working version did. For the best-practice context around Codex CLI workflow, see Codex CLI best practices.

When to update or retire a skill

A skill needs updating when the procedure it describes no longer matches what the project needs—usually because a command changed, a dependency was replaced, or a new failure mode appeared. The signal is a skill that claims success but produces a result you would not have accepted if you had done the step manually. Catch this in testing before it reaches a real task.

Retire a skill when the procedure it describes is no longer useful: the feature it tested was removed, the workflow changed entirely, or a better skill covers the same ground. A skill list cluttered with outdated procedures produces wrong invocations when Codex CLI tries to match a request to the nearest description. Remove or rename obsolete skills clearly.

Making skills portable across projects

A skill written for one project usually has project-specific commands: the test runner, the type checker, the file paths. To reuse the skill on a different project, separate the procedure logic from the project-specific values. The steps stay the same; only the commands and paths change between projects.

One approach: write the skill steps in terms of variables, then set the variables in a project-level config. The skill reads TEST_COMMAND and TYPE_CHECK_COMMAND from the environment; each project sets them differently. The procedure stays the same; the commands adapt.

For working with Codex CLI on Windows or in non-standard setups, see Codex CLI on Windows. For using Codex CLI as a subagent that invokes skills as part of a larger workflow, see Codex subagents.

How to do this with fenbs

1. Create a free account and add a project for the codebase where you are using Codex CLI.
2. Paste each verified skill procedure into fenbs Skills and prompts. Name it the same way you invoke it in Codex CLI.
3. After testing a skill, record the verification result—what you tested, what passed, what failed—as a Lesson learned linked to the project.
4. When a skill needs updating (a command changes, a new failure mode appears), update the procedure in fenbs and note why it changed in the Decisions and rules.
5. Connect Codex CLI to fenbs from Integrations. At the start of each session, ask it to read the project context and list available skills from fenbs.