Update to Forge
Snapshot Oct 29, 2026 · 19:11 UTC · version 1.0.4
Collection source: downloaded plugin package.
Instructions updated for forge-fragments
Skill instructions — Now says: used, and **files**: one tree of logos, PDFs, fonts or reference data. A collection with only skills is a design system; one with only fragments is a parts...
Observed in instructions or declared skills. Runtime behavior has not been tested.
Up to 10 plugins free · no card required.
All fields and original values.
Skill instructions
Oct 29, 2026 · 12:07 UTC
used. A collection with only skills is a design system; one with only fragments is a parts bin. project keeps agent skills, write each pulled skill to its `path` (`.agents/skills/<name>/SKILL.md`). - `skill_list`, `skill_get` and `...
Oct 29, 2026 · 19:11 UTC
used, and **files**: one tree of logos, PDFs, fonts or reference data. A collection with only skills is a design system; one with only fragments is a parts bin. project keeps agent skills, write each pulled skill as its whole `fold...
Compare saved observations
Download comparison JSONSKILL.md text changes
− removed · + added
--- before +++ after @@ -10,8 +10,9 @@ share every other file) and a **story** (the props and values its controls edit). Fragments are filed in **collections**. A collection or a workspace carries **skills**: SKILL.md rules that say how its fragments are meant to be -used. A collection with only skills is a design system; one with only -fragments is a parts bin. +used, and **files**: one tree of logos, PDFs, fonts or reference data. A +collection with only skills is a design system; one with only fragments is a +parts bin. The Forge MCP's own instructions carry the must-know; `fragment_docs` is the full reference (limits, tree rules, the story format, error codes). Read it @@ -46,14 +47,30 @@ 5. Adapt, do not paste: match the project's import aliases and styling entry, wire props to the story's values, keep the kit's tokens. Put `provenance.header` as the first line of the adapted entry file. If the - project keeps agent skills, write each pulled skill to its `path` - (`.agents/skills/<name>/SKILL.md`). + project keeps agent skills, write each pulled skill as its whole + `folder` at `folder.path` (`.agents/skills/<name>/`, named exactly the + skill): run `folder.tar.command` (it replaces the folder once the + download worked, so files a skill dropped do not linger), or write + `folder.markdown` as SKILL.md, curl each file url to its relative path + and `chmod +x` `scripts/`. +6. Never write one skill over another. Skills that share a name come back + in `skillCollisions`, and a folder whose SKILL.md has no + `metadata.forge-skill-id`, or a different one, is another skill (or the + user's own): ask the user which to keep. A hit that belongs to a collection is usually one part of a kit: `fragment_collection_get { collectionId }` lists its siblings, which the same skills govern. A share link `/share/collection/<id>` names a collection; read it the same way. +Find, pull and `fragment_collection_get` also list the **files** kept beside +the fragments (`fileTrees`: paths, mime, size). They are context: read one +with `file_get` (text inline, or a signed url), write a whole tree to disk +with `files_pull`, search with `files_find`. A fragment never links to a +collection file — copy the file into the fragment when it needs one. +`file_save` adds a file (inline, or through the upload url it answers +without content). + ## Create or edit a fragment (needs a shell) 1. Call `fragment_start_session` first, before drafting anything: @@ -112,9 +129,13 @@ tidy. Reuse an existing collection before creating a near-duplicate. - `fragment_remix` copies one fragment into a workspace; `fragment_collection_remix` copies a whole kit with its skills. -- `skill_list`, `skill_get` and `skill_save` manage skills. Write one when the - user states rules a kit must follow: short, imperative, naming what never - to do. +- `skill_list`, `skill_get` and `skill_save` manage skills. A skill is a + folder: SKILL.md plus files under `scripts/`, `references/` and `assets/` + that it links to by relative path. `skill_get` answers SKILL.md as + `markdown` and every file (text inline, binary by url); `skill_save` takes `files` (`{ path, content }` + or `{ path, contentBase64 }`) and `removeFiles`. Write one when the user + states rules a kit must follow: a short, imperative SKILL.md naming what + never to do, with long reference material in `references/`. ## Ask first
Full technical diff · 1 changed fields
changed /skill_md_contents
"---\nname: forge-fragments\ndescription: Use Forge Fragments (hosted React components with variants, collections and skills) through the Forge MCP. Use when the user mentions Forge, a fragment, a Forge collection or kit, a ui8.dev page, or a forge.ui8.ai share link; when they want to find, preview, publish, remix or organize UI they keep in Forge; when they ask about feedback on a fragment; and in a code project before building a piece of UI they may already have in Forge. Not for general UI questions with no Forge workspace involved.\n---\n\n# Forge Fragments\n\nA **fragment** is a small React project hosted in Forge Cloud: Vite-shaped,\npreviewed live at a URL, with one or more **variants** (named entry files that\nshare every other file) and a **story** (the props and values its controls\nedit). Fragments are filed in **collections**. A collection or a workspace\ncarries **skills**: SKILL.md rules that say how its fragments are meant to be\nused. A collection with only skills is a design system; one with only\nfragments is a parts bin.\n\nThe Forge MCP's own instructions carry the must-know; `fragment_docs` is the\nfull reference (limits, tree rules, the story format, error codes). Read it\nwhen a detail here is not enough.\n\n## Where you are decides what you can do\n\n- **Codex, or any agent with a shell and a filesystem**: every flow below.\n- **ChatGPT (no local shell)**: find, preview, publish, feedback, organize,\n remix and skills. Do not call `fragment_start_session` or `fragment_pull`\n there: an edit session needs you to run its download and upload commands,\n and a pull needs a project to write files into. When the user asks to\n create or change a fragment's code in ChatGPT, say that it needs Codex or\n another coding agent connected to Forge, and offer what you can do here\n (find a similar fragment, preview it, remix it, or edit its description,\n tags and variant values).\n\n## Use a fragment in the project you are in\n\nDo this before building any piece of UI the user might already keep in Forge.\n\n1. `fragment_find { intent, project? }`. Say what you are about to build in\n your own words; pass `project` facts (framework, styling, dependencies)\n when you know them. Follow the `next` line it returns.\n2. If `gate.fits` is false, nothing fits: build it yourself, still following\n the `relevant` skills.\n3. `skill_get { skillId }` for every skill listed. Read them before touching\n code: they hold the tokens, spacing, naming and what never to do.\n4. `fragment_pull { fragmentId, variant? }`. It returns the files inline (or a\n tar URL and command for a large tree), signed asset URLs (curl them; they\n expire in an hour), dependencies, the story and the governing skills.\n5. Adapt, do not paste: match the project's import aliases and styling\n entry, wire props to the story's values, keep the kit's tokens. Put\n `provenance.header` as the first line of the adapted entry file. If the\n project keeps agent skills, write each pulled skill to its `path`\n (`.agents/skills/<name>/SKILL.md`).\n\nA hit that belongs to a collection is usually one part of a kit:\n`fragment_collection_get { collectionId }` lists its siblings, which the same\nskills govern. A share link `/share/collection/<id>` names a collection; read\nit the same way.\n\n## Create or edit a fragment (needs a shell)\n\n1. Call `fragment_start_session` first, before drafting anything:\n `{ fragmentId }` to edit, or `{ name, description, tags, collectionId? }`\n to create. Give the user its `shellUrl` right away; that page shows the\n live preview while you work.\n2. Run `download.command` (optional for a new fragment), edit under\n `workdir`, then run `upload.command` exactly as returned.\n3. `fragment_submit { fragmentId, sessionId, deleted? }`. Only changed files\n are written. Give the user `shellUrl`, never `previewUrl`.\n4. Check `fragment_feedback_list { fragmentId }` when you start and after you\n submit.\n\nNever put file contents in a tool argument; no tool accepts them. The server\nowns `index.html`, `src/main.tsx`, `tsconfig.json`, `vite.config.*` and\nlockfiles and ignores them on upload. Variants live at\n`src/variants/<slug>.tsx` with a default export; dependencies go in\n`package.json` (served through esm.sh; React is provided); Tailwind v4 goes in\n`index.css`. A session lasts a limited time: on `session_expired`, start a\nnew one.\n\nVariant metadata (name, story, values) is not code: change it with\n`fragment_save_variant`, which works in ChatGPT too.\n\n## Preview\n\n`fragment_preview { fragmentId, variant? }` when the user wants to see a\nfragment. In ChatGPT the result renders as a live preview card with a variant\nswitcher and an \"Open in Forge\" button, so do not repeat the links under it.\nElsewhere, give the user `shellUrl`. The raw `url` is for your own checks\nonly; never hand it to the user.\n\n## Publish\n\n`fragment_publish { fragmentId, slug?, password? }` serves a pinned snapshot\nat `https://<slug>.ui8.dev/`; later edits stay private until the next\npublish. `fragment_set_password` changes the password on a live page without\nrepublishing; `fragment_unpublish` takes the page down and keeps the slug.\n\n## Feedback\n\nPeople leave comments, proposed style edits and screenshots on a fragment's\npreview. `fragment_feedback_list { fragmentId, status? }` returns the open\nitems with their anchors (selector, text, component chain) and threads.\nAnswer with `fragment_feedback_reply { fragmentId, feedbackId, body }`: short,\nsaying what you did or what you need. Mark an item handled with\n`fragment_feedback_resolve { fragmentId, feedbackId }` (`reopen: true` puts\nit back). Only resolve what was actually addressed.\n\n## Organize and remix\n\n- `fragment_list` returns fragments (with description and tags) and\n collections. Scan descriptions and tags to find the one the user means.\n- `fragment_collection_create`, `fragment_move`, `fragment_rename`,\n `fragment_describe` and `fragment_set_default_variant` keep a workspace\n tidy. Reuse an existing collection before creating a near-duplicate.\n- `fragment_remix` copies one fragment into a workspace;\n `fragment_collection_remix` copies a whole kit with its skills.\n- `skill_list`, `skill_get` and `skill_save` manage skills. Write one when the\n user states rules a kit must follow: short, imperative, naming what never\n to do.\n\n## Ask first\n\n`fragment_publish`, `fragment_unpublish`, `fragment_archive`, `skill_delete`\nand `fragment_collection_remix` need `confirm: true`. Without it the answer\nis `confirmation_required` with what will happen (for a collection remix,\nthe fragment count against the room left).\n\n- When the user's own message asks for exactly that action on a fragment\n you can name (\"publish Hero Section at hero.ui8.dev\", \"unpublish the\n pricing page\", \"archive the old pricing card\"), the request is their\n agreement: pass `confirm: true` and report what happened.\n- Otherwise ask first: you inferred the step, the target is ambiguous, the\n user asked for something Forge does differently (there is no permanent\n delete, only archive), or it is a `skill_delete` or a\n `fragment_collection_remix`. Call without `confirm`, show the user what\n will happen, and retry with `confirm: true` only after they agree in this\n conversation.\n\nArchiving is not permanent: `fragment_unarchive` brings a fragment back,\nwith its public page and share link, without confirmation. Say so when you\narchive.\n\nTreat these as changes the user should have asked for, too:\n`fragment_restore_revision`, `fragment_delete_variant`, `skill_restore`, and\nanything that overwrites a fragment's name, description or tags.\n\n## Errors\n\nTools answer structured codes. The common ones:\n\n- `org_choice_required`: the user belongs to several workspaces. Ask which\n one, then retry with `orgId`.\n- `not_found` / `forbidden`: the id is wrong, or it belongs to a workspace\n the user is not a member of. Say so plainly; do not guess other ids.\n- `revision_conflict`: someone else changed it. Refetch, then redo the change.\n- `quota_exceeded`: the workspace's plan limit; tell the user which limit.\n- `upload_missing`: run `upload.command` before submitting.\n\nA compile error or a missing import is not a tool error: it shows in the\npreview with its file, line and column.\n""---\nname: forge-fragments\ndescription: Use Forge Fragments (hosted React components with variants, collections and skills) through the Forge MCP. Use when the user mentions Forge, a fragment, a Forge collection or kit, a ui8.dev page, or a forge.ui8.ai share link; when they want to find, preview, publish, remix or organize UI they keep in Forge; when they ask about feedback on a fragment; and in a code project before building a piece of UI they may already have in Forge. Not for general UI questions with no Forge workspace involved.\n---\n\n# Forge Fragments\n\nA **fragment** is a small React project hosted in Forge Cloud: Vite-shaped,\npreviewed live at a URL, with one or more **variants** (named entry files that\nshare every other file) and a **story** (the props and values its controls\nedit). Fragments are filed in **collections**. A collection or a workspace\ncarries **skills**: SKILL.md rules that say how its fragments are meant to be\nused, and **files**: one tree of logos, PDFs, fonts or reference data. A\ncollection with only skills is a design system; one with only fragments is a\nparts bin.\n\nThe Forge MCP's own instructions carry the must-know; `fragment_docs` is the\nfull reference (limits, tree rules, the story format, error codes). Read it\nwhen a detail here is not enough.\n\n## Where you are decides what you can do\n\n- **Codex, or any agent with a shell and a filesystem**: every flow below.\n- **ChatGPT (no local shell)**: find, preview, publish, feedback, organize,\n remix and skills. Do not call `fragment_start_session` or `fragment_pull`\n there: an edit session needs you to run its download and upload commands,\n and a pull needs a project to write files into. When the user asks to\n create or change a fragment's code in ChatGPT, say that it needs Codex or\n another coding agent connected to Forge, and offer what you can do here\n (find a similar fragment, preview it, remix it, or edit its description,\n tags and variant values).\n\n## Use a fragment in the project you are in\n\nDo this before building any piece of UI the user might already keep in Forge.\n\n1. `fragment_find { intent, project? }`. Say what you are about to build in\n your own words; pass `project` facts (framework, styling, dependencies)\n when you know them. Follow the `next` line it returns.\n2. If `gate.fits` is false, nothing fits: build it yourself, still following\n the `relevant` skills.\n3. `skill_get { skillId }` for every skill listed. Read them before touching\n code: they hold the tokens, spacing, naming and what never to do.\n4. `fragment_pull { fragmentId, variant? }`. It returns the files inline (or a\n tar URL and command for a large tree), signed asset URLs (curl them; they\n expire in an hour), dependencies, the story and the governing skills.\n5. Adapt, do not paste: match the project's import aliases and styling\n entry, wire props to the story's values, keep the kit's tokens. Put\n `provenance.header` as the first line of the adapted entry file. If the\n project keeps agent skills, write each pulled skill as its whole\n `folder` at `folder.path` (`.agents/skills/<name>/`, named exactly the\n skill): run `folder.tar.command` (it replaces the folder once the\n download worked, so files a skill dropped do not linger), or write\n `folder.markdown` as SKILL.md, curl each file url to its relative path\n and `chmod +x` `scripts/`.\n6. Never write one skill over another. Skills that share a name come back\n in `skillCollisions`, and a folder whose SKILL.md has no\n `metadata.forge-skill-id`, or a different one, is another skill (or the\n user's own): ask the user which to keep.\n\nA hit that belongs to a collection is usually one part of a kit:\n`fragment_collection_get { collectionId }` lists its siblings, which the same\nskills govern. A share link `/share/collection/<id>` names a collection; read\nit the same way.\n\nFind, pull and `fragment_collection_get` also list the **files** kept beside\nthe fragments (`fileTrees`: paths, mime, size). They are context: read one\nwith `file_get` (text inline, or a signed url), write a whole tree to disk\nwith `files_pull`, search with `files_find`. A fragment never links to a\ncollection file — copy the file into the fragment when it needs one.\n`file_save` adds a file (inline, or through the upload url it answers\nwithout content).\n\n## Create or edit a fragment (needs a shell)\n\n1. Call `fragment_start_session` first, before drafting anything:\n `{ fragmentId }` to edit, or `{ name, description, tags, collectionId? }`\n to create. Give the user its `shellUrl` right away; that page shows the\n live preview while you work.\n2. Run `download.command` (optional for a new fragment), edit under\n `workdir`, then run `upload.command` exactly as returned.\n3. `fragment_submit { fragmentId, sessionId, deleted? }`. Only changed files\n are written. Give the user `shellUrl`, never `previewUrl`.\n4. Check `fragment_feedback_list { fragmentId }` when you start and after you\n submit.\n\nNever put file contents in a tool argument; no tool accepts them. The server\nowns `index.html`, `src/main.tsx`, `tsconfig.json`, `vite.config.*` and\nlockfiles and ignores them on upload. Variants live at\n`src/variants/<slug>.tsx` with a default export; dependencies go in\n`package.json` (served through esm.sh; React is provided); Tailwind v4 goes in\n`index.css`. A session lasts a limited time: on `session_expired`, start a\nnew one.\n\nVariant metadata (name, story, values) is not code: change it with\n`fragment_save_variant`, which works in ChatGPT too.\n\n## Preview\n\n`fragment_preview { fragmentId, variant? }` when the user wants to see a\nfragment. In ChatGPT the result renders as a live preview card with a variant\nswitcher and an \"Open in Forge\" button, so do not repeat the links under it.\nElsewhere, give the user `shellUrl`. The raw `url` is for your own checks\nonly; never hand it to the user.\n\n## Publish\n\n`fragment_publish { fragmentId, slug?, password? }` serves a pinned snapshot\nat `https://<slug>.ui8.dev/`; later edits stay private until the next\npublish. `fragment_set_password` changes the password on a live page without\nrepublishing; `fragment_unpublish` takes the page down and keeps the slug.\n\n## Feedback\n\nPeople leave comments, proposed style edits and screenshots on a fragment's\npreview. `fragment_feedback_list { fragmentId, status? }` returns the open\nitems with their anchors (selector, text, component chain) and threads.\nAnswer with `fragment_feedback_reply { fragmentId, feedbackId, body }`: short,\nsaying what you did or what you need. Mark an item handled with\n`fragment_feedback_resolve { fragmentId, feedbackId }` (`reopen: true` puts\nit back). Only resolve what was actually addressed.\n\n## Organize and remix\n\n- `fragment_list` returns fragments (with description and tags) and\n collections. Scan descriptions and tags to find the one the user means.\n- `fragment_collection_create`, `fragment_move`, `fragment_rename`,\n `fragment_describe` and `fragment_set_default_variant` keep a workspace\n tidy. Reuse an existing collection before creating a near-duplicate.\n- `fragment_remix` copies one fragment into a workspace;\n `fragment_collection_remix` copies a whole kit with its skills.\n- `skill_list`, `skill_get` and `skill_save` manage skills. A skill is a\n folder: SKILL.md plus files under `scripts/`, `references/` and `assets/`\n that it links to by relative path. `skill_get` answers SKILL.md as\n `markdown` and every file (text inline, binary by url); `skill_save` takes `files` (`{ path, content }`\n or `{ path, contentBase64 }`) and `removeFiles`. Write one when the user\n states rules a kit must follow: a short, imperative SKILL.md naming what\n never to do, with long reference material in `references/`.\n\n## Ask first\n\n`fragment_publish`, `fragment_unpublish`, `fragment_archive`, `skill_delete`\nand `fragment_collection_remix` need `confirm: true`. Without it the answer\nis `confirmation_required` with what will happen (for a collection remix,\nthe fragment count against the room left).\n\n- When the user's own message asks for exactly that action on a fragment\n you can name (\"publish Hero Section at hero.ui8.dev\", \"unpublish the\n pricing page\", \"archive the old pricing card\"), the request is their\n agreement: pass `confirm: true` and report what happened.\n- Otherwise ask first: you inferred the step, the target is ambiguous, the\n user asked for something Forge does differently (there is no permanent\n delete, only archive), or it is a `skill_delete` or a\n `fragment_collection_remix`. Call without `confirm`, show the user what\n will happen, and retry with `confirm: true` only after they agree in this\n conversation.\n\nArchiving is not permanent: `fragment_unarchive` brings a fragment back,\nwith its public page and share link, without confirmation. Say so when you\narchive.\n\nTreat these as changes the user should have asked for, too:\n`fragment_restore_revision`, `fragment_delete_variant`, `skill_restore`, and\nanything that overwrites a fragment's name, description or tags.\n\n## Errors\n\nTools answer structured codes. The common ones:\n\n- `org_choice_required`: the user belongs to several workspaces. Ask which\n one, then retry with `orgId`.\n- `not_found` / `forbidden`: the id is wrong, or it belongs to a workspace\n the user is not a member of. Say so plainly; do not guess other ids.\n- `revision_conflict`: someone else changed it. Refetch, then redo the change.\n- `quota_exceeded`: the workspace's plan limit; tell the user which limit.\n- `upload_missing`: run `upload.command` before submitting.\n\nA compile error or a missing import is not a tool error: it shows in the\npreview with its file, line and column.\n"Full snapshot data
{
"description": "Use Forge Fragments (hosted React components with variants, collections and skills) through the Forge MCP. Use when the user mentions Forge, a fragment, a Forge collection or kit, a ui8.dev page, or a forge.ui8.ai share link; when they want to find, preview, publish, remix or organize UI they keep in Forge; when they ask about feedback on a fragment; and in a code project before building a piece of UI they may already have in Forge. Not for general UI questions with no Forge workspace involved.",
"included_files": [],
"name": "forge-fragments",
"skill_md_contents": "---\nname: forge-fragments\ndescription: Use Forge Fragments (hosted React components with variants, collections and skills) through the Forge MCP. Use when the user mentions Forge, a fragment, a Forge collection or kit, a ui8.dev page, or a forge.ui8.ai share link; when they want to find, preview, publish, remix or organize UI they keep in Forge; when they ask about feedback on a fragment; and in a code project before building a piece of UI they may already have in Forge. Not for general UI questions with no Forge workspace involved.\n---\n\n# Forge Fragments\n\nA **fragment** is a small React project hosted in Forge Cloud: Vite-shaped,\npreviewed live at a URL, with one or more **variants** (named entry files that\nshare every other file) and a **story** (the props and values its controls\nedit). Fragments are filed in **collections**. A collection or a workspace\ncarries **skills**: SKILL.md rules that say how its fragments are meant to be\nused, and **files**: one tree of logos, PDFs, fonts or reference data. A\ncollection with only skills is a design system; one with only fragments is a\nparts bin.\n\nThe Forge MCP's own instructions carry the must-know; `fragment_docs` is the\nfull reference (limits, tree rules, the story format, error codes). Read it\nwhen a detail here is not enough.\n\n## Where you are decides what you can do\n\n- **Codex, or any agent with a shell and a filesystem**: every flow below.\n- **ChatGPT (no local shell)**: find, preview, publish, feedback, organize,\n remix and skills. Do not call `fragment_start_session` or `fragment_pull`\n there: an edit session needs you to run its download and upload commands,\n and a pull needs a project to write files into. When the user asks to\n create or change a fragment's code in ChatGPT, say that it needs Codex or\n another coding agent connected to Forge, and offer what you can do here\n (find a similar fragment, preview it, remix it, or edit its description,\n tags and variant values).\n\n## Use a fragment in the project you are in\n\nDo this before building any piece of UI the user might already keep in Forge.\n\n1. `fragment_find { intent, project? }`. Say what you are about to build in\n your own words; pass `project` facts (framework, styling, dependencies)\n when you know them. Follow the `next` line it returns.\n2. If `gate.fits` is false, nothing fits: build it yourself, still following\n the `relevant` skills.\n3. `skill_get { skillId }` for every skill listed. Read them before touching\n code: they hold the tokens, spacing, naming and what never to do.\n4. `fragment_pull { fragmentId, variant? }`. It returns the files inline (or a\n tar URL and command for a large tree), signed asset URLs (curl them; they\n expire in an hour), dependencies, the story and the governing skills.\n5. Adapt, do not paste: match the project's import aliases and styling\n entry, wire props to the story's values, keep the kit's tokens. Put\n `provenance.header` as the first line of the adapted entry file. If the\n project keeps agent skills, write each pulled skill as its whole\n `folder` at `folder.path` (`.agents/skills/<name>/`, named exactly the\n skill): run `folder.tar.command` (it replaces the folder once the\n download worked, so files a skill dropped do not linger), or write\n `folder.markdown` as SKILL.md, curl each file url to its relative path\n and `chmod +x` `scripts/`.\n6. Never write one skill over another. Skills that share a name come back\n in `skillCollisions`, and a folder whose SKILL.md has no\n `metadata.forge-skill-id`, or a different one, is another skill (or the\n user's own): ask the user which to keep.\n\nA hit that belongs to a collection is usually one part of a kit:\n`fragment_collection_get { collectionId }` lists its siblings, which the same\nskills govern. A share link `/share/collection/<id>` names a collection; read\nit the same way.\n\nFind, pull and `fragment_collection_get` also list the **files** kept beside\nthe fragments (`fileTrees`: paths, mime, size). They are context: read one\nwith `file_get` (text inline, or a signed url), write a whole tree to disk\nwith `files_pull`, search with `files_find`. A fragment never links to a\ncollection file — copy the file into the fragment when it needs one.\n`file_save` adds a file (inline, or through the upload url it answers\nwithout content).\n\n## Create or edit a fragment (needs a shell)\n\n1. Call `fragment_start_session` first, before drafting anything:\n `{ fragmentId }` to edit, or `{ name, description, tags, collectionId? }`\n to create. Give the user its `shellUrl` right away; that page shows the\n live preview while you work.\n2. Run `download.command` (optional for a new fragment), edit under\n `workdir`, then run `upload.command` exactly as returned.\n3. `fragment_submit { fragmentId, sessionId, deleted? }`. Only changed files\n are written. Give the user `shellUrl`, never `previewUrl`.\n4. Check `fragment_feedback_list { fragmentId }` when you start and after you\n submit.\n\nNever put file contents in a tool argument; no tool accepts them. The server\nowns `index.html`, `src/main.tsx`, `tsconfig.json`, `vite.config.*` and\nlockfiles and ignores them on upload. Variants live at\n`src/variants/<slug>.tsx` with a default export; dependencies go in\n`package.json` (served through esm.sh; React is provided); Tailwind v4 goes in\n`index.css`. A session lasts a limited time: on `session_expired`, start a\nnew one.\n\nVariant metadata (name, story, values) is not code: change it with\n`fragment_save_variant`, which works in ChatGPT too.\n\n## Preview\n\n`fragment_preview { fragmentId, variant? }` when the user wants to see a\nfragment. In ChatGPT the result renders as a live preview card with a variant\nswitcher and an \"Open in Forge\" button, so do not repeat the links under it.\nElsewhere, give the user `shellUrl`. The raw `url` is for your own checks\nonly; never hand it to the user.\n\n## Publish\n\n`fragment_publish { fragmentId, slug?, password? }` serves a pinned snapshot\nat `https://<slug>.ui8.dev/`; later edits stay private until the next\npublish. `fragment_set_password` changes the password on a live page without\nrepublishing; `fragment_unpublish` takes the page down and keeps the slug.\n\n## Feedback\n\nPeople leave comments, proposed style edits and screenshots on a fragment's\npreview. `fragment_feedback_list { fragmentId, status? }` returns the open\nitems with their anchors (selector, text, component chain) and threads.\nAnswer with `fragment_feedback_reply { fragmentId, feedbackId, body }`: short,\nsaying what you did or what you need. Mark an item handled with\n`fragment_feedback_resolve { fragmentId, feedbackId }` (`reopen: true` puts\nit back). Only resolve what was actually addressed.\n\n## Organize and remix\n\n- `fragment_list` returns fragments (with description and tags) and\n collections. Scan descriptions and tags to find the one the user means.\n- `fragment_collection_create`, `fragment_move`, `fragment_rename`,\n `fragment_describe` and `fragment_set_default_variant` keep a workspace\n tidy. Reuse an existing collection before creating a near-duplicate.\n- `fragment_remix` copies one fragment into a workspace;\n `fragment_collection_remix` copies a whole kit with its skills.\n- `skill_list`, `skill_get` and `skill_save` manage skills. A skill is a\n folder: SKILL.md plus files under `scripts/`, `references/` and `assets/`\n that it links to by relative path. `skill_get` answers SKILL.md as\n `markdown` and every file (text inline, binary by url); `skill_save` takes `files` (`{ path, content }`\n or `{ path, contentBase64 }`) and `removeFiles`. Write one when the user\n states rules a kit must follow: a short, imperative SKILL.md naming what\n never to do, with long reference material in `references/`.\n\n## Ask first\n\n`fragment_publish`, `fragment_unpublish`, `fragment_archive`, `skill_delete`\nand `fragment_collection_remix` need `confirm: true`. Without it the answer\nis `confirmation_required` with what will happen (for a collection remix,\nthe fragment count against the room left).\n\n- When the user's own message asks for exactly that action on a fragment\n you can name (\"publish Hero Section at hero.ui8.dev\", \"unpublish the\n pricing page\", \"archive the old pricing card\"), the request is their\n agreement: pass `confirm: true` and report what happened.\n- Otherwise ask first: you inferred the step, the target is ambiguous, the\n user asked for something Forge does differently (there is no permanent\n delete, only archive), or it is a `skill_delete` or a\n `fragment_collection_remix`. Call without `confirm`, show the user what\n will happen, and retry with `confirm: true` only after they agree in this\n conversation.\n\nArchiving is not permanent: `fragment_unarchive` brings a fragment back,\nwith its public page and share link, without confirmation. Say so when you\narchive.\n\nTreat these as changes the user should have asked for, too:\n`fragment_restore_revision`, `fragment_delete_variant`, `skill_restore`, and\nanything that overwrites a fragment's name, description or tags.\n\n## Errors\n\nTools answer structured codes. The common ones:\n\n- `org_choice_required`: the user belongs to several workspaces. Ask which\n one, then retry with `orgId`.\n- `not_found` / `forbidden`: the id is wrong, or it belongs to a workspace\n the user is not a member of. Say so plainly; do not guess other ids.\n- `revision_conflict`: someone else changed it. Refetch, then redo the change.\n- `quota_exceeded`: the workspace's plan limit; tell the user which limit.\n- `upload_missing`: run `upload.command` before submitting.\n\nA compile error or a missing import is not a tool error: it shows in the\npreview with its file, line and column.\n"
}SHA-256 of public snapshot: aed04f904e4daf7fae2324916d97df6ca43bfe7b7aca00bbd1781c560d5d7fcb