docs(skills): add Bolt install steps to the Agent Skills pages - #427
Merged
Conversation
Bolt imports Agent Skills from a public GitHub repo, so the Scandit plugin can be installed there without a terminal. Add it to the per-agent install picker under a new 'AI app builders' group, gated to Web since these platforms only generate web apps. The picker entries gain an optional framework filter, an optgroup label and a link to the platform's own instructions. Verified in the Bolt UI: the repo URL plus the skill-folder dropdown imports a single skill. Lovable and Replit were tested and left out for now — Lovable rejects the repo (its GitHub import applies a 200-file limit to the whole repository before scoping to the linked skill folder), and our skills are not discoverable in Replit's Discover pane yet.
|
The select's value read agentKey, which is seeded from the unfiltered AGENT_INSTALLS and never reset when the framework prop changes, so it could name an entry agentInstallsFor() had filtered out. The panel below already rendered from the clamped `agent`, so the two could disagree: blank select, Claude Code's steps. Unreachable today only because AGENT_INSTALLS[0] has no frameworks and each framework is its own page. Reading agent.key makes the invariant hold by construction.
eugenia-scandit
added a commit
that referenced
this pull request
Aug 24, 2026
…t it Two gaps left by the registry refactor, both the same shape as the bug it fixed: a framework name that resolves to nothing, with no error. 1. THE REGISTRY WAS RUNTIME-ONLY. `slug: string` meant verify:frameworks guarded the frontmatter and the schema, but nothing guarded code. A component writing `frameworks: ['Web']` for `['web']` compiled fine and then matched no framework - exactly how `netIos` and `react` got into the frontmatter. `FrameworkSlug` closes that: 4 typo cases that used to compile are now errors, with "Did you mean" suggestions. The union is spelled out rather than derived. Deriving it needs `as const`, which turns FRAMEWORKS into 13 exact tuple members and drops the optional `aliases` / `unreleased` keys from the entries that omit them - `f.aliases` and `f.unreleased` stop typechecking. Verified: that route fails `tsc` in two consumers. So the union is a second copy, guarded the way the schema enum already is, by a new three-way check (union / registry / enum, every pair both directions). 2. products.json AND features.json WERE OUTSIDE THE REGISTRY. Both state per-framework availability keyed by DISPLAY name, so the slug enum cannot see them - a second vocabulary, unverified. It had already drifted. features.json carried `.Net iOS` and `.Net Android` against the registry's `.NET iOS` / `.NET Android`, 16 keys each. Nothing matched them: FeatureList looks up `feature.frameworks[currentFramework]` with a display name from the registry, so those 32 rows were unreachable. 32 keys normalized; the new DATA check keeps the two files inside the vocabulary. The check is one-directional on purpose: a product need not support every framework, so a registry display missing from a data file is fine. Only a name the registry does not know is an error. UNRELEASED_FRAMEWORK_SLUGS is annotated `string[]` explicitly. It is a membership-test array queried with raw route segments; narrowing it to FrameworkSlug makes `.includes(someString)` an error at its call site. Both new checks verified in both directions: - pre-fix features.json -> exit 1, naming both bad keys; post-fix exit 0 - union with `linux` renamed -> exit 1, reporting the extra and the missing Gates green: verify:frameworks, test:frameworks (9), tsc --noEmit. Unblocks #427, which adds `frameworks?: string[]` to AgentInstall - a sixth copy of the vocabulary landing just as this PR removes five. It can now import FrameworkSlug instead. Not fixed here, needs its own change: FeatureList derives the framework from `/sdks/([^/]+)/`, which yields `net` for /sdks/net/ios/ and matches no entry, so the feature table is empty on both .NET frameworks regardless of this normalization. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
moritzhartmeier
approved these changes
Aug 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds Bolt to the per-agent install picker on the Agent Skills pages, under a new AI app builders group.
Bolt imports Agent Skills straight from a public GitHub repo, so people building there can install the Scandit skills without a terminal —
npx plugins add scandit/skillsis useless to them. The steps are:Verified by hand in the Bolt UI: pasting
https://github.com/scandit/skillspopulates the Skill folder name dropdown and imports the selected skill.Changes
SkillsCallout/agents.tsx— Bolt entry, plus three new optional fields onAgentInstall:group(optgroup in the picker),frameworks(which framework pages offer the entry) anddocs(link to the platform's own instructions).SkillsCallout/ManualInstall.tsx— filters entries by framework, renders optgroups when any grouped entry applies, and shows the docs link.SkillsPage/index.tsx+styles.module.css— a pointer under the one-command install ("Building in an AI app builder instead? The same skills import straight from GitHub into Bolt"), and a reworded manual-install intro. Both are derived from the entries, so they stay correct as builders are added or removed.Gated to Web: these platforms only generate web apps, so nothing changes on the iOS, Android, Flutter, React Native, Cordova, Capacitor, KMP or .NET pages.
Platforms tested and left out
scandit/skills(973 files) is rejected with "ZIP file contains too many files". The repo root URL, the documentedtree/<branch>/skills/<slug>form and uploading GitHub's repo zip all fail. A hand-built zip of a single skill folder (SKILL.md at the root +references/) imports fine via the Archive tab, so the fix on our side would be publishing per-skill zips as release assets inscandit/skills— or per-skill orphan branches, if we want a paste-a-URL flow. Reported to Lovable support.Both re-add as a single entry in
AGENT_INSTALLSonce they work.Verification
yarn typecheck,yarn buildand cspell all pass. Checked the built HTML: the Web page renders the new group and copy, and no other framework page is affected.