← Tiniest CloudCONTENT HISTORY

Update to Tiniest Cloud

Snapshot Nov 12, 2026 · 18:31 UTC · version 2.5.4

Collection source: downloaded plugin package.

WHAT CHANGED

Instructions updated for tiny

Skill instructions — Now says: **Start from the starter, and build with the SDK.** Every new app or website starts from the starter, even when nobody asks for one: `npm create...

Observed in instructions or declared skills. Runtime behavior has not been tested.

Save Tiniest Cloud and check future changes in Following.

Up to 3 plugins free · no card required.

All fields and original values.

Skill instructions

Before

Nov 10, 2026 · 12:08 UTC

**Build the frontend with the SDK.** Plain HTML, CSS and JavaScript, or a framework project: build it, then deploy the project folder with its `dist/` inside. `dist/` is served and the rest is kept as the project's source, shown in t...

After

Nov 12, 2026 · 18:31 UTC

**Start from the starter, and build with the SDK.** Every new app or website starts from the starter, even when nobody asks for one: `npm create @tiniestcloud@latest <folder>` (add `-- --template site` for a website), or `get_starter...

Compare saved observations

Download comparison JSON

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -36,10 +36,11 @@
 These four hold regardless of which version of the SDK is current, and they are the ones an
 agent gets wrong when it treats this like ordinary web hosting:
 
-- **Build the frontend with the SDK.** Plain HTML, CSS and JavaScript, or a framework project:
-  build it, then deploy the project folder with its `dist/` inside. `dist/` is served and the rest is
-  kept as the project's source, shown in the Code tab. With a shell, a new one starts from
-  `npm create tiniest-cloud@latest <folder>` (add `-- --template site` for a website).
+- **Start from the starter, and build with the SDK.** Every new app or website starts from the
+  starter, even when nobody asks for one: `npm create @tiniestcloud@latest <folder>` (add
+  `-- --template site` for a website), or `get_starter` without a shell. Plain HTML by hand is only
+  for one small page. Build it, then deploy the project folder with its `dist/` inside. `dist/` is
+  served and the rest is kept as the project's source, shown in the Code tab.
 - **Do not write a login flow.** Sign-in belongs to the platform. The SDK tells you who the
   visitor is; there are no passwords, sessions or tokens for the app to handle.
 - **Do not use `localStorage` for anything that matters.** It is per-browser and per-device,
Full technical diff · 1 changed fields

changed /skill_md_contents

