菜单
Guide for implementing client-side routing in Fusebase Apps features. Use when: 1. Adding routing (React Router) to a feature, 2. Fixing broken routes or 404s after deployment, 3. Configuring the router.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | feature-routing |
| description | Guide for implementing client-side routing in Fusebase Apps features. Use when: 1. Adding routing (React Router) to a feature, 2. Fixing broken routes or 404s after deployment, 3. Configuring the router. |
Fusebase Apps features are each served from their own subdomain root:
https://{feature-subdomain}.{FUSEBASE_APP_HOST}/
Read FUSEBASE_APP_HOST from the project .env when constructing feature URLs. The feature always owns the full path space from /.
IMPORTANT: Always use path-based routing (
BrowserRouter). Hash-based routing (HashRouter) is forbidden — hash fragments are stripped during redirects (e.g. OAuth, SSO), causing users to lose their navigation state.
Routes work as normal from root:
https://my-feature.{FUSEBASE_APP_HOST}/settings
https://my-feature.{FUSEBASE_APP_HOST}/users/42
import { BrowserRouter, Routes, Route } from 'react-router-dom'
function App() {
return (
<BrowserRouter>
<Routes>
<Route path="/" element={<Home />} />
<Route path="/settings" element={<Settings />} />
</Routes>
</BrowserRouter>
)
}
HashRouter — Forbidden. Hash fragments are dropped on redirects, breaking navigation after OAuth or SSO flows.<Link> component, not raw <a href="/settings">./api — The /api prefix is reserved for the backend when a feature has one. Never create SPA routes under /api/*. See skill feature-backend.Workflow for testing Fusebase API calls interactively using temporary tokens. Use when: 1. You need to verify an API endpoint behavior before writing feature 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.
Guidance for visual design, UI and UX in Fusebase-generated app features. Use when building or refining feature UIs: pages, components, layouts, forms, feedback states, theming, or accessibility. Ensures consistent, clear, and distinctive interfaces using shadcn/ui.
Use when: (1) User wants to set up or improve a debug loop or runbook for the repo, (2) User asks to autonomously test or debug features or runtimes, (3) Building or maintaining DEBUG.md with only verified techniques, (4) User asks to verify or document debug, test, restart, or hot-reload methods for each runtime. Discover and document only proven methods; nothing goes into DEBUG.md until verified.
Use when debugging a feature 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.
Guide for adding a backend layer (REST API + WebSockets) to Fusebase Apps features. Use when: (1) A feature needs a server-side API beyond the Dashboard SDK, (2) Adding REST endpoints or WebSocket support, (3) Setting up the backend/ folder structure. The backend is OPTIONAL — only add when the feature genuinely requires server-side logic.
Practical guide for building Fusebase Apps features. Use when: (1) Creating a new feature, (2) Setting up project structure, Vite config, or authentication, (3) Building or registering features, (4) Configuring permissions or public access, (5) Navigating between features, (6) Fetching user details, (7) Troubleshooting build issues.