OpenAI Skills: Repeatable Procedures in Codex, ChatGPT and the API

When a team does the same kind of work again and again, it can capture the steps in a Skill: a package of instructions plus, where useful, reference material, templates and scripts. But having a Skill does not mean that every product will find it, invoke it, be able to carry out the action it describes, or confirm the result.

This unit covers the documented behaviour of Skills in OpenAI products as of 26 September 2026. The general model of a Skill, how its trigger works and the risks of third-party packages are explained in Claude Skills; standing repository rules and the difference between an instruction and a permission are covered in AGENTS.md. Here we focus on how OpenAI's surfaces differ from one another and on the ways a Skill can be attached through the API.

Five layers that are easy to confuse

When people talk about agents, they easily blur together the model, the product, the surface, the runtime and the Skill itself. These five layers are connected, but each answers a different question.

The model processes context and produces either an answer or a request to call a tool. The product is Codex, ChatGPT or another service that gives people a particular workflow. The surface is the interface a person actually works in: Codex in a terminal, the Codex extension for a development environment, or ChatGPT on the web, for example. The runtime (execution environment) connects the model to files, a command shell, tools, limits and access rules. Finally, the Skill is a description of a repeatable workflow that the model can apply inside such a runtime.

An application programming interface (API) gives an application a way to call a service through a defined contract. The OpenAI API and its software development kit (SDK) are not the same thing as a local Codex session running in a terminal: the developer supplies files, tools and settings separately. The instructions in a Skill do not automatically carry a file system, tools, authentication or permissions from one environment into another.

Nor does a Skill replace the other moving parts of development:

Mechanism	The question it answers	Its limit
AGENTS.md	Which standing rules apply to work in this repository?	It is not a procedure meant to be loaded only for one narrow type of task.
The prompt for the current task	What needs doing right now?	It describes one specific job, not a process that repeats across many jobs.
Skill	How should a repeatable workflow be carried out, and under what conditions?	It does not create file access or access to external systems that is missing.
Tool or integration (connector)	Which action or request can the runtime technically perform?	Having a tool does not decide when it is appropriate or how to check the result.
Subagent	Which part of the work can be handed to a separate agent?	It is a way of organising execution, not an instruction format or a source of permissions.

For example, a Skill might say: first read the requirement in Jira, then compare it with the code, then prepare a pull request (PR). For that to work, the runtime has to actually provide Jira read access, access to the code and a way to create a PR. If the connector is not there, the Skill cannot conjure it up.

One name, several working surfaces

OpenAI's current documentation calls the shared format Agent Skills and describes its use in Codex, ChatGPT and the API. It separately lists the surfaces where standalone Skills and plugins are available. That list reflects what the documentation said on the date it was checked; it is not a promise of identical availability on every plan, in every workspace or in every client. Organisation policy and the settings of a particular product can also affect access.

Surface or delivery channel	How the Skill reaches it	How it can be selected	Where the work happens
Codex CLI (command-line interface) and IDE (integrated development environment) extension	Usually a local Skill directory in the repository or another supported folder	Explicitly with <code>$name</code> or through the <code>/skills</code> menu; selection by description is also possible	In the Codex runtime, with whatever files, shell and tools are configured and allowed in that session
ChatGPT desktop app	Standalone Skills can be created and viewed in the desktop app; Skills inside plugins are also available in Chat and Work modes	Explicitly with <code>@</code>; implicit selection depends on the description and settings	Actions are performed by the capabilities available to that workspace. The Skill does not add a missing integration
ChatGPT on the web and on mobile	The documentation lists Skills packaged inside plugins	Through the plugin and its availability in the particular workspace	A Skill appearing in the catalogue does not mean every access it needs is present
Codex in the ChatGPT desktop app or the CLI through a plugin	Skills can be part of a plugin; standalone local Skills are available in the CLI and the IDE extension	Depends on the installed plugin and the Codex environment	The plugin distributes the procedure and, where needed, integration settings; the actual rights are decided by the runtime
Responses API with hosted shell (a managed command environment)	An uploaded Skill can be attached by ID and version, or a ZIP package can be passed when the container is created	Once mounted, the model may choose the Skill; naming it explicitly in the request makes the intent clearer but does not guarantee correct execution. API documentation	In the command environment OpenAI has set up and its container
Responses API with local shell (a local command environment)	The request contains a local name, description and path to the Skill directory; a <code>skill_reference</code> attachment is not supported in this mode	The model sees the metadata and can read the instructions at the given path. API documentation	In the local environment controlled by whoever sends the request
Agents API	The Skill directories must already exist inside the isolated execution environment (sandbox); the request registers their parent folders	The environment finds each SKILL.md and adds names and descriptions to the context; the model can read the Skill it selects. Agents API documentation	In a sandbox whose configuration is defined by the application
Plugin	A way of bundling Skills and optional integrations into a single package	Depends on the catalogue and the surface	The Skill describes the procedure; the integration provides operations and data. Permission to act comes from the product or the runtime