BEFORE
"---\nname: tiny\ndescription: >-\n  Build apps, websites, dashboards and reports and put them online on Tiniest Cloud, which gives\n  each one sign-in, per-user storage, realtime, push notifications, scheduled jobs, backend\n  functions and an LLM, with no keys and no server to set up. Use when building or changing an\n  app hosted on Tiniest Cloud, or when you see tiny.db, tiny.ai, or tiny.rules.json.\n---\n\n# Building for Tiniest Cloud\n\nTiniest Cloud puts apps, websites, dashboards and reports online. Each one gets sign-in,\nper-user storage, realtime rooms, push notifications, scheduled jobs, backend functions and a\nlanguage model, with no keys anywhere and no server to set up.\n\n## Call `tiny_guide` first\n\n**Before writing or changing any app that will be deployed here, call the `tiny_guide` tool.**\nIt returns the current SDK reference, the limits and the patterns that matter, then names the\nguide's other sections; call it again with `section` for each one the build uses (`fetch` to\ncall another service's API, `jobs` for scheduled work, `functions` for server code). This file\ndeliberately does not repeat any of it. The platform gains features,\nand a copy pasted into a plugin listing would keep teaching an old API long after the real one\nmoved on, producing apps that deploy cleanly and then fail in the browser.\n\nSo: `tiny_guide`, then build, then `deploy`.\n\n**Before designing, call `tiny_guide` with a `topic`** — `design`, `app`, `website`,\n`dashboard`, `presentation` or `form` — for how that kind of thing should look: a direction for\nthe product and its industry, palette, type, motion, light and dark, and a checklist. When the\nperson has design standards of their own (a design system, components, a brand guide, an app to\nmatch), those come first and the playbook only fills what they leave open.\n\n## What never changes\n\nThese four hold regardless of which version of the SDK is current, and they are the ones an\nagent gets wrong when it treats this like ordinary web hosting:\n\n- **Build the frontend with the SDK.** Plain HTML, CSS and JavaScript, or a framework project:\n  build it, then deploy the project folder with its `dist/` inside. `dist/` is served and the rest is\n  kept as the project's source, shown in the Code tab. With a shell, a new one starts from\n  `npm create tiniest-cloud@latest <folder>` (add `-- --template site` for a website).\n- **Do not write a login flow.** Sign-in belongs to the platform. The SDK tells you who the\n  visitor is; there are no passwords, sessions or tokens for the app to handle.\n- **Do not use `localStorage` for anything that matters.** It is per-browser and per-device,\n  so the same person loses their data on their phone. Storage in the SDK follows the account.\n- **Do not add a server of your own or call your own API.** There is no origin to call. Logic\n  users must not be able to change runs as a backend function: a file in the deployed\n  `_functions/` folder (`public/_functions/` in the starters), called from the page with\n  `tiny.call`. Anything that needs a secret goes through a connection the app's owner declares,\n  so the key never reaches the page or the function's code.\n\n## Deploying\n\nThe server cannot read your disk. Read the files yourself and pass their contents to `deploy`.\nEvery deploy is a new immutable version, saved as a draft: nothing goes live from a deploy.\nThe person looks at it in the build view and publishes it there, and earlier versions stay\nrestorable with `rollback`.\n\nIf a deploy reports that an app uses `localStorage` or calls its own backend, `modernize_app`\nconverts it to the platform's own storage and sign-in.\n"
AFTER
"---\nname: tiny\ndescription: >-\n  Build apps, websites, dashboards and reports and put them online on Tiniest Cloud, which gives\n  each one sign-in, per-user storage, realtime, push notifications, scheduled jobs, backend\n  functions and an LLM, with no keys and no server to set up. Use when building or changing an\n  app hosted on Tiniest Cloud, or when you see tiny.db, tiny.ai, or tiny.rules.json.\n---\n\n# Building for Tiniest Cloud\n\nTiniest Cloud puts apps, websites, dashboards and reports online. Each one gets sign-in,\nper-user storage, realtime rooms, push notifications, scheduled jobs, backend functions and a\nlanguage model, with no keys anywhere and no server to set up.\n\n## Call `tiny_guide` first\n\n**Before writing or changing any app that will be deployed here, call the `tiny_guide` tool.**\nIt returns the current SDK reference, the limits and the patterns that matter, then names the\nguide's other sections; call it again with `section` for each one the build uses (`fetch` to\ncall another service's API, `jobs` for scheduled work, `functions` for server code). This file\ndeliberately does not repeat any of it. The platform gains features,\nand a copy pasted into a plugin listing would keep teaching an old API long after the real one\nmoved on, producing apps that deploy cleanly and then fail in the browser.\n\nSo: `tiny_guide`, then build, then `deploy`.\n\n**Before designing, call `tiny_guide` with a `topic`** — `design`, `app`, `website`,\n`dashboard`, `presentation` or `form` — for how that kind of thing should look: a direction for\nthe product and its industry, palette, type, motion, light and dark, and a checklist. When the\nperson has design standards of their own (a design system, components, a brand guide, an app to\nmatch), those come first and the playbook only fills what they leave open.\n\n## What never changes\n\nThese four hold regardless of which version of the SDK is current, and they are the ones an\nagent gets wrong when it treats this like ordinary web hosting:\n\n- **Start from the starter, and build with the SDK.** Every new app or website starts from the\n  starter, even when nobody asks for one: `npm create @tiniestcloud@latest <folder>` (add\n  `-- --template site` for a website), or `get_starter` without a shell. Plain HTML by hand is only\n  for one small page. Build it, then deploy the project folder with its `dist/` inside. `dist/` is\n  served and the rest is kept as the project's source, shown in the Code tab.\n- **Do not write a login flow.** Sign-in belongs to the platform. The SDK tells you who the\n  visitor is; there are no passwords, sessions or tokens for the app to handle.\n- **Do not use `localStorage` for anything that matters.** It is per-browser and per-device,\n  so the same person loses their data on their phone. Storage in the SDK follows the account.\n- **Do not add a server of your own or call your own API.** There is no origin to call. Logic\n  users must not be able to change runs as a backend function: a file in the deployed\n  `_functions/` folder (`public/_functions/` in the starters), called from the page with\n  `tiny.call`. Anything that needs a secret goes through a connection the app's owner declares,\n  so the key never reaches the page or the function's code.\n\n## Deploying\n\nThe server cannot read your disk. Read the files yourself and pass their contents to `deploy`.\nEvery deploy is a new immutable version, saved as a draft: nothing goes live from a deploy.\nThe person looks at it in the build view and publishes it there, and earlier versions stay\nrestorable with `rollback`.\n\nIf a deploy reports that an app uses `localStorage` or calls its own backend, `modernize_app`\nconverts it to the platform's own storage and sign-in.\n"
Full snapshot data
{
  "description": "Build apps, websites, dashboards and reports and put them online on Tiniest Cloud, which gives each one sign-in, per-user storage, realtime, push notifications, scheduled jobs, backend functions and an LLM, with no keys and no server to set up. Use when building or changing an app hosted on Tiniest Cloud, or when you see tiny.db, tiny.ai, or tiny.rules.json.",
  "included_files": [],
  "name": "tiny",
  "skill_md_contents": "---\nname: tiny\ndescription: >-\n  Build apps, websites, dashboards and reports and put them online on Tiniest Cloud, which gives\n  each one sign-in, per-user storage, realtime, push notifications, scheduled jobs, backend\n  functions and an LLM, with no keys and no server to set up. Use when building or changing an\n  app hosted on Tiniest Cloud, or when you see tiny.db, tiny.ai, or tiny.rules.json.\n---\n\n# Building for Tiniest Cloud\n\nTiniest Cloud puts apps, websites, dashboards and reports online. Each one gets sign-in,\nper-user storage, realtime rooms, push notifications, scheduled jobs, backend functions and a\nlanguage model, with no keys anywhere and no server to set up.\n\n## Call `tiny_guide` first\n\n**Before writing or changing any app that will be deployed here, call the `tiny_guide` tool.**\nIt returns the current SDK reference, the limits and the patterns that matter, then names the\nguide's other sections; call it again with `section` for each one the build uses (`fetch` to\ncall another service's API, `jobs` for scheduled work, `functions` for server code). This file\ndeliberately does not repeat any of it. The platform gains features,\nand a copy pasted into a plugin listing would keep teaching an old API long after the real one\nmoved on, producing apps that deploy cleanly and then fail in the browser.\n\nSo: `tiny_guide`, then build, then `deploy`.\n\n**Before designing, call `tiny_guide` with a `topic`** — `design`, `app`, `website`,\n`dashboard`, `presentation` or `form` — for how that kind of thing should look: a direction for\nthe product and its industry, palette, type, motion, light and dark, and a checklist. When the\nperson has design standards of their own (a design system, components, a brand guide, an app to\nmatch), those come first and the playbook only fills what they leave open.\n\n## What never changes\n\nThese four hold regardless of which version of the SDK is current, and they are the ones an\nagent gets wrong when it treats this like ordinary web hosting:\n\n- **Start from the starter, and build with the SDK.** Every new app or website starts from the\n  starter, even when nobody asks for one: `npm create @tiniestcloud@latest <folder>` (add\n  `-- --template site` for a website), or `get_starter` without a shell. Plain HTML by hand is only\n  for one small page. Build it, then deploy the project folder with its `dist/` inside. `dist/` is\n  served and the rest is kept as the project's source, shown in the Code tab.\n- **Do not write a login flow.** Sign-in belongs to the platform. The SDK tells you who the\n  visitor is; there are no passwords, sessions or tokens for the app to handle.\n- **Do not use `localStorage` for anything that matters.** It is per-browser and per-device,\n  so the same person loses their data on their phone. Storage in the SDK follows the account.\n- **Do not add a server of your own or call your own API.** There is no origin to call. Logic\n  users must not be able to change runs as a backend function: a file in the deployed\n  `_functions/` folder (`public/_functions/` in the starters), called from the page with\n  `tiny.call`. Anything that needs a secret goes through a connection the app's owner declares,\n  so the key never reaches the page or the function's code.\n\n## Deploying\n\nThe server cannot read your disk. Read the files yourself and pass their contents to `deploy`.\nEvery deploy is a new immutable version, saved as a draft: nothing goes live from a deploy.\nThe person looks at it in the build view and publishes it there, and earlier versions stay\nrestorable with `rollback`.\n\nIf a deploy reports that an app uses `localStorage` or calls its own backend, `modernize_app`\nconverts it to the platform's own storage and sign-in.\n"
}

SHA-256 of public snapshot: 453b4125152c40062ef434e109c536f8649300ee92afb70c05532bc8136a123d