I would separate “knows our process” from “can reach our CRM.” Those are different capabilities, and treating them as one is how a useful workflow turns into a confusing installation project.
My shorthand is procedure, connection, package. A skill carries the procedure, MCP supplies a tool connection, and a plugin can distribute the pieces. Start with the job you want repeated.
Start with a repeatable procedure
For the fictional Cedar Metrics workflow, a useful procedure reads a campaign export, applies agreed metric definitions, reconciles totals and produces a draft report. That sequence can be documented without any external service connection.
Once the procedure works, a skill can preserve the instructions and supporting resources. This prevents each new task from having to rediscover the same denominator checks and output structure. It also gives a maintainer a concrete artifact to review when the workflow changes.
I would avoid creating a skill from an untested prompt just because it sounds reusable. Run the procedure on a known fixture, inspect the output and fix the ambiguous steps first. Packaging a weak process makes it easier to repeat the weakness.
TipCapture the accepted procedure and its checks after a successful manual run.
Understand the skill folder
A skill is a directory containing SKILL.md, with required name and description metadata and instructions below it. It can include references and scripts when the workflow needs them. The current documentation describes progressive loading: the agent sees identifying information first and reads the full instructions when the skill is selected.
The description therefore has a practical job. It should explain when the skill applies and where its scope ends. “Helps with business” is too broad. “Builds a campaign report from an approved export and reconciles aggregate metrics” is a useful trigger.
Keep deterministic calculations in a small tested script when appropriate, while using the instructions to explain input definitions, review and interpretation. A skill can combine judgment with ordinary code; it does not need to turn every arithmetic operation into a language-model decision.
TipUse a clear description with the task and input type near the beginning.
Invoke and verify the skill
In Codex CLI or the IDE extension, current documentation supports /skills or a $ mention to select a skill. ChatGPT uses @ selection in supported workflows. The agent can also choose a skill when the task matches its description, so good scope language helps both explicit and implicit use.
For a first test, invoke the skill explicitly and supply the fictional campaigns.json fixture. Confirm that the procedure actually loads and that the output follows its checks. Do not infer successful invocation merely because the answer resembles the desired report.
Standalone skills and plugin-bundled skills have different surface availability. Read the current installation guidance for the surface you use. A skill folder on your laptop is not automatically available to every web or mobile conversation under the same account.
TipTest explicit invocation before relying on automatic matching.
Use MCP when the workflow needs a connection
MCP is a protocol for connecting an agent client with tools and resources supplied by a server. The server determines which capabilities it exposes; the authenticated identity and service permissions determine what those capabilities can access.
For Cedar Metrics, a reporting skill might eventually use an approved CRM connection to retrieve fresh opportunity data. MCP supplies the tool interface, while the skill explains how to use the retrieved fields and validate the report. Neither replaces the other.
I would inspect the exposed tools before designing around them. A server may offer search and retrieval without the write action you expected. A generic statement that it “supports the CRM” is not enough to establish the workflow’s actual capabilities.
TipList the specific tool operation and fields required by the task before installing a server.
Configure access through the supported flow
Codex supports local and remote MCP server configurations through its documented setup. In the CLI, codex mcp provides management commands, and some remote services require an authentication flow. The correct configuration depends on the server’s official instructions.
Use an approved server and the intended service account. Keep credentials in the supported configuration or authentication mechanism, not in SKILL.md or a shared prompt. Then run a narrow read-only request against a record you can verify independently.
The test should establish both availability and correctness. A server starting successfully does not prove that it points to the right tenant or that the returned company is the intended account. Record identity, source timestamps and permissions all remain part of the review.
TipCheck the account and workspace after authentication, especially if you have several service logins.
Treat plugins as installed software
A plugin can bundle skills, MCP connections and other components such as interfaces or hooks. That makes installation convenient, but it also means the package may do more than supply a paragraph of instructions. Inspect its source, components and supported surfaces.
Current documentation supports plugins across several ChatGPT and Codex surfaces, while the IDE extension does not support plugin packages. Desktop-only components still require the relevant desktop environment. A shared directory is not a promise of identical execution everywhere.
I would install a package because a specific workflow needs it. A large collection of loosely understood plugins creates more possible actions and more maintenance without necessarily improving the next result. One well-understood connection is enough for a first account-brief workflow.
TipReview scripts and hooks as executable components, not as harmless documentation.
Test the complete workflow in layers
Test the skill against a local fixture first. Then test the connection with a small read-only query. Finally combine them and compare the resulting report with the source records. This sequence makes it easier to identify whether a failure comes from procedure, access or interpretation.
For the fictional campaign report, the expected totals provide a stable procedure test. For a connected CRM brief, use record links and dated fields as the evidence. If the combined workflow changes a business conclusion, inspect whether the source changed or the procedure applied it differently.
Add write actions only when the intended fields, authorization and duplicate-handling behavior are clear. A workflow that can retrieve an opportunity correctly has not yet demonstrated that it can safely update one.
TipKeep separate checks for procedure correctness and service connectivity.
Where extensions become a distraction
The first failure is installing tools before defining the task. The second is copying the same instructions into AGENTS.md, a skill and a plugin without a clear source of truth. The third is assuming a familiar package name proves its code and permissions are appropriate.
Keep the architecture small enough to draw: standing project rules, one procedure, the required connections and a reviewable output. If you cannot explain why a component is present, remove it from the first version and test the simpler workflow.
A skill should save a repeated explanation. A connection should supply a necessary capability. A package should make distribution manageable. Which part of your current process actually needs to become reusable?
How to set it up
Prove the procedure
Run the campaign report manually against the known fictional fixture and record the accepted checks.
Create and invoke a skill
Use the supported skill creator or a documented SKILL.md folder, then invoke it explicitly in your surface.
Add a connection if needed
Configure an approved MCP server through its supported authentication flow and test one read-only query.
Test the combined result
Compare source records, calculations and output. Review permissions before adding any write action.
Frequently asked questions
Is a skill an MCP server?
No. A skill supplies a procedure; an MCP server exposes tools or resources through a connection.
Does every skill need code?
No. Instructions can be enough. Add scripts when they make deterministic work easier to verify.
How do I invoke a skill in Codex?
Use supported /skills selection or a $ mention in CLI or the IDE extension.
Can a skill be selected automatically?
Yes, when the task matches its description. Test explicit use first so you know it works.
Does installing a plugin grant service access?
It may still require separate authentication and authorization. Verify the connected identity and scope.
Can I use plugin packages in the IDE extension?
Current documentation says the IDE extension does not support plugins; skills and MCP are separate supported routes.
Where should secrets go?
Use the supported credential or authentication configuration, never the skill instructions or repository source.
What should I build first?
One tested procedure with known inputs and checks. Add connections only when the workflow needs them.
Sources & further reading
ChatGPT and Codex change quickly. This page was last reviewed September 22, 2026; verify time-sensitive details against the official docs above before relying on them.