Create Skill

Create Skill

This skill guides the creation of effective skills. Authoring guidance is split across the reference files below. Read the ones the current step needs rather than all of them.

Step 1: Understanding the Skill with Concrete Examples

Skip this step only when the skill's usage patterns are already clearly understood. It remains valuable even when working with an existing skill.

To create an effective skill, clearly understand concrete examples of how the skill will be used. This understanding can come from either direct user examples or generated examples that are validated with user feedback.

For example, when building an image-editor skill, relevant questions include:

• "What functionality should the image-editor skill support? Editing, rotating, anything else?"
• "Can you give some examples of how this skill would be used?"
• "I can imagine users asking for things like 'Remove the red-eye from this image' or 'Rotate this image'. Are there other ways you imagine this skill being used?"
• "What would a user say that should trigger this skill?"

To avoid overwhelming users, avoid asking too many questions in a single message. Start with the most important questions and follow up as needed for better effectiveness.

Conclude this step when there is a clear sense of the functionality the skill should support.

Step 2: Planning the Reusable Skill Contents

To turn concrete examples into an effective skill, analyze each example by:

1. Considering how to execute on the example from scratch
2. Identifying what scripts, references, and assets would be helpful when executing these workflows repeatedly

Example: When building a pdf-editor skill to handle queries like "Help me rotate this PDF," the analysis shows:

1. Rotating a PDF requires re-writing the same code each time
2. A scripts/rotate_pdf.py script would be helpful to store in the skill

Example: When designing a frontend-webapp-builder skill for queries like "Build me a todo app" or "Build me a dashboard to track my steps," the analysis shows:

1. Writing a frontend webapp requires the same boilerplate HTML/React each time
2. An assets/hello-world/ template containing the boilerplate HTML/React project files would be helpful to store in the skill

Example: When building a big-query skill to handle queries like "How many users have logged in today?" the analysis shows:

1. Querying BigQuery requires re-discovering the table schemas and relationships each time
2. A references/schema.md file documenting the table schemas would be helpful to store in the skill

To establish the skill's contents, analyze each concrete example to create a list of the reusable resources to include: scripts, references, and assets.

When creating a new skill, establish with that list in hand whether the skill earns its existence. The contents fail that test when they compensate for a problem fixable at its source, when they serve a one-time job rather than a recurring one, or when the instruction files the harness already loads cover them. Where any of those holds, state which one and name the alternative — the upstream fix, a runbook, or a doc pointer — then use request_user_input to let the user choose between that alternative and building the skill anyway, and continue from their answer; when that gate cannot reach the user, build the skill and record the concern in the report. When updating an existing skill, apply the test to the change in hand and record any doubt about the whole skill's reason to exist beside the finished edit.

Step 3: Initializing the Skill

Skip this step if the skill being developed already exists and iteration is needed. In this case, continue to the next step.

When creating a new skill from scratch, create the skill directory with:

• A SKILL.md file with proper YAML frontmatter (name and description) and TODO placeholders for the body
• Resource directories as needed: scripts/, references/, and/or assets/

After initialization, customize or remove the generated files as needed.

Step 4: Edit the Skill

When editing the (newly-generated or existing) skill, remember that the skill is being created for another Codex session to use. Focus on information that would be beneficial and non-obvious to Codex. Consider what procedural knowledge, domain-specific details, or reusable assets would help another Codex session execute these tasks more effectively.

To begin implementation, start with the reusable resources identified above: scripts/, references/, and assets/ files. Note that this step may require user input. For example, when implementing a brand-guidelines skill, the user may need to provide brand assets or templates to store in assets/, or documentation to store in references/.

Before writing SKILL.md, read references/principles.md, references/structure.md, and references/writing.md. These apply to every skill.

Then read the references matching what this skill does:

• Multi-step or looping workflow → references/workflows.md, plus references/tools.md when it gates on user input
• Depends on or fans out to other skills → references/composition.md, plus references/tools.md when it fans out
• Dispatches spawn_agent, request_user_input, or MCP calls → references/tools.md
• Bundles executable scripts → references/scripts.md
• Targets a specific harness primitive, or depends on an exact tool name, limit, or discovery path → references/harness.md

Read references/evaluation.md when validating the skill against real tasks or refining it from observed behavior.

Task Tracking

At the start of Step 5, track each remaining step with the Codex plan tool, restating any remaining steps of a parent workflow alongside them:

• "Review the skill" for Step 5
• "Run $evaluate-findings skill" for Step 6
• "Run $apply-findings skill" for Step 7
• "Verify" for Step 8

Step 5: Review the Skill

After writing all files, spawn a Codex sub-agent (inherited model defaults) to review the skill. The reviewer should read references/skill-reviewer.md for review guidelines, read all skill files, and produce a review report following the format in the guidelines. Its prompt must direct it to treat the shared working tree and its git index as read-only and to review by reading and reasoning; fixes happen in Step 7. HEAD stays where it is: read other refs with git show <ref>:<path> rather than git checkout or git switch.

• For new skills, frame the review as open-ended: propose improvements, convention checks, writing quality.
• For modified skills (simplification, restructuring, bug fix), frame the review as regression-focused: check whether the change broke anything. Tell the reviewer not to propose new features.
• For same-session iteration (re-reviewing a skill after applying findings from a previous review in the same session), treat as modified: the review is checking whether the fixes broke anything.
• For batch changes (multiple skills created or modified in the same session), group the work by distinct change rather than by skill. Two skills received the same change when the edited text is identical; otherwise each is a distinct change. Launch one Codex sub-agent per distinct change, plus one sub-agent covering every site of a change applied identically across several skills. Give that sub-agent the full site list, and have it check each site in its own local context and flag any comparable location in the batch that should have received the change but did not. State the total count and which sites map to which sub-agent. Issue all spawn_agent calls in one batch, then collect their results with wait_agent. Do not issue one and await its result before issuing the rest. Each sub-agent inherits the parent model.

Step 6: Run $evaluate-findings Skill

Run the $evaluate-findings skill on the review findings.

Step 7: Run $apply-findings Skill

Run the $apply-findings skill on the evaluated findings.

Step 8: Verify

When the skill bundles executable code, run the project's test suite and report the result: state pass or fail with the failing output, rather than closing the workflow on an assumption that the suite still passes. When the skill bundles none, or the project has no suite to run, say so.

Then call update_plan to mark this step completed and continue with the next step of the active workflow.