journey-templates
Skill535 starsChanged 5 months agoMITView on GitHub
Use as the optional template-publishing stage of the Butterbase journey, after deploy (and substrate, if used). Walks the user through authoring a clone-ready README, bundling agent spec files, dry-running and pushing the repo snapshot, flipping visibility to public + listed, and self-clone-testing. Delegates the mechanics to the `templates` skill. Skipped by default in hackathon mode.
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 30
Refresh docs: Call butterbase_docs with topic: "templates" (and topic: "repo" if the cache doesn't already cover snapshot push).
- Distinctive: line 35
Default: skip (especially in hackathon mode unless the user explicitly chose to publish their submission).
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Journey: Publish-as-template (optional)
Turn the deployed app into a public, forkable template. This stage is only for apps the user explicitly wants to share — most journeys end at deploy (or submit in hackathon mode).
When to use
- Dispatched by
journeywhencurrent_stage: templates. - Directly via
/butterbase-skills:journey-templates. - The row is optional in the checklist; skip silently if the user declines.
Inputs
- A deployed, working app (post-
journey-deploy). docs/butterbase/02-plan.md— to know what features the app uses (agents, MCP servers, OAuth providers, function env vars).docs/butterbase/04-build-log.md— to confirm deploy smoke passed.
Preflight
00-state.mdmust havecurrent_stage: templatesor later ANDdeployticked.- The
@butterbase/climust be installed locally (butterbase --versionworks). If not, invokejourney-preflightto fix. - The repo must be bound:
.butterbase/config.jsonexists with the rightcurrentApp. If not, runbutterbase repo init <app_id>.
Procedure
- Refresh docs. Call
butterbase_docswithtopic: "templates"(andtopic: "repo"if the cache doesn't already cover snapshot push). Skip if03b-docs-cache.mdis fresh. Confirm intent. Ask:
"Publish '<app_name>' as a public template? Public + listed makes it appear in the gallery; public + unlisted is forkable by anyone with the app_id but hidden from search. Or skip. (listed / unlisted / skip)"
Default: skip (especially in hackathon mode unless the user explicitly chose to publish their submission).
- On skip: mark the row
- [x] templates (skipped — not publishing)in00-state.md. Writedocs/butterbase/06-template.mdwith one line:Skipped on <date>.Return to orchestrator. - On listed / unlisted: delegate to
butterbase-skills:templates. The wrapped skill walks the user through: a. Author / review README.md. This is the most important step — clone replay does not carry OAuth secrets, agent records, MCP server registrations, function secrets, or user data. The README must explain every manual step a cloner will need. Thetemplatesskill has the full checklist; do not let it write a short README and move on. b. Bundle agent specs. If the app has agents, ensureagents/<name>.jsonexist (export withbutterbase agents get <name>if missing) and are tracked. c. Inspect drift.butterbase repo status. Walk the modified / untracked / deleted lists with the user. This is the chance to catch a stray secret file or an unwanted directory before it ends up in the snapshot. d. Dry-run.butterbase repo push --dry-run. Confirm the final upload manifest matches whatrepo statusshowed. e. Push.butterbase repo push -m "publish v1". Capture the snapshot id. f. Flip visibility.butterbase visibility public --listed(or--unlisted). g. Self-clone test.butterbase clone <app_id> /tmp/clone-test-<ts>into a scratch directory — this also exercises the cloner-siderepo pullthatbutterbase cloneruns internally. The wrapped skill walks the README from a cold cloner's perspective and reports any gap. Loop back to (a) if gaps exist. Write artifact.
docs/butterbase/06-template.md:--- published_at: <ISO> app_id: <id> visibility: public listed: <true|false> snapshot_id: <id> selfclone_test: <pass | gaps fixed in round N> --- # Template publication - Visibility: public (<listed | unlisted>) - Latest snapshot: <id> - README covers: env vars, OAuth, agent re-import, MCP servers, seed data, first-run smoke - Self-clone test directory: /tmp/clone-test-<ts> - Gallery URL: https://butterbase.ai/templates/<app_id> (or wherever discovery lives)- Update state. Tick
- [x] templatesin00-state.md. - Return to orchestrator (or end the journey, since this is the last optional stage).
Anti-patterns
- ❌ Pushing the repo after flipping visibility. Order matters: snapshot first, public second. Otherwise the gallery briefly advertises an empty template.
- ❌ Skipping the README. The clone preflight tells the cloner which env vars exist but not what they're for or what manual setup remains. A bare-bones README publishes a broken-on-clone experience.
- ❌ Skipping the self-clone test. The author always knows too much; only a cold walk-through catches missing instructions.
- ❌ Forgetting agent specs. The
agentsDB table doesn't replay. Withoutagents/*.jsonin the repo, cloners can see your agent code paths but cannot recreate the agents themselves. - ❌ Publishing in hackathon mode by default. Hackathon submissions are usually private; only publish if the user explicitly asks.
- ❌ Pushing files containing secrets. Always dry-run first and scan the file list.
Other versions1 project uses a version of this.
Word for word · 1
- butterbase-ai/butterbase-skills★ 535100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository40 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- butterbase-skillsSkill
- agentsSkill
- aiSkill
- auth-setupSkill
- build-appSkill
- contributingSkill
- debug-rlsSkill
- deploy-frontendSkill
- durable-objectsSkill
- function-devSkill
- integrationsSkill
- journey-agentsSkill
- journey-aiSkill
- journey-authSkill
- journey-deploySkill
- journey-docsSkill
- journey-durableSkill
- journey-frontendSkill
- journey-functionsSkill
- journey-ideaSkill
- journey-planSkill
- journey-preflightSkill
- journey-ragSkill
- journey-realtimeSkill
- journey-rlsSkill
- journey-schemaSkill
- journeySkill
- journey-storageSkill
- journey-submitSkill
- journey-substrateSkill
- meetingsSkill
- migrationsSkill
- paymentsSkill
- rag-devSkill
- realtimeSkill
- schema-designSkill
- storageSkill
- substrateSkill
- templatesSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

