Skills

Journey Plan

Use as stage 2 of the Butterbase journey, after journey-idea has written 01-idea.md.

Install

npx skills add butterbase-ai/butterbase-skills --skill journey-plan -g -a claude-code -y
Category
Design
Updated
4d ago
License
MIT
Context cost
Mediumabout 1,968 tokens
Runs scripts
No, instructions only

What it does

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.

Journey: Plan

Stage 2 of the guided journey. Turn the idea brief into an actionable Butterbase plan.

When to use

  • Dispatched by journey when current_stage: plan.
  • Directly via /butterbase-skills:plan.

Inputs

  • docs/butterbase/01-idea.md (must exist, if absent, bounce back to journey-idea).
  • docs/butterbase/00-state.md (for hackathon_mode, hackathon_deadline).

External services, check built-ins first

When the plan needs email, messaging, calendar, CRM, docs, or project-management integration:

  1. Invoke butterbase-skills:integrations and call manage_integrations action: "list_available" to see what Composio covers for this app.
  2. If a toolkit fits, the plan should record "via manage_integrations (toolkit: <name>)" instead of naming an external SDK.

When the plan needs payments:

  1. Invoke butterbase-skills:payments.
  2. Default to Stripe Connect via manage_billing unless the user's region forces a fallback (see the payments skill).
  3. Record the choice ("Stripe Connect" or "<regional gateway> via function proxy") in the plan's Payments section.

Procedure

Work through these sections in order. After each section, write the result to 02-plan.md before moving on. One question at a time per the spec's questioning discipline.

  1. Tables. Read the capability map. Propose a starter table list with columns and types, recommend, don't ask blank. Example: "Tables I'm seeing: users, orders, items. Missing any?" Then for each table: "<table>.<column>: should this be a uuid / text / int / timestamp / enum?". Confirm primary keys, foreign keys, indexes that are obvious (foreign-key columns).

  2. RLS model. For each table: "Can user A see user B's <table> rows? ① no, strict isolation ② yes, public-read ③ only shared via explicit grant." Decide policy shape. In hackathon mode, prefer option ① and recommend manage_rls action: create_user_isolation.

Read the whole SKILL.md on GitHub

More in Design