OpenAI Skills Hit GitHub Trending After Their Catalog Was Deprecated

OpenAI skills reached fifth place on a September 7 GitHub Trending list, despite OpenAI having already deprecated the repository attracting that attention. The conflict matters more than the ranking itself. Developers are discovering a simple format for reusable agent instructions just as OpenAI redirects its distribution strategy toward plugins.

The repository had accumulated 25,655 stars and 1,733 forks when checked on September 7, 2026. GitHub records show that OpenAI created it on November 25, 2025, and last pushed changes on July 14, 2026. Those dates establish the underlying event more clearly than the undated trending entry.

The project is not abandoned because skills failed. Its own notice points developers toward a newer OpenAI Plugins repository and a plugin-building guide. The emerging contest is therefore reusable, portable instructions versus packaged extensions with manifests, tools, controls, and distribution metadata.

That distinction pressures anyone building repeatable AI workflows. A Markdown playbook is easy to inspect and share. A production plugin can also provide tools, authentication, user interfaces, policy controls, and marketplace distribution. OpenAI now appears to want both layers, but under a larger package.

The OpenAI Skills Repository Is Trending After Deprecation

The immediate news is a popularity signal colliding with an official migration signal.

The repository surfaced in fifth place on the supplied GitHub Trending aggregation on September 7. GitHub Trending rankings move frequently, and the aggregator did not include a verified publication timestamp. The ranking should therefore be treated as a snapshot, not a permanent leaderboard position.

The underlying repository data is firmer. GitHub’s public API identifies November 25, 2025, as the creation date. It reports July 14, 2026, as the latest push date. The same record describes the project as a “Skills Catalog for Codex.”

By September 7, the project had more than 25,000 stars. Stars do not equal active installations, satisfied users, or production adoption. They do show unusually broad developer interest in a repository that existed for less than one year.

The project’s repository notice changes the meaning of that interest. OpenAI labels the catalog deprecated and directs readers to the OpenAI Plugins repository for current Codex examples. It also sends creators to new documentation for building skill-only plugins.

That makes this different from a routine trending story. Developers are not merely starring a growing library. They are arriving at an architectural handoff between two ways of distributing agent behavior.

The older repository presents skills as folders containing instructions, scripts, and supporting resources. Codex can discover those folders and activate them for matching tasks. System skills arrive automatically, while curated and experimental skills use an installer workflow.

The new destination treats a skill as one possible component inside a plugin. OpenAI’s Plugins repository supports manifests, skills, MCP server definitions, apps, commands, hooks, agent metadata, and assets. MCP, or Model Context Protocol, provides a standard connection layer between AI systems and external tools or data.

The migration does not erase the smaller format. A skill-only plugin can still center on the same instructional unit. What changes is the package around it, including how OpenAI expects creators to distribute and govern that capability.

GitHub’s figures also require context. The skills repository is not marked as archived, even though its README calls it deprecated. It still exposes issues and remains publicly accessible. OpenAI has preserved it as a reference while moving active examples elsewhere.

That combination helps explain why the project can trend after deprecation. Existing links still work, the examples remain useful, and the concept is easier to grasp than a complete plugin architecture. The repository is becoming an educational doorway, even if it is no longer the preferred destination.

For developers, the practical message is precise. The skill format remains relevant, but the old catalog is no longer the current distribution map. New work should account for the plugin layer before teams build installation processes around the deprecated repository.

Why OpenAI Skills Attracted Developers So Quickly

Skills turn repeated prompting into versioned operational knowledge without requiring a new model or application.

A skill starts with a SKILL.md file containing metadata and instructions. It can also include scripts, references, templates, schemas, and other resources. That structure lets a team store more than a polished prompt.

A useful skill can specify when it should activate, what inputs it needs, which steps must run, and how the output should look. It can also define checks that must pass before the agent finishes. Those details convert an informal habit into a reusable procedure.

OpenAI’s skills guidance describes the format as a way to stop re-explaining recurring work. That framing makes the appeal easy to understand. Many agent failures come from missing process context rather than insufficient model intelligence.

Consider a code review workflow. A normal prompt might ask an agent to inspect a pull request. A skill can require framework detection, security checks, test execution, evidence collection, and a fixed reporting format.

The same pattern applies outside software development. A research skill can set source standards and verification rules. A presentation skill can bundle layouts and brand assets. A publishing skill can enforce metadata, image, translation, and quality checks.

This model also supports progressive disclosure. The agent first sees a skill’s name and description, which help it decide whether the workflow applies. It loads the full instructions only after activation. Supporting files can remain unloaded until the task requires them.