OpenAI describes a plugin as a way to distribute one or more Skills and, where needed, integration settings in a single package. The Model Context Protocol (MCP) can provide those integrations, but an MCP server by itself is not a working procedure. The documentation lists standalone Skills for the ChatGPT desktop app, Codex CLI and the IDE extension; Skills inside plugins are also available in ChatGPT on the web, desktop and mobile, and in Codex through the ChatGPT desktop app and the CLI. This is a list of documented surfaces, not a promise of equal availability on every plan and in every workspace. The details are in the guide to building Skills and the documentation on Skills in plugins.

A documented discovery path does not guarantee that every version of an app implements Skill discovery without bugs. In the open issue #40458, for instance, a user reported that Codex for Windows version 26.818.2441.0 did not show repository Skills from the documented folder, even though the reporter had checked the file format, the repository root and project trust. This is a report about one specific version and configuration, not proof that every Windows app has the same problem. The practical lesson: after installing a Skill, check that it really appears on the surface where the team will use it.

The table answers "where is this possible?", but it does not yet explain what actually enters the context and when files are executed. For that we need to look inside the package.

The Skill package and OpenAI metadata

A minimal Skill is a directory containing a <code>SKILL.md</code> file. The file starts with a metadata block, followed by ordinary Markdown text describing the procedure. The format requires two fields: <code>name</code> and <code>description</code>. The open Agent Skills specification adds rules: the name must be 1 to 64 characters of lowercase Latin letters, digits and hyphens; it must not start or end with a hyphen, must not contain consecutive hyphens, and must match the directory name. The description is limited to 1,024 characters and should say what the Skill does and when to use it. These are format rules, not a guarantee that every product behaves the same way Agent Skills Specification.

A small fictional example:

---
name: jira-pr-preflight
description: Prepare the implementation of a Jira issue and a draft PR. Use for issues that explicitly ask for implementation in the repository; do not use for explaining concepts, checking status without making changes, or preparing a release.
---

First read the Jira issue, its acceptance criteria and the repository rules.
If the Jira or GitHub tool is missing, say so and stop
before any action you cannot perform or verify.
After making changes, list the criteria you checked and the evidence.
Create a draft PR only when an authorised mechanism is available.
Do not merge the PR and do not publish a release.

The directory may also contain <code>references/</code> with material to read, <code>scripts/</code> with executable code, and <code>assets/</code> with templates or other files. These resources are not interchangeable:

• a link to a reference means it should be read under a specific condition;
• an instruction to run a script means executing code, with possible side effects;
• an asset may be a template or data, but on its own it is not a command;
• a file being present in the directory does not prove that the runtime found, read or executed it.

Before running a script you need to understand its path relative to the Skill root, its input and output files, the runtime version, external dependencies, network access and expected side effects. Reading <code>references/</code> can also be risky if untrusted instructions reach the context that way, but reading a file is not in itself running a shell command.

OpenAI also documents an optional <code>agents/openai.yaml</code> file. It uses YAML (a recursive acronym for "YAML Ain't Markup Language", a format for structured data) and can set a display name and short description for the interface, configure the implicit-invocation policy and declare dependencies on tools. For example, <code>allow_implicit_invocation: false</code> in the Codex policy turns off selection by description while keeping explicit invocation. This is an OpenAI adaptation file, not a replacement for <code>SKILL.md</code>. Declaring a tool dependency does not authorise the call either, and it does not install a connector on its own. These fields may change; their current descriptions are in the official documentation on building Skills.

Extra metadata should be useful to the host that will actually read it. Do not add a field just because some other platform understands it. The specification, for example, calls <code>allowed-tools</code> experimental and explicitly warns that support depends on the implementation. A single file may be syntactically acceptable to several products, but a field that controls Claude Code's behaviour does not thereby become a Codex rule.

From description to invocation

Codex reads the names and descriptions of Skills when looking for a candidate. The full text of <code>SKILL.md</code> is added once the Skill is selected; other reference files can be loaded only when the procedure points to them. This is progressive loading: first a lightweight index, then detailed instructions for the specific job.

