# Install with AI Let an AI coding assistant do the integration for you. This works with any agent that can read a URL or a pasted file and edit your codebase — Claude Code, Cursor, Copilot, Windsurf, and the like. The machinery is a single file: an **agent playbook** at [`https://dailysmith.com/docs/agent/install-sdk.md`](https://dailysmith.com/docs/agent/install-sdk.md). It is the [JS SDK guide](/docs/install-sdk) rewritten for a machine executor: exact snippets, the decision points by framework, `curl` commands that validate your key and base path *before* any code is edited, and a verification checklist at the end. ## The prompt Paste this into your assistant, filling in your key: ``` Read https://dailysmith.com/docs/agent/install-sdk.md and follow it to install the baas studio blog on this website. Publishable key: pk_YOUR_KEY Blog base path: /blog ``` Your publishable key is on the site's page in the dashboard, and the base path is whatever the blog is configured to mount at (`/blog` unless you changed it). If you leave either out, the playbook tells the agent to stop and ask you rather than guess. :::callout{severity=info title="Agent can't fetch URLs?"} Open the [playbook](https://dailysmith.com/docs/agent/install-sdk.md) yourself — it's plain markdown — and paste its whole contents into the chat along with the prompt above. Same result. ::: Every docs page is also fetchable as raw markdown — append `.md` to its URL (e.g. [`/docs/install-sdk.md`](https://dailysmith.com/docs/install-sdk.md)), or start from the index at [`/docs/llms.txt`](https://dailysmith.com/docs/llms.txt). Rendered pages advertise their source via ``. ## What the agent will do ::::steps :::step[Validate before editing] It calls the delivery API with your key and base path. A wrong key, an unverified site, or a mismatched base path is caught here, with instructions on how to fix each — no code gets touched on a dead end. ::: :::step[Embed the SDK snippet] It adds the two-line container-plus-script snippet to the page at your base path, in whatever shape your stack wants — a static page, a Next.js or SvelteKit catch-all route, a CMS template. ::: :::step[Serve the shell everywhere] It configures your host so every URL under the base path returns that page — the step manual integrations most often miss — using your platform's rewrites (Netlify, Vercel, nginx, or the framework route itself). On a statically exported site it also makes your build emit absolute asset URLs, without which the bundle 404s on every post URL. ::: :::step[Style the blog into your design] The blog inherits your font and colours, but not your link treatment, your measure, or your heading scale. The playbook has it fix those against the site's own styles rather than leaving browser defaults. ::: :::step[Verify and report] It hard-loads a real post URL in a browser and checks the page actually booted — not just that HTML came back — then reports what changed, what it could not verify itself, and what's left for you (publishing posts). ::: :::: ## Is this safe? The integration only involves your **publishable** key (`pk_…`), which is public by design — it grants read access to your published posts and nothing else. The playbook explicitly instructs the agent to never request or handle secret keys, to keep the diff limited to the blog route, your routing config and the styles that fit the blog into your design, and to not commit or deploy without your approval. On a statically exported site it also has to flip one global build setting so assets resolve on deep URLs — the playbook requires it to call that out in its report. As with anything an agent writes, review the diff before you ship it.