ChatGPT Extensions Keep Product Interfaces and Context Beside the Conversation
Corey Ching argues that ChatGPT plugin extensions can keep a product’s interface and selected context beside a conversation, so users can ask for help without losing sight of what they are working on. The Figma and Meetings demonstrations show how selected designs or meeting notes can inform a request while remaining available for review. Ching recommends starting with a user task, then building and refining an extension around it.
The extension keeps the interface and its context beside the conversation
Corey Ching describes plugin extensions as a way to bring more of a product’s interface into ChatGPT. The difference from embedding a webpage or displaying an artifact is that an extension can have a persistent home in the sidebar or open as an interactive side panel beside an existing conversation. Builders control the layout, navigation, and interactions, shaping what users can explore and how they work with it.
That arrangement keeps two modes of work available at once: using a product interface directly and asking ChatGPT for help with relevant context still in view. Ching says sidebar experiences such as Code Review and Meetings use the same plugin system.
The Figma demonstration makes the connection concrete. A user opens the Figma extension from the sidebar, places it beside a conversation, selects design frames, and asks ChatGPT for help implementing them. The displayed response describes a design-to-code workflow and says it will add components and design-system tokens; a later view shows proposed components alongside a live preview. The user can ask for a different layout while ChatGPT knows which design element is selected.
Your extension connects those interactions to the conversation.
The example is not just about displaying a design next to chat. It shows how a selected object in the product interface can inform a request, while the interface and resulting work remain available for the user to inspect.
Shared context can support different kinds of work
The Meetings demonstration uses the same pattern for notes and follow-up. The meeting displayed is explicitly labeled a fictional sample. Its notes describe a Harbor onboarding launch review: six customer walkthroughs produced four teams that completed setup without help and two that paused at the permissions screen, unsure who would gain access. The discussion recommends clearer permission labels and a preview of the invitation before it is sent.
The sample summary says the October 8 pilot remains achievable if duplicate invitations are fixed and an accessibility check is completed. It says invitations will be limited to 20 existing customer workspaces, with broader availability to be discussed after one week of pilot feedback. The meeting discussion also records a decision to use one default template for the pilot and revisit template selection afterward.
A separate action-item view presents additional specifics: keep the pilot cap at 20 workspaces until an October 15 review, and assign follow-ups for duplicate invitations, permission wording, accessibility checks, and confirming the eligible workspaces. Keeping these views distinct matters: the summary and discussion describe the meeting, while the action-item screen shows follow-ups and a more specific review point.
From the sidebar, the user asks what the team decided and what needs follow-up. The displayed next request asks ChatGPT to draft a setup guide based on the notes, covering the default template, permissions, inviting a teammate, feedback after the first session, and a launch checklist. It also directs ChatGPT to use placeholders for product links or support contacts that were not provided. The screen shows ChatGPT beginning that task; it does not show a completed guide.
Here, the extension gives the user a way to bring meeting material into a conversation without restating it. The requested output is grounded in the notes, and the user can review the work as it is produced.
The product determines what users can explore and do
Extensions are also a way to make a product’s own navigation and resources available inside ChatGPT. Ching says builders can customize the onboarding flow after installation, @mentions in the composer, and controls and settings, in addition to the interface itself.
The OpenAI Developers example illustrates a resource-oriented use. Ching says he built it in Codex using Plugin Creator. Its displayed interface sits beside a code window and offers documentation, developer tools, DevDay talks, featured sessions, and a schedule. Rather than asking ChatGPT about those resources in the abstract, a user can open the plugin from the sidebar and explore them there.
Across these examples, the extension’s role varies: it can keep selected design work available during implementation, bring meeting notes into a follow-up task, or provide a home for developer resources. In each case, the product interface remains part of the work rather than becoming a separate destination from the conversation.
Start with the user task, then build and refine
Ching says plugin extensions build on MCP and MCP apps, bringing a product’s tools and interface into the same conversation. His practical starting point is to choose something users need help with, build a first version using Plugin Creator, try it, and improve it.
The examples suggest what to look for in that first version: a task where people need to move between exploring an interface and asking ChatGPT for assistance, with relevant context preserved between the two. Users can then review the result before deciding what to do next.