bassclef
Get started

Quickstart

Install bassclef and run your first three commands in about 15 minutes.

Time ~15 min end to endPrereqs Claude Code + a git repoCost free (Claude API on your budget)

Use this when

You have Claude Code installed, you have a repo you want to try bassclef in, and you want a step-by-step walkthrough from zero to a pull request on your branch.

Skip this when

You already ran the three commands and want reference detail. Head to the individual skill pages under Skills, or read the install page for install-only detail.

Step 1 — Install bassclef

Follow the install page for the full list of prereqs (Claude Code, Node 20+, git, Python 3) and the six setup commands: pnpm add -g @thebassclef/lite → bassclef init → open Claude Code → /onboard-repo → bassclef check. About five minutes end to end.

The /onboard-repo step is one-time setup that wires GitHub and fills project state. Do it once before Step 2 below — the next three commands assume it ran.

Verify the install worked:

bassclef check

Expected: a table showing the substrate version, the wired skills, and the wired hooks. If anything looks wrong, the failure-mode playbook has the recovery steps for each class.

Step 2 — Sketch a UI with /riff

In Claude Code inside your repo, type:

/riff a modal that lets a user schedule a Slack DM to themselves in
30 days as a reminder to review a decision they made today

Replace the paragraph after /riff with what you actually want to sketch. Any UI idea works — a modal, a settings screen, a dashboard tile, a form field.

Claude comes back with three clickable HTML mocks on a local /prototypes/<slug>/ URL. Each mock is drafted through a different design lens. You click through them in your browser and pick the direction that feels right.

Expected time: 3-5 minutes for /riff to run.

Step 3 — Turn one sketch into a plan with /launch

Once you have picked a variant, type /launch and name the variant you want — /launch variant b, /launch pick B, or just tell it which mock you chose. Claude reads the variant and produces:

  • A spec at docs/specs/YYYY-MM-DD-<slug>.md
  • User stories shaped for one-at-a-time shipping (each is independent, negotiable, valuable, estimable, small, and testable — the INVEST checklist)
  • A class-responsibility decomposition (which class owns which behavior, following the GRASP pattern set)
  • A migration plan (branch shape, feature flag, cutover checklist)

You review the spec. If it looks right, move on. If it does not, edit the spec — bassclef reads it as authoritative for step 4.

Expected time: 5-7 minutes for /launch to run + your review time.

Step 4 — Ship the plan with /build

Type:

/build

/build dispatches the Builder role per user story. For each one, it writes code, runs /verify, commits, and moves on. When all stories are done, /build dispatches Reviewer against the spec. If Reviewer signs off, /build opens a pull request on your branch.

You review the pull request the same way you would review a teammate's. You merge when you are ready.

Expected time: varies — depends on story count and complexity. A small feature might take 20 minutes. A medium one, an hour.

What you shipped

By the end of the four steps, you have:

  • A pull request open on your repo with real code
  • A spec that documents what the code does and why
  • User stories (INVEST-shaped) that trace back to the spec
  • A Reviewer-signed-off record in the pull request body
  • A migration plan for anyone deploying this

Your reviewer can compare the code against the spec you agreed on before implementation started. No handoff surprise. No demo that does not compile.

What to try next

On this page

© 2025–2026 Sunjay Pandey·Privacy·Apache-2.0 code