Update to Simple Host

{
  "description": "Plan a website on Simple Host before building it. Use when the person has an idea for a site or web tool but has not settled what it should do, asks whether Simple Host can handle bookings, forms, accounts, payments, a database, private pages or server code, or wants to know what to build with Simple Host KV, SQLite or files. Explains who can read and write what, then hands implementation to website-deploy.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 215
    },
    {
      "relative_path": "references/capabilities.md",
      "size_in_bytes": 8425
    },
    {
      "relative_path": "references/handoff-and-examples.md",
      "size_in_bytes": 10490
    }
  ],
  "name": "website-deploy-builder",
  "skill_md_contents": "---\nname: website-deploy-builder\ndescription: Plan a website on Simple Host before building it. Use when the person has an idea for a site or web tool but has not settled what it should do, asks whether Simple Host can handle bookings, forms, accounts, payments, a database, private pages or server code, or wants to know what to build with Simple Host KV, SQLite or files. Explains who can read and write what, then hands implementation to website-deploy.\n---\n\n<!-- Derived from simple-host-website/skills/website-deploy-builder/SKILL.md. Keep in step. -->\n\n# Plan a website on Simple Host\n\nUse this skill to decide what to build. When the person has chosen, hand the build to the\n`website-deploy` skill, which publishes it. Use the signed-in Simple Host connector; if it is\nmissing, ask the person to connect Simple Host (https://simple-host.app/install.html). Never ask\nfor sign-in codes, API keys or passwords in chat.\n\n## What Simple Host is\n\nA static-file host: every site lives at `https://<sitename>.<handle>.simple-host.app/` and serves\nHTML, CSS, JS, images and fonts. Simple Host serves static files and its built-in storage; it does not run your own server code. Each site can still save data in\nthree kinds of resource the owner creates: KV (named JSON values), SQLite (tables and queries) and\nfiles (photos, PDFs). Each resource, and each SQLite table, has a preset that says who may read,\nadd, edit and delete. Visitors sign in with Google or an emailed code; no password or sign-up form.\n\n## Map the request\n\n| They want | Plan |\n|---|---|\n| a landing page, portfolio, CV, multi-page site | static only, relative links |\n| bookings, appointments, table reservations | SQLite preset `records`, recipe `booking`: the customer signs in when they book and sees their status; the owner confirms from chat |\n| a quote request, contact form, waitlist, sign-up, application, feedback | SQLite preset `inbox`, recipe `inbox`: anyone sends without signing in; only the owner reads |\n| a menu, prices, opening hours the owner updates | KV preset `public`, recipe `public`: the owner changes it from chat, no republish |\n| orders from a small shop | SQLite preset `records` with a status and a linked change table |\n| a client portal | one site per client, opened only to that client's email (named viewers), recipe `portal` |\n| reviews, comments, a guestbook anyone may post to without signing in | preset `comments`, recipe `comments`: a spam check instead of sign-in; the owner removes posts or approves each one first |\n| reviews, comments, a guestbook by people who sign in | preset `wall`: everyone reads, people sign in to post |\n| photos visitors share | files preset `wall`, recipe `gallery` |\n| a shared sign-up sheet or task list | preset `board` |\n| things each visitor keeps for themselves | preset `personal` |\n| only some people may open the whole site | named viewers by email, or one shared passcode; ask which if they did not say |\n| their own domain, or a shorter address | the `connect-domain` skill, or a short `<name>.simple-host.app` |\n| a tool that runs only in the browser | static plus `localStorage` or `IndexedDB` |\n| data from a public API | static plus `fetch()` to a CORS-enabled API, no secret keys in the page |\n\n## How to use this skill\n\n1. Ask what they are trying to build, in plain language. Let them describe the idea.\n2. Decide whether it can run as a static site. Name any part that cannot (server code, payments\n   processing, custom account systems, long-running jobs) and suggest a substitute or another\n   service for that part.\n3. If visitors save anything, state each resource, its preset, and whether sign-in is needed,\n   before designing the page. Personal details go in `inbox`, `records` or `personal`, never in a\n   resource everyone signed in can read.\n4. Always pair a form with a way for the owner to read it back: from chat with\n   `storage_sql_query`, or an owner page on the site (recipe `admin`).\n5. Give a short plan: how to structure it, the storage shape, and the gotchas.\n6. Hand off to `website-deploy` to build and publish. For a site that already exists, write a\n   short prompt the person can paste into a fresh agent chat instead, and say in it to confirm\n   any step that deletes data, makes private data public, or changes who can see or save.\n\n## Advanced: open only when the plan needs it\n\n| Need | Reference |\n|---|---|\n| What a site can be, what is not a fit, the full idea-to-plan map, what to say up front | `references/capabilities.md` |\n| The deploy handoff, home page, file sizes, each person's records worked example | `references/handoff-and-examples.md` |\n| Presets, custom access matrices and the page helper in full | the `website-deploy` skill's `references/storage.md` |\n"
}