メニュー
Use as the optional substrate-linking stage of the Butterbase journey, after deploy and before submit. Asks whether to connect the deployed app to the owner's substrate (so functions get ctx.substrate). Skipped by default in hackathon mode.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Claude Code plugin for Butterbase — 30+ guided skills and auto-configured MCP for the AI-native backend-as-a-service.
Use when the user wants to read/write their Butterbase substrate — the per-user agent-memory backend that holds entities, business state, institutional memory, and an append-only action ledger. Use for: founder copilots, AI agents that need memory across sessions, anything that proposes actions on the user's behalf.
Use when designing, deploying, or debugging a Butterbase Agent (declarative LLM/tool graph), registering an MCP server for tool use, or wiring access controls and rate limits. Agents are first-class app resources defined by a `graph_spec` and invoked over `/v1/<app_id>/agents/<name>/runs`.
Use as the agents build stage of the Butterbase journey. Implements the Agents section of 02-plan.md by delegating to the `agents` skill for each agent. Registers any required MCP servers, validates each graph_spec, creates the agent, and smokes it via invoke_agent. Skipped if the plan has no agents.
Use as stage 1 of the Butterbase journey, when the user has only a rough idea ("I want to build something that..."). Conducts a concrete, one-question-at-a-time brainstorm that surfaces who the user is, what they do first, what the must-haves are, and inline-tags Butterbase capabilities (→ manage_schema, → deploy_function, etc.). Produces docs/butterbase/01-idea.md.
Use as stage 2 of the Butterbase journey, after journey-idea has written 01-idea.md. Translates the idea + capability map into a concrete Butterbase plan — tables (with columns/types/RLS shape), auth providers, function list (name + trigger), storage buckets, AI/RAG/realtime/durable usage, and the chosen frontend stack. In hackathon mode, ruthlessly cuts scope into a "ship now" vs "post-hackathon" split. Produces docs/butterbase/02-plan.md.
| name | journey-substrate |
| description | Use as the optional substrate-linking stage of the Butterbase journey, after deploy and before submit. Asks whether to connect the deployed app to the owner's substrate (so functions get ctx.substrate). Skipped by default in hackathon mode. |
Connect the deployed app to the owner's substrate so functions get ctx.substrate injected at cold start. Skip if the user has no AI-agent / memory use case.
Invoke automatically when the journey orchestrator's cursor reaches substrate. The row is optional in the checklist; skip silently if the user declines.
Refresh docs. Call butterbase_docs with topic: "substrate". If the plan mentions AI memory / agent state / cross-session knowledge, also WebFetch https://docs.butterbase.ai/substrate. Skip if docs/butterbase/03b-docs-cache.md already covers substrate.
Confirm. Ask the user:
"Connect
<app_id>to your substrate? This lets the app's functions read/write your agent memory viactx.substrate. You can disable later. (yes / skip)"
Default: skip.
On skip: mark the row - [x] substrate (skipped — no agent memory needed) in docs/butterbase/00-state.md. Write docs/butterbase/04b-substrate.md with one line: Skipped on <date>. Return.
On yes:
a. If platform_users.substrate_provisioned_at is NULL for the caller, call POST /v1/me/substrate/provision first (or invoke whatever MCP wrapper exists — check butterbase_docs topic substrate).
b. Link the app. Use whichever surface you have:
manage_app with { action: "link_substrate", app_id: "<app_id>" }.butterbase apps link-substrate <app_id>.POST /v1/me/apps/<app_id>/substrate-link with empty body and Authorization: Bearer <bb_sk_*> for the app owner. The route enforces caller == app owner and sets apps.substrate_user_id to the caller's id.
c. Verify: manage_app with { action: "get_config", app_id: "<app_id>" } and assert substrate_user_id is non-null.
d. Smoke: invoke any HTTP function the app already has and check ctx.substrate is defined (if the function logs it). If no function exists yet, skip the smoke and note in the artifact.Write artifact. docs/butterbase/04b-substrate.md:
---
linked_at: <ISO>
app_id: <id>
substrate_user_id: <id>
---
# Substrate Linkage
- App linked at <ISO>
- Substrate user ID: <id>
- Smoke: <pass / skipped — no function yet>
Update state. Tick the substrate row in 00-state.md.
journey-functions has run.