---
name: dynostatic-integration
description: Build or convert an Astro or static website using a DynoStatic installation, or embed its published widgets. Use for editable CMS pages, source-managed translations, website-rendered forms, media delivery, and automatic publishing while preserving the site's design and hosting.
---

# Build with DynoStatic

Start with the installation URL, including its subfolder if present. Read its
`integration.php` and follow `agent.start` or `agent.guides.site-conversion`.
The installed manifest and guides are authoritative for that installation; this
skill does not require access to the DynoStatic source repository.

Resolve the relative links below against the installation root, never against the
origin alone. If an older manifest has no `agent` section, read `llms.txt` and the
available [CMS](docs/cms.md) and [Automation API](docs/automation-api.md) guides.
Do not infer support for newer actions from a newer skill.

## Website conversion

Read [Build a CMS website](docs/site-conversion.md), then follow this workflow:

1. Preserve current user edits, frontend design, routes, SEO, languages, media and
   dynamic handlers. Identify the actual repository, branch, host account and
   deployment mode. Do not substitute a starter for an existing site.
2. Discover the selected website through authenticated APIs. Content tokens read
   published build data; Automation tokens manage workspace resources. Discover
   the latter's capabilities before writing. Never request database credentials,
   application keys, admin cookies or provider secrets as routine integration input.
3. Map human-editable pages into Pages with content and SEO fields. Keep shared
   business/navigation data in shared resources. Preserve explicit ordering and
   native translation groups. Import through supported application operations,
   with revision preconditions and safe retries; never insert CMS rows directly.
4. Choose independent or [source-managed translations](docs/source-managed-translations.md).
   For source-managed content, edit the source and export/rewrite/import queued
   targets. Keep existing localized URLs and authored translations. Providers are
   not automatically connected. Use the existing visual/code editor for declared
   HTML fields, with the same supported formatting in the frontend.
5. Fetch current publications, all pages/locales and required media on every
   production build. Keep the `content:read` token in build secrets. Verify site
   identity and complete captures; fail on missing, stale or inconsistent inputs.
   An editing workspace or old publication capture does not refresh itself.
6. If the website owns form submissions, use [Website forms](docs/site-forms.md).
   Bundle one complete `cms.form` revision into both renderer and validator;
   retain the existing Worker, Turnstile and mail configuration. Follow Pages
   languages, finish queued translations, and reject stale browser revisions.
7. Choose media delivery explicitly: an embed uses its published media URLs;
   images downloaded, optimized and deployed with the site use the site's host.
   An embedded gallery does not automatically export its photos into a build.
8. Connect a build hook after bulk import, verify job delivery, and prove a real
   publish → fresh fetch → build → deployed change. For Cloudflare, read
   [Cloudflare website builds](docs/site-build-cloudflare.md). Build and runtime
   secrets are separate, and a hook does not provision repository hosting.

Verify representative desktop/mobile pages, locale/SEO parity, image output and
form failures with mocked delivery. Do not send contact messages as an incidental
test. Report CMS import, local build, live deployment and automatic publishing as
separate verified outcomes. Record unresolved configuration and conversion lessons
without credentials. Follow the user's existing deployment and backup authorization.

## Community deals and forums

For user-submitted deals or discussions, read the installed
[community publishing guide](docs/community-publishing.md) and discover
`integration.php` → `community`. Discover `automation.community.setup` with a
private website Automation token to provision its owner-only presets, then use
the installed setup script to publish Comments through ordinary change sets.
Keep `.secrets/` and `.local/` ignored. Use its Deals/Discussions presets, verified
contributor accounts, product imports and existing comments/voting. The
[Astro/Worker reference](examples/community-astro-worker/README.md) serves new
publications immediately and hands off to confirmed static builds. Keep all
community routes behind its visibility check and keep build credentials in the
separate dispatcher/CI. Follow the installed freshness, moderation and deployment
contracts rather than inventing another account or forum backend.

## Widget embedding

For a published widget, obtain its ULID and add this at the intended position:

```html
<div data-dynostatic-widget="WIDGET_ULID"></div>
```

Load the installation's `embed.js` once per document with `defer` and
`data-cfasync="false"`. Do not copy or bundle the loader unless the installation
owner maintains that fork. For Astro, keep the external script classic and inline:

```astro
<script is:inline data-cfasync="false" src="https://widgets.example.com/embed.js" defer></script>
```

The runtime handles `astro:page-load`, multiple widgets and inserted DOM. Use
`data-page-key` only when the canonical URL is not the desired stable comments
discussion key. Use `data-dynostatic-mode="light"` only when the host supplies the
complete [styling contract](docs/styling.md).

For origin errors, register the page's exact scheme/host/port under the selected
website's **Settings → Integrations**. Never weaken the check or use `Referer` as
a fallback. See the [integration guide](docs/integration.md).