runs the real CloudCannon app against local files, with no login, on one origin. This skill starts the local editing loop and hands it to the user.
Why: the server serves a directory and syncs source files; it does not run the SSG.
carries an editor save to disk, so the field shows the new text — but the preview renders the built output, and nothing regenerated it. The user sees their edit in the field and the old page beside it, with no error anywhere.
Then tell them to open
, and that Ctrl-C stops the server.
The preview reloads itself whenever the output directory changes, so a rebuild in a second terminal closes the loop with nothing else running. See dev-server-api.md § Events.
Default to manual. A watched rebuild after each save changes the output directory, and the preview then reloads the whole page. The editable regions' own in-place re-render is hidden behind that reload, so testing visual editing feels jarring. Manual also suits a slow build, or a post-build step that rewrites the whole output.
Offer watched when the user wants the preview to follow edits that editable regions don't re-render on their own: content edited in the source editor, data files, templates or styles.
MUST detect the build with the CLI rather than by looking for config files. cloudcannon configure detect-build-commands
is the product's own detection and covers every SSG the CLI knows.
MUST NOT keep a second detection table anywhere in this skill; it would drift from the CLI's. Take the command it suggests (
), not the bare SSG command — see
setup.md § Build commands.