That approach reduces context pressure. An organization can keep many specialized workflows available without placing every instruction into every conversation. The agent receives detailed guidance when it becomes relevant.

The open Agent Skills specification formalizes the core directory layout. It requires a SKILL.md file with YAML metadata and Markdown instructions. Scripts, references, and assets remain optional.

Portability follows from that modest contract. Plain text works with version control, code review, and familiar developer tools. Teams can inspect a change to an agent workflow before merging it, just as they inspect application code.

However, “write once, use everywhere” remains an aspiration rather than a guarantee. Compatible clients can interpret optional fields differently. Tool names, permissions, filesystem paths, and execution environments can also vary.

A skill that tells Codex to invoke a local command will not automatically work in a browser-only agent. A workflow depending on private company data needs a valid connector and permission model. A polished instruction file cannot remove those environmental differences.

Even with those limits, the format offers a useful separation. The model supplies general reasoning, while the skill supplies local procedure. Teams can improve the procedure without training another model or rebuilding an application.

That separation also changes ownership. Subject-matter experts can help write workflows in readable Markdown. Engineers can add deterministic scripts where exact behavior matters. Reviewers can audit both parts inside one versioned folder.

The result sits between a prompt and conventional software. It is more structured than a copied instruction block, but lighter than a complete application. That middle layer explains why the repository drew attention across technical and nontechnical use cases.

Knowledge workers face the same repetition problem. Research methods, meeting analysis, document review, and reporting standards often live in scattered notes. A structured AI workflow can preserve those decisions and make them easier to reuse.

OpenAI skills became popular because they gave that reusable layer a recognizable shape. The repository’s deprecation does not remove the underlying demand. It signals that OpenAI wants to place the shape inside a broader product and distribution system.

OpenAI Skills Are Moving Inside a Larger Plugin Package

OpenAI is preserving the skill as an instructional component while changing the unit that users install and administrators control.

The replacement repository makes the new boundary visible. Each plugin includes a required .codex-plugin/plugin.json manifest. A manifest identifies the package and provides metadata that the host can use during installation and discovery.

The plugin may then contain skills, MCP configurations, app definitions, commands, hooks, assets, and agent-facing metadata. Not every package needs every surface. A creator can still build a skill-only plugin when instructions and bundled resources are sufficient.

OpenAI’s plugin packaging guide says the manifest belongs at the plugin root. The directory can then group related capabilities under a single installable package. That creates a clearer deployment boundary than a loose folder copied into a skills directory.

This is the central opponent in the story: portable instruction folders versus governed extension packages. The two are not mutually exclusive technologies. They represent different answers to what should count as the distributable product.

A standalone skill prioritizes readability and portability. Its center of gravity is the playbook. Developers can clone a folder, inspect its files, and adapt the workflow for another compatible agent.

A plugin prioritizes integration. Its center of gravity is the complete capability delivered to a user or organization. The package can combine instructions with external tools, authentication requirements, interface components, and lifecycle controls.

That distinction matters once workflows leave individual machines. A company distributing an agent capability must answer who maintains it, which data it can access, and how updates arrive. It also needs a way to disable or replace compromised versions.

A folder convention alone does not answer every question. Hosts still need installation, policy, provenance, and permission systems. Plugins give OpenAI a container where those concerns can become explicit.

The new model also reflects the expanding role of AI agents. Early skill examples often focused on telling an agent how to complete a task. Newer extensions increasingly need to supply the actions and interfaces required to complete that task.

A sales workflow illustrates the difference. Instructions can explain how to qualify a lead and format a summary. Completing the workflow may require a customer database connection, authorization, write controls, and a confirmation interface.

Packaging those pieces together reduces setup friction. It can also make the capability easier for an administrator to evaluate as one unit. The tradeoff is additional complexity for creators who only wanted to share a readable procedure.

This transition pressures library maintainers and enterprise teams first. Maintainers must decide whether to preserve a generic skill folder or adopt OpenAI-specific packaging. Enterprises must decide which layer they will review, approve, and deploy.

Agent platform competitors face pressure too. The open skill format lowers the cost of moving instructional content between compatible clients. Product-specific packaging can then create differentiation around discovery, governance, interfaces, and connected tools.

OpenAI is not alone in recognizing the value of skills. The Agent Skills project says Anthropic originally developed the format before releasing it as an open standard. Its quickstart lists Claude Code, OpenAI Codex, and GitHub Copilot among compatible environments.

That industry background complicates any claim that OpenAI owns the category. OpenAI maintains its implementation, examples, and product conventions. The underlying format belongs to a broader effort to make agent procedures portable.

