fusebase-flow

Run the A2 find-wasted-effort audit — the process-per-outcome (ceremony) sibling of /token-waste-audit. Parses Flow artifacts on disk (gate/deploy reports, handoffs, approval artifacts, git log, prevents: annotations) for ceremony that bought no safety outcome. Read-only; report goes to state/audit/ (gitignored). Findings are review candidates, never auto-prune.

Run the read-only Fusebase Flow health check. Reports CLI_LAYER_DRIFT, FLOW_LAYER_DRIFT, SHARED_MERGE_DRIFT, EXCEPTION_IN_EFFECT, BROKEN, or HEALTHY, and offers Flow recovery only for Flow-owned/shared drift after explicit operator confirmation.

Write the active session restart state to docs/tmp/handoff.md so a fresh AI session continues from the exact current point. Triggers the handoff skill — inspects repo state, reconstructs goal/decisions/failures/next-step, and writes the 16-section handoff for the next coding agent (not a human report).

Onboard THIS project to Fusebase Flow. The Product Owner interviews you about your vision, audience, and domain, then writes the project artifacts (docs/north-star.md, AGENTS project-values) that steer all future work. Re-runnable. Skipping is fine — Flow works generically without it; nothing is created unless you provide content.

Start a Product Owner session under Fusebase Flow. The PO is the single point of contact — consults on what to build and how, reads the project's North Star (if onboarded), and breaks work into phases and slices for the AI Developer. Does not write application code.

Use this agent to execute a Fusebase Flow AI Developer or Deploy-phase handoff. Invoke with `docs/tmp/handoff/<date>-<slug>-implement.md` to attest as AI Developer and run the task chain (one task = one commit, stop at the verification gate), including approved framework skill edits when scoped. Invoke with `docs/tmp/handoff/<date>-<slug>-deploy.md` to attest as Deploy phase and run the deploy command per the deploy handoff (capture deploy hash, run probes, observe smoke results). Never drafts specs or decisions; never approves deploys without an explicit handoff artifact. Stops at the gate; produces the gate report and waits.

Run this agent when the user wants to create or update an app. It analyzes the user's requirements and produces a detailed technical architecture plan — data model, backend needs, permissions, UI structure — that the main coding agent will implement.

Use this agent when a new app has been generated or scaffolded in the project. It verifies that the app has been properly created.

Use this agent to lead the Fusebase Flow ticket lifecycle from Specify through deploy closeout. Drives Specify, Clarify, Plan, design discovery/ideation, skill classification, Decisions, Tasks, draft-verification-gate, post-implement code-review (and security-permissions-review when the diff touches a sensitive surface), deploy-handoff drafting, and deploy closeout (verifying the Deploy session's single FR-14 docs commit landed). Absorbs Architect responsibilities inline when escalation triggers fire (investigation surface > 10 files, cross-cutting refactor, platform blocker, blocked-migration design). Never edits application code; produces specs, decisions, tasks, gates, handoffs only.

Guide for creating and using secrets in Fusebase Apps app backends. Use when: (1) An app backend needs API keys, passwords, or other sensitive config, (2) Creating secrets via the CLI, (3) Accessing secrets at runtime in backend code, (4) Deciding what should be a secret vs. a regular env var.

Guide for managing sidecar containers alongside app backends. Use when: (1) An app backend needs auxiliary services like headless browsers, caches, or other tools, (2) Adding/removing/listing sidecar containers, (3) Configuring sidecar networking, env vars, or resource tiers.

Guidance for visual design, UI and UX in Fusebase-generated apps. Use when building or refining app UIs: pages, components, layouts, forms, feedback states, theming, or accessibility. Ensures consistent, clear, and distinctive interfaces using shadcn/ui.

Use ONLY when docs/<app>/business-logic.md exists, before fixes/improvements that touch business behavior. Treats the documented business logic as a guard layer — the fix must not silently break documented behavior. Pairs with FR-20 zoom-out. If no business-logic doc exists, this skill does nothing (silent no-op) — do NOT auto-create. Not for net-new features with no documented logic.

Use ONLY when docs/audience.md exists (audiences defined during onboarding) OR the operator explicitly asks to optimize a surface for client-facing vs internal use. Steers app surfaces differently — client-facing = simple/guided/trust-first; internal = robust controls/power-features. If docs/audience.md is absent, this skill does nothing (silent no-op) — do NOT activate or create the file. Not for projects without defined audiences.