The current Codex guide lists these local sources: repository folders named <code>.agents/skills</code> from the current working directory up to the repository root; the user folder <code>$HOME/.agents/skills</code>; the administrative folder <code>/etc/codex/skills</code>; and built-in system Skills. For a local folder in a nested directory, Codex can find the Skills of that directory and of its parents up to the repository root. The page also says that Codex supports symbolic links and does not merge Skills that share a name. That is the documented behaviour; the issue report about the Windows desktop app mentioned above shows why discovery should be checked on the actual surface and version. Source: the current OpenAI guide.

There is a practical resource limit here. According to the current Codex documentation, the initial list of Skills takes up to 2% of the model's context window, or 8,000 characters if the window size is unknown. Codex first shortens descriptions; if there are many Skills, some may be left out of the initial list and the system may show a warning. This limit applies to the metadata list, not to the full text of the selected Skill. So a very long description does not make the trigger more precise — it can crowd out other descriptions and blur the scope of the Skill itself.

Explicit invocation is useful when a person already knows which procedure they need. In ChatGPT that may mean selecting it with <code>@</code>; in Codex CLI or the IDE, choosing it from the <code>/skills</code> menu or referring to it as <code>$name</code>. Implicit invocation is convenient when the task naturally matches the description, but it remains the model's decision. For the Responses API, the documentation likewise says that the model may use a mounted Skill on its own, and that an explicit phrase such as "use Skill X" makes the request's intent clearer. None of these options proves that the procedure finished correctly.

The description should help tell apart intents that look alike. For each Skill it helps to define positive examples, where it really is needed, and negative examples that use similar words but describe different work. If two Skills have the same name, Codex does not merge them. They are not "two halves of one package": the user may see both, and automatic selection becomes less predictable. Separate their scopes or give them explicitly unique names.

When a wrong automatic choice could change an external system, narrowing the description may not be enough. In Codex, turn off implicit invocation through the supported metadata, keep the procedure available for explicit invocation, and control the action through runtime permissions. The description steers routing to an instruction; it does not control access to the "publish" button.

Attaching a Skill through the OpenAI API

In the API documentation's examples, how you supply a Skill depends on the type of shell environment.

For hosted shell, the Responses API documentation shows two ways: refer to an uploaded Skill by <code>skill_id</code> and, optionally, <code>version</code>; or pass the Skill's ZIP package as an inline Skill when the container is created. In the second case the request contains a name, a description and the ZIP content encoded in Base64, which lets you use a Skill without first creating a stored version of it. For local shell, the documentation instead shows <code>name</code>, <code>description</code> and a <code>path</code> to a directory the environment can reach, and it states plainly that a <code>skill_reference</code> attachment is not supported there. These are three documented ways of supplying the resources; do not carry one environment's format over to another OpenAI Skills API documentation.

In the Agents API, Skills are discovered through <code>environment.capability_directories</code>. The directories must be unique absolute paths inside an existing isolated environment (sandbox), must already exist, and must not contain <code>.</code> or <code>..</code> segments. A session can register up to 32 such directories. Once running, the environment looks for <code>SKILL.md</code> in them and adds the descriptions to the context, and the model can choose the relevant instructions. This shows once again that the API does not automatically use Codex's local discovery. The directory requirements and limits are described in the Agents API documentation.

An uploaded Skill can be versioned. The API documentation describes <code>default_version</code>, <code>latest_version</code> and an explicit version field in the reference. For a reproducible procedure it is better to pin a specific version than to rely on "the latest": after an update the behaviour may change even though the Skill's name stays the same. An uploaded ZIP package must contain exactly one <code>SKILL.md</code> file (the name is matched case-insensitively). As of the check date, the official documentation limits the ZIP to 50 megabytes, a version to 500 files and the unpacked content to 25 megabytes. These are product limits that may change; they are listed in the section on validating Skill packages.

Do not confuse the local environment of the current shell tool with the separate, legacy <code>local_shell</code> tool. The Skills API documentation shows Skills being passed to a local shell environment as <code>environment.type: "local"</code>, and the separate local shell guide recommends the shell tool for new integrations. For Responses API shell tools, the documentation specifies that Skill metadata and instructions are added to the user prompt, not the system prompt; this detail describes Responses API shell tools and does not automatically apply to the Agents API. These API-specific details and recommendations may change.