The repository transition therefore looks less like a retreat from standards and more like a move up the stack. OpenAI can retain compatibility with a simple instructional format while competing through the package, host, marketplace, and control plane around it.

The decisive question is whether that layering stays clean. Developers should be able to reuse core instructions without carrying every OpenAI-specific integration. Users should also receive the richer installation and security experience promised by plugins.

If those goals remain compatible, the migration will expand the value of skills. If product metadata and proprietary hooks spread into the core workflow, portability will weaken despite continued support for SKILL.md.

The Format’s Simplicity Hides Security and Reliability Risks

A readable skill can still direct an agent toward unsafe commands, untrusted content, or actions beyond the user’s intent.

The repository’s popularity should not be interpreted as evidence of production readiness. GitHub stars measure interest, not security review. Fork counts show reuse or experimentation, not successful deployment.

Skills occupy a sensitive position because they influence agent behavior. A user may read the title and description, while the agent later loads detailed instructions, scripts, or references. Those deeper resources can affect tool selection and execution.

This creates a supply-chain concern. A malicious or compromised package could include instructions that seek secrets, alter files, or contact an unexpected service. A script can create more direct risk if the host allows it to execute.

Plain text improves inspectability, but inspection must actually happen. Teams should review every bundled file, not only SKILL.md. They should also inspect updates before accepting a new revision.

Descriptions introduce another reliability risk. They determine when many agents choose to activate a skill. An overly broad description can trigger the wrong workflow, while a vague one can leave a relevant capability unused.

The official skill-creator example emphasizes detailed descriptions because they carry the burden of discovery. That is a practical design constraint, not a minor documentation preference. Activation errors can change the entire path an agent follows.

Instruction conflicts add another layer. A repository can contain system policies, project instructions, user requests, and activated skills. The host needs a clear priority model when those sources disagree.

A skill should never gain authority merely because it activated. The agent still needs to respect user scope, platform policy, sandbox restrictions, and approval requirements. Packaging alone cannot guarantee that behavior.

Tool portability also remains incomplete. The open specification defines how a skill is arranged, but it does not make every referenced tool available. A workflow that succeeds in one Codex environment can fail elsewhere because permissions or connectors differ.

The same issue appears with local paths and dependencies. A bundled Python script may assume a package, operating system, or command-line utility. Creators need explicit compatibility notes and useful failure messages.

Maintenance is another concern. A skill can silently become stale when an API changes, a product moves a setting, or a compliance requirement evolves. Version control records the change history, but it does not validate continued correctness.

Deterministic checks can reduce that risk. Creators can include validation scripts, schema tests, example inputs, and acceptance criteria. Teams can run those checks during review and after dependency updates.

Evaluation should also cover behavior, not only file structure. A valid folder can still produce unreliable outcomes. Teams need representative tasks that test activation, execution, error handling, and refusal boundaries.

The deprecation of a highly starred catalog demonstrates a related lifecycle problem. A resource can remain visible long after the preferred installation path changes. Search results and shared links can keep sending newcomers toward outdated guidance.

OpenAI addresses this with a prominent notice and direct migration links. That is useful, but hosts and installers should eventually surface deprecation status before installation. A warning buried inside a README arrives too late for some workflows.

Enterprises will likely demand signed packages, publisher identity, version constraints, permission declarations, and audit trails. Those needs favor the plugin model. They also increase the distance between a casual Markdown workflow and an approved organizational capability.

Developers should resist treating either format as inherently safe. A small folder is easier to inspect, while a managed plugin can support stronger controls. Both depend on trustworthy distribution and disciplined host behavior.

The right security question is not whether a skill contains code. Instructions themselves can cause consequential tool use. Review must cover what the package persuades the agent to do, which resources it loads, and which actions it enables.

Open Standards and Product Control Now Share the Same Layer

The market is converging on portable skill instructions while competing over the systems that discover, authorize, and distribute them.

The Agent Skills specification supplies a common minimum. A directory needs a SKILL.md file, required name and description fields, and Markdown instructions. Optional directories can contain scripts, references, and assets.

That minimum makes cross-client reuse plausible. It does not require every vendor to expose identical installation methods or tools. Each platform can build its own runtime behavior around the shared folder structure.

OpenAI’s repository used that portability as a central message. Its README described skills as reusable across agents and linked directly to the open standard. The new plugin direction adds an OpenAI-specific package without necessarily changing the inner skill.

This resembles earlier layers in software development. A source file can use a standard language while applications ship through different package managers and stores. Compatibility at one layer does not eliminate competition at another.

The benefit is specialization. OpenAI can improve installation, interface metadata, and administrative controls without waiting for a universal specification. Other agent platforms can implement their own packaging while continuing to understand the same basic skill.

