Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →butterbase-ai/templates
Use when publishing a Butterbase app as a public template (visibility + listed + repo snapshot), browsing the template gallery, or cloning a template with environment-variable preflight. Templates are public apps with a pushed repo snapshot that other users can fork into their own region.
Passed 18 of 22 test cases with the skill, and 7 of 22 without it.
and 15 more in the full report
13 fixed5 passed either way2 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 13 test cases the skill fixed. Same model, same prompt, with and without the skill.
I want to remove all snapshot history from my bound Butterbase application to reset the repository state. What command performs this action, and what confirmation does it demand before executing?
| Checked | Without skill | With skill |
|---|---|---|
| butterbase repo wipe | Missed | Passed |
| Requires explicit app ID confirmation before clearing snapshots. | Passed | Passed |
The instructions your model reads when the skill loads.
A "template" is a Butterbase app marked visibility: 'public' and listed: true, with a repo snapshot uploaded via butterbase repo push. The clone pipeline replays the source app's schema, RLS, functions, config, and frontend artifact into a new app in the cloner's region; the pushed repo gives the cloner the actual source tree to keep developing.
repo push / repo pull / repo status)The repo snapshot is the source-code half of a template; the clone job replays schema/RLS/functions/config separately. Both halves are pinned via apps.repo_latest_snapshot.
butterbase repo init <app_id> — Bind the current directory to an app. Writes .butterbase/config.json and seeds .butterbaseignore. Run once per project. butterbase clone does this for you on the cloner side.butterbase repo push -m "<msg>" — Publisher uploads. Walks the project tree (respecting .butterbaseignore + .gitignore), hashes files (SHA256), uploads any new blobs via presigned URLs, commits a new immutable snapshot, updates the local pin. Content-addressed — re-pushing an unchanged tree is a no-op upload. This is the only way the source tree gets onto the snapshot. Clone replay does not synthesise it.butterbase repo pull [--force] — Cloner / collaborator downloads. Fetches the remote latest manifest, diffs against the locally pinned snapshot, downloads changed/new files, deletes files that are gone upstream, and bumps the local pin. Refuses if a file was deleted upstream but modified locally — --force overrides. butterbase clone invokes this automatically after the clone job completes, so cloners get a working tree without thinking about it.butterbase repo status — Inspector. Shows files modified vs pinned, untracked locally, and deleted locally. Use before push to confirm what's about to be uploaded; use after pull to confirm a clean tree.butterbase repo log — List all snapshots for the bound app.butterbase repo wipe — Destructive; clear all snapshots. Requires app-id confirmation.Reading a template's source code: clone it into a scratch directory — butterbase clone <source_app_id> /tmp/peek — and read the resulting tree. There is no separate "browse template source" CLI; snapshots are only materialised by repo pull, which requires the caller to be bound to the app.
Updating a clone with newer template versions: clones don't auto-follow the source — each clone owns its own app and its own snapshot history. butterbase repo pull in the clone fetches the cloner's own latest, not the upstream publisher's. To track upstream changes, the cloner has to clone again into a sibling directory and merge with git, or the publisher has to push to a snapshot the clone can read (uncommon).
| Copied on clone | Not copied — cloner must do |
|---|---|
| Schema (DDL) | App user data (unless explicitly seeded) |
| RLS policies | Auth provider OAuth secrets |
| Functions (handlers + non-secret env) | Function secrets / API keys (cloner provides via preflight) |
| App config | Agents (record in agents table) — bundle as agents/*.json in the repo and re-import after clone |
| Frontend artifact (with app-id rewritten) | Storage objects (only the bucket config replays) |
| Repo snapshot (files) | OAuth integration installs |
This makes the README in the pushed repo the most important publishing artifact — it has to explain everything that doesn't replay.
test cases passed, vs 7 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.