AI App Integration
Purpose
Help agents decide whether an AI-powered feature should be built with AI SDK only, ChatGPT Apps SDK + MCP, or a hybrid, then make model, tool, UI, and persistence ownership explicit before implementation. This is a guardrail, not an API manual.
Use When
- the task touches chat, streaming, structured output, tool calling, embeddings, or agent loops
- the task needs a ChatGPT host surface, widget, MCP tool, or app submission shape
- the current implementation mixes model logic, tool execution, UI state, and storage
- the answer depends on current AI SDK or Apps SDK API shapes
Do Not Use When
- the task is pure prompt writing, evaluation, or model comparison with no app integration
- the work is generic backend plumbing that does not touch an AI surface
- deployment, auth, or launch logistics are the only problem
- another more specific skill already owns the surface
Quick Start
- Classify the request first as
AI SDK only, ChatGPT Apps SDK + MCP, or hybrid.
- Write the ownership map next: model, tools, UI, persistence.
- Fetch current official docs before writing code whenever AI SDK v6 or Apps SDK APIs are involved.
- Prefer AI SDK v6 for chat, streaming, structured output, tool calling, embeddings, and agent loops.
- Use ChatGPT Apps SDK + MCP only when the user-visible surface needs ChatGPT host integration or a widget.
- Treat
window.openai compatibility as secondary to the MCP Apps bridge and current docs.
- End with the next verifier and the evidence it should capture.
Operating Constraints
- Do not let UI state leak into model tools.
- Do not hide persistence behind tool calls.
- Do not choose ChatGPT Apps when a plain AI SDK route is enough.
- Do not rely on v5-era AI SDK snippets or memory for v6 signatures.
- Do not teach wrapper helpers as the canonical surface when the docs expose a better current API.
- Do not turn this into a generic AI SDK cookbook or a ChatGPT Apps walkthrough.
Inputs This Skill Expects
- the user goal and the target surface
- whether the feature needs a ChatGPT host surface, widget, or MCP tool exposure
- the current model, tool, UI, and persistence boundaries if any exist
- the official docs or package versions already in scope
- any existing route, server, or widget file that the request should fit into
Output Contract
- Name the classification first.
- State which layer owns generation, tool execution, UI rendering, and persistence.
- State which current docs must be checked before code changes.
- Recommend the smallest viable starting point and what not to build.
- Keep the answer at planning level unless the task explicitly asks for implementation details.
Procedure
- Read the request and classify the surface.
- Draw the boundary map before choosing code shape.
- Check the current official docs for every AI SDK or Apps SDK API involved.
- Choose the smallest architecturally coherent seam that satisfies the contract honestly.
- Prefer AI SDK only unless the host surface materially changes the product.
- Use ChatGPT Apps SDK + MCP when the product needs ChatGPT-hosted UI, widget metadata, or MCP tool wiring.
- Verify the selected seam against the docs and the next runtime or browser check.
Pitfalls And Gotchas
- Rejected trope: wire the model straight to the UI and let tools sort out the rest.
- Better alternative: separate model, tool, UI, and persistence ownership first, then connect them with explicit interfaces.
- Rejected trope: build a ChatGPT app because the feature is interactive.
- Better alternative: stay AI SDK only when the host surface does not add value.
- Rejected trope: follow old SDK snippets from memory.
- Better alternative: fetch current docs and match the current v6 or Apps SDK signatures.
- Rejected trope: hide storage inside tool handlers.
- Better alternative: keep persistence behind its own API or data layer.
- Rejected trope: turn the skill into a full API reference.
- Better alternative: keep it a guardrail that chooses seams and evidence.
Progressive Disclosure
Start with the smallest useful decision: surface class, ownership map, and docs check. Expand only enough to choose between AI SDK only, ChatGPT Apps SDK + MCP, or hybrid cleanly. Keep the skill short so it steers implementation instead of becoming a manual.
Verification Pattern
- Confirm the classification is explicit.
- Confirm model, tool, UI, and persistence boundaries are named separately.
- Confirm a docs-first check is named before code.
- Confirm the answer does not collapse into a generic prompt-engineering or app-architecture essay.
- Next verifier: the implementation reviewer or checker; capture the docs consulted, the selected architecture, and the boundary map.
1---2name: ai-app-integration3description: Guardrail for choosing and separating AI SDK and ChatGPT Apps SDK integration seams.4---56# AI App Integration78## Purpose9Help agents decide whether an AI-powered feature should be built with AI SDK only, ChatGPT Apps SDK + MCP, or a hybrid, then make model, tool, UI, and persistence ownership explicit before implementation. This is a guardrail, not an API manual.1011### Use When12- the task touches chat, streaming, structured output, tool calling, embeddings, or agent loops13- the task needs a ChatGPT host surface, widget, MCP tool, or app submission shape14- the current implementation mixes model logic, tool execution, UI state, and storage15- the answer depends on current AI SDK or Apps SDK API shapes1617### Do Not Use When18- the task is pure prompt writing, evaluation, or model comparison with no app integration19- the work is generic backend plumbing that does not touch an AI surface20- deployment, auth, or launch logistics are the only problem21- another more specific skill already owns the surface2223## Quick Start241. Classify the request first as `AI SDK only`, `ChatGPT Apps SDK + MCP`, or `hybrid`.252. Write the ownership map next: model, tools, UI, persistence.263. Fetch current official docs before writing code whenever AI SDK v6 or Apps SDK APIs are involved.274. Prefer AI SDK v6 for chat, streaming, structured output, tool calling, embeddings, and agent loops.285. Use ChatGPT Apps SDK + MCP only when the user-visible surface needs ChatGPT host integration or a widget.296. Treat `window.openai` compatibility as secondary to the MCP Apps bridge and current docs.307. End with the next verifier and the evidence it should capture.3132## Operating Constraints33- Do not let UI state leak into model tools.34- Do not hide persistence behind tool calls.35- Do not choose ChatGPT Apps when a plain AI SDK route is enough.36- Do not rely on v5-era AI SDK snippets or memory for v6 signatures.37- Do not teach wrapper helpers as the canonical surface when the docs expose a better current API.38- Do not turn this into a generic AI SDK cookbook or a ChatGPT Apps walkthrough.3940## Inputs This Skill Expects41- the user goal and the target surface42- whether the feature needs a ChatGPT host surface, widget, or MCP tool exposure43- the current model, tool, UI, and persistence boundaries if any exist44- the official docs or package versions already in scope45- any existing route, server, or widget file that the request should fit into4647## Output Contract48- Name the classification first.49- State which layer owns generation, tool execution, UI rendering, and persistence.50- State which current docs must be checked before code changes.51- Recommend the smallest viable starting point and what not to build.52- Keep the answer at planning level unless the task explicitly asks for implementation details.5354## Procedure551. Read the request and classify the surface.562. Draw the boundary map before choosing code shape.573. Check the current official docs for every AI SDK or Apps SDK API involved.584. Choose the smallest architecturally coherent seam that satisfies the contract honestly.595. Prefer AI SDK only unless the host surface materially changes the product.606. Use ChatGPT Apps SDK + MCP when the product needs ChatGPT-hosted UI, widget metadata, or MCP tool wiring.617. Verify the selected seam against the docs and the next runtime or browser check.6263## Pitfalls And Gotchas64- Rejected trope: wire the model straight to the UI and let tools sort out the rest.65- Better alternative: separate model, tool, UI, and persistence ownership first, then connect them with explicit interfaces.66- Rejected trope: build a ChatGPT app because the feature is interactive.67- Better alternative: stay AI SDK only when the host surface does not add value.68- Rejected trope: follow old SDK snippets from memory.69- Better alternative: fetch current docs and match the current v6 or Apps SDK signatures.70- Rejected trope: hide storage inside tool handlers.71- Better alternative: keep persistence behind its own API or data layer.72- Rejected trope: turn the skill into a full API reference.73- Better alternative: keep it a guardrail that chooses seams and evidence.7475## Progressive Disclosure76Start with the smallest useful decision: surface class, ownership map, and docs check. Expand only enough to choose between AI SDK only, ChatGPT Apps SDK + MCP, or hybrid cleanly. Keep the skill short so it steers implementation instead of becoming a manual.7778## Verification Pattern79- Confirm the classification is explicit.80- Confirm model, tool, UI, and persistence boundaries are named separately.81- Confirm a docs-first check is named before code.82- Confirm the answer does not collapse into a generic prompt-engineering or app-architecture essay.83- Next verifier: the implementation reviewer or checker; capture the docs consulted, the selected architecture, and the boundary map.