The API call itself can return text, a tool event or an artifact in the sandbox; it does not create a PR or a change in another service without a separate tool and code that passes the result on. An SDK makes it easier to build an API request, but it does not make a local process's file paths visible to a remote environment, and it does not remove the need to configure tools. Hosted shell, local shell and the Agents API each require different preparation of files and environment; the documentation does not present this as one universal way to call Skills OpenAI Skills API.

A Skill is not a permission

If a Skill says "read Jira" and the runtime has no Jira integration connected, the model can only explain that limitation. If it says "create a pull request" but there is no authorised way to write to GitHub, the sentence itself grants no such access. The outcome depends on the capabilities of the product and the runtime, the integration's credentials, organisation policies and the consequences of the action.

The same applies to scripts. A script in <code>scripts/</code> can read files, send network requests or change data — but only if the environment has given it those capabilities. Conversely, having network permission does not make every network call acceptable. OpenAI specifically warns that Skills in the Responses API can contain prompt injection: instructions that try to influence tool choice and exfiltrate data. The documentation requires treating a Skill as potentially untrusted instructions and code, especially when the network is connected to its work. So you check its origin, change history, code, dependencies, network destinations, access to secrets and sandbox — before giving the package a working environment. These recommendations are in the Risks and safety section of the API documentation.

Do not put a secret in the text of a Skill or in its examples. A reference file can describe where a secret parameter is expected without revealing its value; the tool should use a managed secret with properly restricted access. If an external action carries real-world risk — a merge, a payment, deleting customer data or a deployment, for example — the procedure must stop before it unless there is explicit permission and an external gate that checks that permission.

Maintenance and evaluation

A Skill changes along with the product, the repository and the connected tools. When reviewing an update, check not only the wording but also whether file paths, tool names, runtime versions, input formats, output evidence and stop conditions are still correct. If a link points to a GitHub example that may change, pin the commit; if the Skill is uploaded to the Responses API, pin a specific version. Do not confuse the version of a plugin with the version of each Skill inside it.

Testing should cover at least three independent outcomes:

1. Discovery: did the runtime find the Skill, and was it available in the session where it was needed?
2. Selection and execution: was it invoked on the intended requests, did it stay away from requests that belong elsewhere, and did the model carry out the required steps?
3. Result and permissions: does the output contain the required evidence, are gaps marked, and did every action stay within the permitted limits?

Compare direct and paraphrased positive requests, similar-looking negative requests, an edge case with incomplete data, and an attempt at an external action without the necessary permission. A false positive means the procedure started where it was not needed; a false negative means it did not start where it would have helped. Track both, not just the share of runs that completed successfully.

A real but not universal signal about the risk of having too many Skills came from Eric Provencher on the OpenAI engineering blog on 11 September 2026: long or contradictory descriptions can make selection harder, and progressive loading helps keep irrelevant instructions out of the context most of the time. The author describes observations from his own work with Codex and GPT-6 Astra (GPT stands for Generative Pre-trained Transformer). It is not a guarantee of how every model behaves. The current Codex documentation independently confirms the mechanism of shortening and omitting descriptions, but the selection of a particular Skill should be tested on the surface and model you actually use. Sets of positive, negative and edge-case requests are described in the unit on testing Claude Skills; detailed methods for evaluating agents are in agent evaluation.

Worked example: a Jira issue ends in a draft PR

Situation. A small team receives a Jira issue: "Add monthly invoice export". A developer often repeats the same opening sequence: read the acceptance criteria, find the relevant components, make the change, run the available checks, create a pull request and explain exactly what was verified. The goal is to reduce skipped steps without turning the Skill into an all-purpose release agent.

Solution. The hypothetical package from the earlier example has a narrow description: implementing a Jira issue in the repository, nothing else. Its instructions define the sources of truth: Jira for requirements, the repository rules for local conventions, the code files for current behaviour, and check results as evidence. The procedure reads the acceptance criteria, flags ambiguity before editing any code, limits the set of files it changes, implements the minimal change, runs only the checks that are available and relevant, and collects their actual results. It then creates a draft PR through an available, authorised means of writing to GitHub. Its response includes links to the Jira issue and the PR, the changed files, a "criterion → evidence" map, and what was not checked and why. The procedure does not merge the PR into the target branch, does not deploy the change to production, does not present missing continuous integration (CI) results as passing, and stops if the Jira or GitHub connector is absent.

