uGitMe

uGitMe

The Push: June 8th, 2026

Portable AI skills, tiny local search, and a job hunt copilot that finally brings some order to the chaos

Anshul Desai's avatar
Anshul Desai
Jun 08, 2026
∙ Paid

OpenAI Plugins: AI Apps Need Extension Logic

github.com/openai/plugins

A weird thing keeps happening in AI products: the model feels smart until it touches real work. Ask for a product brief, and it helps. Ask it to pull the latest roadmap from Notion, turn design tokens from Figma into code, then push a deploy, and suddenly the experience falls apart into brittle one-offs. OpenAI Plugins matters because it treats that gap as a packaging problem, not just a model problem. The repo is basically a public catalog of how AI tools get specific, with reusable structures for skills, commands, app integrations, and agent behavior.

The Drop: Prompting Stops at the Edge

Chat feels magical right up until the assistant needs a stable relationship with external software. That is the frustration driving OpenAI Plugins. Every serious AI workflow eventually runs into the same wall: one team wants Airtable actions, another wants Jira triage, another wants Figma inspection, and each integration ends up being handcrafted, half-documented, and impossible to reuse cleanly across products.

Plenty of companies already bolt tools onto models. The problem is shape. What belongs in the manifest, what belongs in a command surface, what belongs in a skill, and what belongs in agent instructions? Without a shared packaging model, every AI app becomes its own tiny operating system, with custom glue nobody else can adopt.

Several examples in this repo make that pain very concrete. Figma is not just a connector, it bundles design-aware behaviors. Notion is not just read and write, it carries workflows for planning and research. That distinction matters. The repo is chasing a standard unit of AI capability, something richer than an API wrapper but more portable than a full app.

The Stack: JavaScript at the Center, Metadata Everywhere

JavaScript anchors the repo, with supporting Python scattered through individual plugin skills and scripts. The core pattern is lightweight but structured: a plugin manifest in JSON, optional skills written as task-specific guidance and tooling, plus companion metadata like app descriptors, MCP descriptors, agents, commands, hooks, and assets.

The Sauce: The Plugin Is the Product Boundary

Instead of treating integrations as a raw list of callable tools, OpenAI Plugins defines a plugin as a bundle of behavior. That is the architectural bet, and honestly, that is the interesting part. A plugin can include a plugin manifest, which declares what the package is, then layer in skills, which encode domain-specific playbooks, plus agent configs, commands, and app metadata. In other words, capability is being packaged with context.

That sounds subtle, but it changes how AI systems become reliable. A plain tool interface says, “here is an endpoint.” This repo says, “here is how an assistant should behave around this domain.” For Figma, that might mean code-to-canvas workflows and design system rules. For Atlassian, that might mean turning meeting notes into tasks or generating status reports with the right query patterns. The package is not just access, it is operational judgment.

Architecturally, this looks a lot like the next step after app stores and browser extensions. Those ecosystems standardized distribution of functionality for humans clicking interfaces. This standardizes distribution of workflow intelligence for models. The optional surfaces matter because different capabilities need different control planes. Some need command execution, some need MCP-style interoperability, some need static references, some need visual assets and marketplace presence.

That modularity is clever because it avoids pretending every integration is the same. A finance plugin, a design plugin, and a deployment plugin should not share one flat schema. OpenAI Plugins gives them a common envelope while letting the internals stay specialized.

The Move: Build Repeatability, Not Just Demos

Plenty of teams could put OpenAI Plugins to work immediately, even without shipping an AI product to millions of users. A startup building an internal copilot could package high-value workflows, e.g. “triage support issues from Zendesk into Linear” or “turn product specs into Jira tickets,” as reusable plugins instead of burying logic inside prompts. That creates something much more durable than prompt templates. New teammates inherit a workflow object, not tribal knowledge.

Enterprises should pay attention for a different reason. This repo hints at a governance layer for agent behavior. Once capability is packaged into manifests, commands, and skills, teams can review, version, and standardize how assistants interact with company systems. That means fewer rogue automations, cleaner audits, and easier rollout across departments.

Founders chasing distribution might see an even bigger angle. If plugins become the accepted unit of AI functionality, owning a best-in-class plugin for a category, e.g. Figma handoff, Notion research, or iOS build-debug loops, becomes a wedge into larger platforms. The strategic advantage is not “adding AI.” It is becoming the default behavior package that every AI workspace wants to install.

The Aura: Software Starts Carrying Know-How

People are getting less patient with generic AI help. A chatbot that “can probably do this” no longer feels impressive when the task involves real tools, real documents, and real consequences. What starts to matter is whether software comes with embedded expertise, the kind that already knows the patterns of a meeting recap, a deployment flow, or a design review.

That expectation changes user behavior. Instead of prompting from scratch every time, teams start selecting trusted capability packs. Taste becomes portable. Process becomes installable. On a human level, that means fewer blank-page interactions and more confidence that the assistant understands the norms of the work, not just the words in the request.

The Play: Packaging Becomes the Wedge

This looks less like a pure 0-to-1 category creation and more like an attempt to define the packaging standard inside an existing market, AI assistants with tool access. Still, standards can be where outsized value accrues. TAM is broad because every software category with repeatable workflows can become plugin territory, from design and PM to sales ops and developer tooling. PMF signals are early but real enough: the repo is curated, examples span major products, and the value compounds through community contribution and distribution into host platforms. Moat is not raw code, it is ecosystem gravity, default schemas, and switching costs once teams organize workflows around a common plugin format.

Winners:

  • Tambo: Faster assembly of agent-native product experiences compounds because packaged capabilities reduce custom integration work and shrink CAC for enterprise proofs of concept.

  • Glean: Stronger workflow reach compounds because a plugin standard lets enterprise knowledge retrieval connect to action surfaces, lifting LTV through deeper seat expansion.

  • Atlassian: Broader assistant relevance compounds because Jira and Confluence workflows become easier to distribute as installable behavior bundles across AI products.

Losers:

  • Lindy: More commoditized automation erodes differentiation because bespoke workflow wrappers get replaced by portable plugin packages that are easier to remix elsewhere.

  • Moveworks: Heavier implementation overhead becomes a drag because standardized capability packaging lowers the premium buyers will pay for closed, services-heavy orchestration.

  • Salesforce: Tighter platform control weakens at the edges because third-party AI assistants can ship domain-specific actions without forcing users fully into Salesforce’s own assistant stack.

tl;dr

OpenAI Plugins turns AI integrations into portable capability bundles, not just tool hookups. The smart idea is packaging workflows, instructions, and interfaces together so assistants carry domain judgment, not only API access. Product teams, enterprise AI buyers, and founders building agent experiences should look closely.

Stars: 2,262 | Language: JavaScript

User's avatar

Continue reading this post for free, courtesy of Anshul Desai.

Or purchase a paid subscription.
© 2026 Anshul Desai · Privacy ∙ Terms ∙ Collection notice
Start your SubstackGet the app
Substack is the home for great culture