Build Request | Team AI plugin architecture: split Apps, Skills, and workflows out of the giant prompt

Direct answer

A team should not make one growing prompt carry role definition, knowledge sources, tool permissions, execution order, and output format. A maintainable AI plugin separates them: the role names the user and goal, Skills preserve decision methods, Apps or MCP connect data and actions, workflows define sequence and confirmation, and templates define the deliverable.

The value is not tidier files. It is the ability to replace a source, update a rule, constrain permission, or locate a failure without revalidating one giant text block.

What OpenAI announced

On August 4, 2026, OpenAI announced plugins for K–12 teachers, higher-education faculty, and higher-education students. OpenAI describes a plugin as Apps, role-specific Skills, instructions, and common workflows packaged to start multi-step work without first constructing a complex prompt.

The plugins can connect user-selected course materials, documents, calendars, and approved Apps. Published availability is limited to district deployments of ChatGPT Edu and ChatGPT for Teachers, with institutions controlling tools and permissions. This article extracts an architecture to test; it is not an installation review.

Why giant prompts become difficult to operate

A long prompt mixes concerns that change at different rates: role and completion criteria; business sources; reusable judgment methods; tool permissions; execution order and stops; and output contracts.

When one layer changes, the whole prompt must be reread and retested. After a failure, the team cannot tell whether a source was missing, a Skill judged incorrectly, a connector failed, a workflow skipped a check, or a template omitted a field.

A six-layer team plugin

This extends OpenAI's “App + role Skill + instructions + common workflows” definition; it is not an official directory specification.

1. Role: define the user, result, completion criteria, priorities, and decisions reserved for a person.
2. Sources: list approved projects, documents, calendars, repositories, and selection rules so changing facts do not become permanent Skill knowledge.
3. Skills: store repeatable methods—release review, fact checking, code review, or support triage—independently of a connector.
4. Apps / MCP: read systems and execute actions with explicit least privilege. Playing a role must not grant broad account access.
5. Workflows: define triggers, sequence, confirmation points, stop conditions, and recovery.
6. Templates: fix required output fields and order without deciding whether the content is correct.

A Skill decides how to judge. An App or MCP defines what can be read or done. A workflow decides what happens first and when to confirm. A template defines what must be delivered.

Example: a release-manager plugin

A weekly release review could use:

• Role: release manager, responsible for a publish-or-block decision.
• Sources: release notes, migrations, rollback documentation, and change scope.
• Skill: version, migration, compatibility, evidence, and rollback checks.
• App / MCP: GitHub commits and CI plus Sentry error state.
• Workflow: collect evidence → run checks → stop on a blocker → obtain human approval → generate the announcement.
• Template: decision, change summary, verified items, blockers, and rollback entry point.

Replacing Sentry should change the connector, not the review method. A new standard should change the Skill; a new announcement format should change the template.

Minimum reversible prototype

Choose a task repeated at least weekly with clear inputs and acceptance criteria. Start with one real source, one automated low-risk step, one human confirmation, and two samples: one that must pass and one that must stop.

release-plugin/
  role.md
  sources.json
  skills/release-check/SKILL.md
  workflows/release-review.md
  templates/release-note.md

The test is not file count. A boundary is real only if a source, rule, permission, sequence, or output can change and be tested inside its own layer.

Pre-launch checklist

1. Does the role own one concrete job?
2. Can every fact be traced to an approved source?
3. Can the Skill change without replacing the connector?
4. Do Apps or MCP use least privilege and confirm writes?
5. Does the workflow define inputs, checkpoints, stops, and recovery?
6. Does the template make missing output obvious?
7. Is there one real pass case and one real block case?
8. Can logs identify the failing layer?

Evidence boundary

We have not run the education plugins and do not recommend installing them based on this article. Non-education teams can test the packaging idea with a reversible prototype, but should not treat this as an effectiveness evaluation.

— Token Beggars Editorial