Observable result in the simulated example. When the procedure actually runs, its report might show: the PR changes one service and adds an export test; formatting passed; the CI check was unavailable and remains unverified; the draft PR is open for review and no merge was performed. This is an example of the expected report, not a check performed while this unit was written. A reviewer can compare the claims with the files and the command output instead of relying on the phrase "all done".

Why it fits. The Skill holds the repeatable procedure and the expected format of evidence. The Jira connector, the command shell or the GitHub tool perform the individual operations. The user can hand over just this one Jira issue, and the procedure still limits its scope to one repository and stops before the merge.

When it does not fit. If the export touches accounting rules or personal data, or needs an irreversible migration, an ordinary implementation Skill may not have the necessary preconditions. That calls for a separate decision by the product owner, a review against data policies, and a specialist in the financial logic. If the environment only has read access to the repository, the Skill cannot create a PR; it can return a plan and evidence of exactly where it stopped.

Worked example: a broad trigger captures a general question

Situation. In a teaching scenario, a Skill for reviewing code changes has this description: "Helps with development, GitHub, code, releases and all questions about the project." A person asks: "Explain why you would squash several commits before merging." The model wrongly selects the PR review procedure, looks for changed files, finds none and asks for the repository. The Skill fired on a question about a concept, even though nobody asked for a review of specific changes.

Solution. The author shortens the description and names the actual work, its input and its limits:

description: Review a specific pull request against the criteria of its linked issue, comparing the description, the changes and the available CI evidence. Use when explicitly asked to review a PR; do not use for general Git explanations, writing code, writing a PR description or starting a release.

The author then tests paraphrases. "Review PR 184 against issue A1M-123" should be a positive example; "What does squashing commits mean?" a negative one; "Compare these changes with the previous version" an edge case. That last request may be asking for analysis of specific changes, but it is not necessarily a full review against criteria. If the Skill should only ever be invoked explicitly, the author also turns off implicit invocation in the supported Codex metadata and keeps <code>$pr-review</code> for manual use.

Expected test result. The general question about squashing commits should not select the Skill, and a request naming a specific PR should lead to a review against criteria and evidence. A question about the difference between branching workflows stays an edge case, so the author adds it to the test set and decides whether it belongs to this Skill, to another procedure, or to an ordinary answer. This is an expectation, not a measured result; it is tested on the target model and surface after the description changes.

Why it fits. A description is a routing signal, not a full contract. A concrete object of work and a type of request narrow the scope better than a list of big topics. Negative examples show what the Skill should not be confused with.

When it does not fit. If the product does not let you control implicit invocation, the description will reduce false selections but not eliminate them. If a mistaken run could add comments or change a status, you need a separate permission check and confirmation at the tool level. Reliability is measured with a set of requests on the target surface, not just by reading the new description.

Worked example: adapting a Claude Code Skill for Codex

Situation. A team takes a Skill from Claude Code that, when invoked directly with <code>/pr-summary</code>, reads the changed files, runs GitHub CLI commands and returns a short report. Its metadata block at the top of the file contains <code>disable-model-invocation</code>, <code>allowed-tools</code> and <code>context: fork</code>; the body uses shell command substitution and a variable holding the path to the Skill directory. The team simply copies the folder into Codex and expects the same switches to restrict activation and give the commands their permissions.

Problem. Claude Code defines its own meaning for these fields: <code>disable-model-invocation</code> removes automatic invocation, <code>allowed-tools</code> can permit the named tools for the current turn, and <code>context: fork</code> runs the procedure in a separate Claude Code subagent context that does not receive the history of the parent conversation. In the body of the Skill, a construct prefixed with <code>!</code> can run a shell command in advance and then substitute its output into the instruction text; Claude Code also substitutes <code>${CLAUDE_SKILL_DIR}</code> in the text and in Bash rules. These are Claude Code mechanisms, not portable Skill syntax. They are not properties of the shared <code>SKILL.md</code> format, and they do not carry the same permissions into Codex. Codex uses its own discovery paths, the <code>agents/openai.yaml</code> file for metadata and invocation policy, and its own shell permissions. Delegating to a separate Codex subagent is designed separately (see Codex subagents). Even when the file opens, a Claude Code substitution or a pre-approved command does not turn into a Codex permission Claude Code: Skills.

Action. The author separates the reusable procedure from the settings of a particular environment. The portable <code>SKILL.md</code> keeps the essence of the workflow: how to compare the changed files with the criteria, how to label evidence and when to stop. Project rules and private identifiers stay as external context. Claude-specific fields and dynamic insertions are not passed off as shared settings. For Codex, the author adds its supported explicit-invocation metadata, places the package in a documented folder, checks the actual name of the GitHub tool and adapts the script path relative to the Skill root. If the command-line tool is not installed or the environment does not allow it to run, the instructions name that precondition and do not declare the work complete.