The risk is gradual fragmentation. Product-specific metadata can become essential to discovery. Vendor-only hooks can become necessary for useful behavior. A nominally portable workflow can then lose important capabilities outside its original host.

Creators should separate core procedure from host integration wherever practical. The skill can describe the durable workflow. Product-specific files can define interface presentation, connectors, permissions, and installation behavior.

That separation also helps teams manage knowledge. A reliable workflow often outlives the model, interface, or tool used to run it. Keeping durable procedure readable makes migration and auditing easier.

The underlying trend reaches beyond OpenAI. Agent products increasingly need structured methods for carrying organizational knowledge into execution. Prompts alone are difficult to govern when they live in personal documents or conversation histories.

Skills make that knowledge visible. Plugins make it deployable. Connected tools make it actionable. The industry is now deciding how those three layers should interact.

For model providers, the opportunity is strategic. A rich extension library makes an agent more useful without requiring every capability inside the model. It also creates a distribution channel connecting developers, businesses, and users.

For enterprises, the value is operational. Teams can standardize recurring processes while retaining reviewable source material. They can attach controlled tools when the workflow needs access to company systems.

For individual developers, the calculus is mixed. A standalone skill remains the fastest way to encode a recurring procedure. A plugin becomes worthwhile when distribution, interfaces, or connected services matter.

The trending repository captures that tension unusually well. Developers are voting for the approachable object, a folder they can read. OpenAI is investing in the managed object, a package the product can install and govern.

Neither signal cancels the other. Together, they suggest that successful agent ecosystems need a small authoring primitive and a larger delivery mechanism. Problems arise only when the delivery layer obscures or locks the primitive.

OpenAI’s next challenge is to preserve the clarity that drove interest in the original catalog. Plugin architecture can solve real deployment problems, but it should not make a simple workflow feel like application development.

What Developers Should Watch After the OpenAI Skills Migration

Three signals will show whether OpenAI can convert repository interest into a durable extension ecosystem.

The first signal is migration clarity. OpenAI needs current examples that show when creators should use a standalone skill, a skill-only plugin, or a richer plugin. Clear compatibility guidance would strengthen the case that the new layer extends skills instead of replacing them.

The Plugins repository already contains more than 300 commits and examples spanning design, mobile development, deployment, presentations, and connected services. The older skills repository shows 114 commits. Those totals describe repository activity, not quality, but they reveal where new development is concentrated.

Watch whether popular examples from the deprecated catalog receive direct successors. A documented mapping would reduce confusion for existing users. Missing equivalents would suggest that part of the older catalog no longer fits OpenAI’s priorities.

The second signal is cross-client portability. Developers should test whether the same core SKILL.md performs consistently in Codex, Claude Code, GitHub Copilot, and other compatible hosts. Successful reuse would support the open-standard promise.

Those tests should separate instructions from integrations. A workflow may remain portable while its MCP server, interface, or authentication layer stays product-specific. Reporting that distinction will produce more useful evidence than declaring an entire plugin portable or incompatible.

The third signal is governance. OpenAI’s plugin system needs visible answers for publisher identity, permissions, updates, deprecation, and organizational controls. Strong controls would justify the additional packaging and help enterprises approve agent capabilities.

Governance will become especially important as plugins combine instructions with external actions. Users need to know which data a plugin can read and which systems it can modify. Administrators need ways to restrict those capabilities by workspace and role.

The old repository offers a warning about lifecycle communication. It remained unarchived and highly discoverable after its README declared deprecation. Better installer-level notices would prevent users from adopting outdated packages without seeing the warning.

Developers should also watch the relative growth of both repositories. Continued starring of the deprecated catalog would signal persistent demand for simple examples. Faster adoption of plugins would suggest the broader package is becoming understandable enough for mainstream use.

A single GitHub Trending appearance cannot establish either outcome. The ranking has no verified timestamp beyond the September 7 snapshot, and it provides no installation or retention data. The stronger evidence will come from maintained examples, successful migrations, and repeatable cross-client tests.

For teams evaluating OpenAI skills now, the sensible action is to preserve workflow logic in a standards-compatible SKILL.md. New distribution work should follow OpenAI’s plugin guidance and keep product-specific integration outside the core procedure.

That approach protects the reusable knowledge while acknowledging where OpenAI is heading. Audit scripts and permissions before installation, record the source revision, and test the workflow against representative tasks.

The final question is practical: does your agent need better instructions, or does it need a complete extension with tools and governance? Start with the smallest reviewed skill that solves the recurring task. Move to a plugin when distribution, connected actions, or organizational control becomes part of the requirement.