StackBlitz Embed Integration
Overview
This skill selects and implements the supported SDK method for an existing StackBlitz project, a public GitHub path, or an inline project. It treats the embed as third-party executable content with explicit loading, persistence, accessibility, and browser-support boundaries.
Prerequisites
- A named host page and the source of the project to embed
- Confirmation that source code is public and safe to send to or execute through StackBlitz
- A static fallback and intended responsive behavior
Tool Discipline
Use Read, Glob, and Grep to inspect the host component, content source, CSP, existing third-party scripts, and responsive patterns. Use WebFetch only for current official StackBlitz documentation. Use Write or Edit after the embed source and trust boundary are confirmed.
Current Contract
- Use
embedProjectIdfor an existing StackBlitz project,embedGithubProjectfor a public GitHub repository/path, andembedProjectfor a generated inline project. - Inline projects live in browser memory unless a user forks them into a StackBlitz account; do not promise automatic persistence.
- Use current
EmbedOptions; do not depend on deprecatedforceEmbedLayoutbehavior. clickToLoadis a useful consent/performance boundary for expensive or numerous embeds.- Treat the returned VM instance as an integration capability with an explicit owner and disposal path.
- WebContainer-based embeds have stricter browser constraints than static code fallbacks.
Authentication
Do not embed private repositories, secrets, licensed source, or authenticated application state through a public project method. If enterprise origin or private access is required, stop and obtain the documented organization configuration and security approval.
Workflow
- Inspect the host page, choose the authoritative project source, and classify its sensitivity.
- Select one SDK method and a pinned SDK version from the repository lockfile.
- Define height, view, theme,
openFile, andclickToLoadfrom the user journey; avoid deprecated options. - Add a titled container, loading state, error state, and accessible static link or code fallback.
- Reconcile CSP, privacy disclosure, responsive layout, and browser support with the site owner.
- Test initial load, user-triggered load, failure, keyboard flow, narrow viewport, and navigation cleanup.
Approval Boundaries
Require explicit authorization before adding a third-party executable embed, changing CSP, loading private code, selecting an enterprise origin, or adding analytics. Show the data/source flow and fallback before deployment.
Output
Return the selected source and SDK method, package/version evidence, embed options, trust and persistence semantics, accessibility/fallback behavior, tests run, changed files, rollout, and rollback.
Error Handling
| Condition | Response |
|---|---|
| GitHub project cannot load | Verify the public repository, branch/tag/commit, and optional subfolder path. |
| Inline work disappears | Explain browser-memory semantics and offer an explicit fork/export path. |
| Embed breaks narrow layouts | Use a responsive container and preserve the static fallback. |
| Host CSP blocks the embed | Propose the narrow official origins; never disable CSP wholesale. |
Examples
Given a public tutorial repository pinned to a commit, add a click-to-load embed opening the relevant file and provide a normal GitHub link plus static code sample when the runtime cannot load.