fusebase-dev
OrganizationThe framework client-facing teams use to build internal & client apps with AI. Two agents — a Product Owner that advises what to build, and an AI Developer that ships it. Built by FuseBase.
Categories
Indexed Skills (45)
business-logic-guardian
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.
client-vs-internal
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.
code-review
Use before commit, deploy, or PR merge, or when operator asks "review this diff" / "is this safe?"; reviews diff vs spec, decisions, maintainability, scope, tests, rollback. Do NOT write or fix code — review only.
comment-policy
Use when writing or editing code, adding/changing comments, or before committing a code diff — delivers FR-22's tripwire + retrieval-pointer comment policy at write time. Do NOT use for prose/doc edits, non-code tickets, or as a review gate (that's `code-review`).
communication
ALWAYS apply on every chat output (Mode A — visual, concrete, brief) and on every internal-artifact write (Mode B — dense, tabular, front-loaded; no narrative padding). Mandatory at session start; not on-demand. Contains the full ASCII pattern library and the 12 Mode B principles with concrete anti-patterns.
design-discovery-ideation
Use when the operator asks for options, variations, alternatives, product/UI directions, or divergent ideation before a spec or decision is locked. Do NOT use for deterministic edits, post-lock implementation changes, simple bug fixes, or AI Developer invention of new product direction.
documentation-budget
Use before creating, expanding, or revising any AI-consumed documentation artifact (spec, decisions, tasks, verification-gate, handoff, backlog, problem-catalog, product/business-logic docs, project-internal skills). Classifies whether a persistent doc is needed, which tier applies, and how to minimize context cost. Operationalizes FR-23 — documentation budget. Prevents duplicate rationale, narrative padding, and docs created merely because a template exists. Do NOT use for operator chat, source comments (that's `comment-policy`), or purely human-facing files (README/LICENSE/PUBLISHING).
fusebase-flow-health-check
Use when the operator asks "is Fusebase Flow healthy", "check Fusebase Flow", "did fusebase update break anything", "Fusebase Flow status", "restore Fusebase Flow", or asks whether Fusebase CLI and Fusebase Flow agent files conflict. Runs the read-only health engine, reports layer verdicts (`HEALTHY`, `CLI_LAYER_DRIFT`, `FLOW_LAYER_DRIFT`, `SHARED_MERGE_DRIFT`, `EXCEPTION_IN_EFFECT`, `BROKEN`), and offers Flow recovery only when the drift is Flow-owned or shared-merge. For CLI-owned drift, instruct the operator to run the current FuseBase CLI refresh/update first, then Flow recovery.
git-history-diagnostic
Use when something worked before and is now broken (a regression), or the operator asks "when did this break", "find the commit that caused X", "it used to work", "compare to a previous version". Locates where a regression entered by comparing commits / bisecting history. Do NOT use for net-new bugs that never worked, for routine rollback (git-workflow), or as a substitute for reproduce-before-fix (FR-10).
implementation-planning
Use after spec is drafted to plan implementation; produces decisions, tasks, verification-gate, and implementer handoff. Do NOT write code, do NOT lock decisions on operator's behalf, do NOT run before spec exists.
lightweight-lane
Use at Specify to classify a ticket Full vs Lightweight, and whenever a change looks small / reversible / low-risk ("small fix", "tweak", "hotfix", "drop pretty-printing", "bump a constant"). Operationalizes FR-21 — ceremony proportional to change size. Defines the eligibility gate, the change-note artifact, the one-pass build→verify→deploy procedure, and mid-flight promotion. Do NOT use for risky/uncertain work, schema/data migrations, security/permission changes, new public contracts needing a decision, unknown-root-cause diagnostics, or large features — those take the Full lane.
north-star
Use ONLY when docs/north-star.md exists (the project has been onboarded) OR the operator explicitly asks to check/apply the North Star. When present, steers every task, decision, and fix toward the project's locked vision and flags drift away from it. If docs/north-star.md is absent, this skill does nothing (silent no-op) — do NOT activate, do NOT create the file. Not for projects that have not been onboarded.
phase-audit
Use when a multi-slice phase has been implemented and the operator wants an independent audit of ALL slices before sign-off, or asks to "audit the phase", "review all slices", "independent check". Spawns a fresh sub-agent that examines every slice against the spec. Do NOT use for a single-diff review (use code-review), for security-only review (use security-permissions-review), or before a phase is implemented.
product-apps-decomposition
Use when planning how to structure a product — deciding whether to build one large app or several focused apps. Gives generic decomposition guidance always (reliability + token economy), and steers to the specific app breakdown when docs/<app>/product.md defines one. Do NOT use for single-file edits or for app-internal component structure.
product-docs-first
Use when starting a new app and the operator wants product documentation designed before code, OR docs/<app>/product.md exists. Ingests operator research and the North Star, then designs per-app product docs that planning builds from. If no product.md exists and the operator did not ask to create one, this skill does nothing (silent no-op) — do NOT auto-create. Not for mid-implementation edits.
project-onboarding
Use when the operator wants to set up / optimize THIS project for their vision — onboard the project, capture the North Star, define audience, or run the discovery interview. Triggers on "/onboard", "onboard my project", "set up my project", "capture my vision", "set my north star". Product-Owner-owned. Creates project artifacts (docs/north-star.md, fills AGENTS project-values). Do NOT use for ordinary ticket work, for writing application code, or to auto-run on install — it is operator-triggered only.
release-deploy-reporting
Use ONLY when verification passed AND operator explicitly says "prepare deploy" / "draft deploy" / "ship it"; drafts deploy handoff, captures deploy hash + probes + smoke, advises spec DRAFT→DONE flip. Do NOT auto-invoke; operator triggers explicitly.
repo-onboarding-context-map
Use on first Fusebase Flow install, opening an unfamiliar repo, or after major restructuring; produces durable context map (commands, structure, protected paths, risky boundaries). Do NOT use for routine ticket investigation.
requirements-specification
Use when operator starts a new ticket ("ship X", "build Y", "add feature", "fix workflow") and no spec exists; produces spec, clarify questions, acceptance criteria. Do NOT use for code edits, mid-flight reorgs, or after a spec is locked.
role-discipline
ALWAYS load at session start. Apply the section matching your self-attested role (Product Owner / AI Developer / Architect / Deploy phase). Contains role-specific don't-list, exact refusal phrasing for FR violations, and pointers to recovery procedures. Mandatory; not on-demand.
security-permissions-review
Use when changes touch auth, permissions, secrets, env files, deploy config, external messages, data export/import, production DB writes, or customer-visible behavior; surfaces sensitive-path findings + approval-required list. Do NOT use as general code review.
skill-authoring
Use when the operator asks to create, update, import, analyze, or preserve a reusable skill or recurring instruction pattern. Do NOT use for one-off ticket work, ordinary code implementation, problem-catalog incidents, or copying external skill text verbatim.
smoke-testing
Use when Product Owner defines smoke prompts or deploy handoffs, and when AI Developer / Deploy phase executes post-deploy smoke. Do NOT use for pre-deploy unit/integration/source gates alone; smoke means proving the operator-visible outcome on the deployed surface with ground-truth diagnostics.
task-delegation
Use when the operator explicitly asks for delegation, subagents, parallel agents, or when an AI Developer has independent T-task slices that can safely run in parallel. Do NOT use for simple edits, immediate blocking work, deploy commands, production side effects, or Product Owner code-writing.
validation-and-qa
Use when code changes need a gate report, operator asks "is this ready?", or a single observed failure needs reproducibility check; runs lint/typecheck/tests, smoke, probes, reproducibility-before-fix. Do NOT approve deploy (that's release-deploy-reporting).
zoom-out
Use before committing a bug fix or improvement, when a fix is non-trivial, or when the same area has been patched before. Operationalizes FR-20 — zoom out to root cause before applying a narrow patch. Do NOT use for trivial typo/format edits, for net-new feature work with no prior code (nothing to zoom out from), or as a substitute for reproduce-before-fix (FR-10 / validation-and-qa).
fusebase-dashboards
How to use MCP for working with Fusebase dashboards during LLM development. Use when: 1. Discovering dashboards, views, schema via MCP; 2. Creating or updating dashboards/views; 3. Reading/writing dashboard data; 4. Working with relations, filters, templates, child tables; 5. Working with managed databases (e.g. meetings, companies, deals) — load prompts_search({ groups: ["managedDatabases"] }) and see references/meetings.md, references/companies.md, references/deals.md.
fusebase-gate
How to use MCP for Fusebase Gate. Use when: working with gate contracts, tokens, org user listing, health, or generated MCP tools and prompts.
api-exploration
Workflow for testing Fusebase API calls interactively using temporary tokens. Use when: 1. You need to verify an API endpoint behavior before writing app code, 2. You want to explore available API responses or schemas, 3. You're unsure how an API endpoint works and need to test it, 4. Debugging API integration issues by making direct calls.
app-backend
Guide for adding a backend layer (REST API, WebSockets, cron jobs) to Fusebase Apps apps. Use when: (1) An app needs a server-side API beyond the Dashboard SDK, (2) Adding REST endpoints or WebSocket support, (3) Setting up the backend/ folder structure, (4) Scheduling cron jobs for periodic tasks. The backend is OPTIONAL — only add when the app genuinely requires server-side logic.
app-business-docs
Maintain docs/en/business-logic.md in English — human-readable business logic, main user flows, scenarios, and edge cases. Use after domain or workflow code changes, or when revalidating the app during debugging.
app-dev-practices
Practical guide for building Fusebase Apps apps. Use when: (1) Creating a new app, (2) Setting up project structure, Vite config, or authentication, (3) Building or registering apps, (4) Configuring permissions or public access, (5) Navigating between apps, (6) Fetching user details, (7) Troubleshooting build issues.
app-secrets
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.
app-sidecar
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.
app-ui-design
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.
dev-debug-logs
Use when debugging an app through `fusebase dev start`, or when you need to inspect browser logs, proxied API traffic, frontend dev server output, or backend output captured by the local CLI. Explains where logs are written and which file to inspect for each symptom. This is for LOCAL DEVELOPMENT only - for deployed apps, use the remote-logs skill instead.
fusebase-cli
Complete guide for using the Fusebase CLI (fusebase) tool to initialize, develop, and deploy Fusebase Apps apps. Use when: 1. Initializing new Fusebase Apps projects, 2. Creating or configuring apps, 3. Running apps locally or deploying them 4. Setting up app permissions for dashboards.
git-workflow
General Git workflow for generated apps: safe local commits, clean history, and rollback guidance. Includes strict debug/deploy traceability section when git-debug-commits flag is enabled.
handling-authentication-errors
Required implementation pattern for handling AppTokenValidationError (401) responses when app tokens expire. Use when: 1. Building any Fusebase Apps app that makes API calls, 2. Implementing authentication error handling, 3. Creating AuthExpiredModal components, 4. Setting up global error handlers in App.tsx. All apps MUST implement this pattern to handle token expiration gracefully.
mcp-gate-debug
After Fusebase Gate MCP tool sessions, produce a concise debug-oriented summary — what went smoothly, what did not, and actionable improvements to fusebase-gate skills, prompts, or MCP server behavior. Prioritize isolated SQL/NoSQL store flows.
remote-logs
Use when debugging a deployed app backend. Explains how to fetch build logs and runtime logs using the `fusebase remote-logs` command. Only applicable to apps with a backend/ folder. For local development, use dev-debug-logs skill instead.
app-routing
Guide for implementing client-side routing in Fusebase Apps apps. Use when: 1. Adding routing (React Router) to an app, 2. Fixing broken routes or 404s after deployment, 3. Configuring the router.
file-upload
Canonical low-level Fusebase file upload lifecycle and file API guide. Use it when implementing temp -> stored -> display URL flows or building file descriptors for downstream apps.
fusebase-portal-specific-apps
How to develop apps that show different information based on the portal where they are embedded. Use when a task requires showing different data depending on the parent portal
managed-integrations
Guide on creating connections to third-party services and integrating them into apps. Use when a user requests functionality involving communication with third-party services
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.