Expected result. After the adaptation the team keeps the core of the procedure: reading the changes, the criteria, the report and the stop condition. The Skill is discovered by Codex's rules and should be invoked in the specified way; tool permissions are decided by the environment. The test set should include a specific PR request, a general question about Git and a session with no GitHub integration. This is a test plan, not the result of a run; real observations are added only after testing in the target Codex.

Why it fits. What was ported is knowledge of the process, not the platform's internal machinery. The official Agent Skills specification provides a shared base file, but Claude Code and Codex have additional and differing mechanisms for invocation, paths, permissions and execution rules. OpenAI metadata describes OpenAI settings; it does not turn Claude Code-only keys into Codex commands.

When it does not fit. Automatic porting is dangerous if the original Skill runs a deployment, changes production, or contains shell templates that build commands from the text of the task. First review the whole package and identify every side effect. If there is hardly any shared portable process, it is cheaper and safer to write a separate Codex Skill and keep only the verified criteria and the output format.

A practical model for Skill authors

When designing an OpenAI Skill, think not in terms of a file name but in terms of a chain of evidence:

1. Which specific, recurring request should lead to this Skill?
2. Which source of truth does it read, and which fields or data still need to be verified?
3. Which parts are instructions, which are reference material, which are scripts and which are external tools?
4. On which surface exactly does it live: Codex, ChatGPT, the Responses API or the Agents API?
5. Who has the right to read, run code, write to an external system and confirm the result?
6. Which positive, negative and edge-case examples show that the Skill is selected appropriately and produces useful output?

If the author answers any of these questions with an assumption instead of a fact ("the file is there, so it was found", "the tool is named, so it is allowed", "the model replied, so the action was done"), the procedure is not ready. Check the relevant runtime, folder and permission system; where necessary, leave an honest stop condition.

In short: <code>SKILL.md</code> holds the workflow, and OpenAI metadata adapts it to certain features of Codex and ChatGPT. For the API, files and tools have to be connected separately. Discovering a Skill, invoking it, reading its resources, running code, getting permission for an external action and proving the result are separate transitions. Checking each transition is what makes a repeatable procedure more reliable.

Sources and further reading

Pages and the repository that may change were checked on 26 September 2026.

1. OpenAI, Build skills, current online documentation; the former address developers.openai.com/codex/skills redirects to this page. Supported surfaces, file structure, invocation and metadata in Codex and ChatGPT; accessed 2026-09-26.
2. OpenAI, Skills — API documentation, current online documentation. Hosted references, inline packages, local paths, the Agents API, versions, limits and risks; accessed 2026-09-26.
3. OpenAI, Skills — Plugins concepts, current online documentation. The role of Skills in a workflow and how they differ from an MCP integration; accessed 2026-09-26.
4. Agent Skills, Specification, current format specification. The required <code>name</code> and <code>description</code>, rules for names and descriptions, and differences between implementations; accessed 2026-09-26.
5. Anthropic, Extend Claude with skills — Claude Code Docs, current online documentation. Used only to compare Claude Code metadata and its invocation and access mechanisms; accessed 2026-09-26.
6. OpenAI, openai/plugins: openai-platform-api-key/SKILL.md, commit <code>1dc195897af4161d039b80d8471ec0a10c9bbc89</code>. Reviewed as an example of narrow scope, negative triggers, safety limits and links to references; accessed 2026-09-26.
7. OpenAI, openai/plugins: plugin-eval/evaluate-skill/SKILL.md, same commit. Reviewed as an example of a separate procedure for evaluating a Skill; accessed 2026-09-26.
8. OpenAI Codex, Issue #40458: Windows Desktop App does not discover repository-local skills, report created on 24 August 2026 for Codex App 26.818.2441.0 on Windows. Used as a single report about a specific version, not as evidence of a general defect; status and description checked 2026-09-26.
9. OpenAI, Eric Provencher, Rethinking skills and prompts for GPT-6 Astra, 11 September 2026. Used as a dated personal observation about overly long and contradictory descriptions, not as a normative requirement; accessed 2026-09-26.
10. OpenAI, Local shell, current guide to the local shell tool; used to distinguish it from the legacy <code>local_shell</code>; accessed 2026-09-26.