build-app · git:20261005.660dfe3 · 2026-10-05 · sha256 d607122369f19806
build-app git:20261005.660dfe3A
Immutable. This exact content never changes and is served at /api/v1/blob/d607122369f19806.
---
name: build-app
description: The front door for building a Streamlit-in-Snowflake app from idea to opened PR, or resuming one mid-build. Owns the spec, scaffold, page-building, and ship phases, with human checkpoints between them. Start here for any new app, to document an existing one, or to add a page. Use when the user says "build an app", "new dashboard", "add a page", "spec this out", or "pick up where we left off".
argument-hint: "[<idea>] | --spec"
allowed-tools: [Bash, Read, Write, Edit, Glob, Grep, AskUserQuestion]
---
# /build-app
> **Repo overlay:** if `.streamsnow/overlays/build-app.md` exists in this repo, read it first — committed, repo-specific additions/overrides ([_shared/overlays.md](../_shared/overlays.md)). Outside Claude Code, also read [_shared/other-agents.md](../_shared/other-agents.md).
One command owns the app lifecycle: **spec → scaffold → build → preview → verify → ship → done**.
It reads `apps/<slug>/REQUIREMENTS.md` §11 to resume an interrupted build, tells the user the exact
next command at each judgment point, and never skips a checkpoint.
> **Wizard, not a runner.** It runs everything deterministic itself — the `streamsnow` CLI steps,
> preview launch, validation, and the `/review-app` procedure — and stops only at the three human
> checkpoints (spec confirmed, pages clicked through, ready to ship). The user types checkpoints.
## Modes
- **Default** — a new app, or a slug to resume. If `apps/<slug>/REQUIREMENTS.md` §11 exists, resume
from its `Current phase`; never restart a build that's underway.
- **`--spec [<slug>]`** — write or refresh the requirements spec only, then stop for review. Covers
brand-new specs, ticket ingestion, and **backfill** (reverse-engineering the spec from an existing
app's source — automatic when `apps/<slug>/` already has code). Follow [spec.md](spec.md).
## Phase 0 · Preflight
1. Report which `streamsnow` runs and its version, then run `streamsnow doctor --format json`.
2. If `streamsnow` is not on PATH, a `required` check fails, or `streamsnow.config.yaml` is
missing, say "This machine or repo isn't set up yet, so I'm running onboarding first", follow
[/onboard](../onboard/SKILL.md)'s instructions in full, then continue at Phase 1. `optional`
failures get one line and no handoff.
- `--spec` mode only: offer `/onboard` but carry on without config if the user prefers;
schema choices in §3 then stay unverified.
## Phase 1 — Spec
3. Follow [spec.md](spec.md) to produce `apps/<slug>/REQUIREMENTS.md` — the contract every later
phase builds and audits against. Confirm the one-screen summary with the user before moving on.
## Phase 2 — Scaffold, then CHECKPOINT 1
4. Follow [scaffold.md](scaffold.md): `streamsnow new <domain> <function>` plus the first-build
conventions. Runtime comes from the spec §9 / repo default — see
[_shared/runtime-decision.md](../_shared/runtime-decision.md); decide before scaffolding.
5. **CP1:** show the scaffold tree and the §4 page list (created vs. TODO). Ask: continue /
edit the spec / stop. Block until the user chooses.
## Phase 3 — Build pages, then CHECKPOINT 2
6. For each TODO page in §4 order, follow [pages.md](pages.md) — page module, `queries/*.sql` with
header blocks, `st.navigation` registration — then fill the stubs against the spec. Run the
matching `streamsnow check` commands as you go; problems are cheapest here.
7. Launch the preview yourself per [pages.md § Build loop](pages.md#build-loop) (`streamsnow
preview start <slug>`), hand over the URL, and ask for a click-through of every page.
8. **CP2:** the user confirms pages render, charts populate, and filters work — the correctness
check no static gate can make. Block until they answer.
## Phase 4 — Check & ship, then CHECKPOINT 3
9. Run `streamsnow validate-app <slug>` — the pass/fail check that must be clean before shipping.
Fix and re-run on any FAIL (`/validate-app` explains each one).
10. **Run the review yourself:** follow `/review-app`'s instructions in full for this app (default
mode; `--auto` only if the user asked for the hands-off loop). Present its verdict.
11. **CP3:** validation passes, review is clean, user is ready → hand off to `/ship-app <slug>`
(a first deploy may need one-time admin DDL from `streamsnow deploy-setup --admin`: surface it, don't run it).
## State — §11 Build Progress
§11 lives inside `apps/<slug>/REQUIREMENTS.md`: a `Current phase` line (the lifecycle above) plus
an append-only `Sessions` log whose last line always names the next command. Update it via `Edit`
on every phase transition — never rewrite past session lines. On resume, read `Current phase` and
jump to the matching phase; `done` or `in-production (backfilled)` means the app is live — new
§4 pages route to the build phase, anything else to `/feedback-app` or `/review-app`.
Apps started before 0.8 name the old `start-app` skill in that log; say `/build-app` instead.
## Out of scope
Porting an external app → `/migrate-app`; feedback on a live app → `/feedback-app`; review depth → `/review-app`; live lineage → `/audit-lineage`; machine, repo and Snowflake setup → `/onboard`.
## Done when
The PR is open, `streamsnow validate-app <slug>` passes, and §11 reads `Current phase: done`.