菜单
Use when debugging a deployed feature backend. Explains how to fetch build logs and runtime logs using the `fusebase remote-logs` command. Only applicable to features with a backend/ folder. For local development, use dev-debug-logs skill instead.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | remote-logs |
| description | Use when debugging a deployed feature backend. Explains how to fetch build logs and runtime logs using the `fusebase remote-logs` command. Only applicable to features with a backend/ folder. For local development, use dev-debug-logs skill instead. |
This skill applies only to features with a backend/ folder. Frontend-only features do not produce remote logs.
When a feature backend has been deployed using fusebase deploy, you can fetch logs from the cloud:
| Context | Command | What It Reads |
|---|---|---|
| Local development | fusebase dev start | Log files in <feature>/logs/dev-*/ |
| Deployed backend | fusebase remote-logs | Cloud build and runtime logs |
If the feature is running locally via fusebase dev start, use the dev-debug-logs skill instead.
Fetch build/deployment logs from the most recent deploy:
fusebase remote-logs build <featureId>
Output includes:
in_progress, failed, finished)Fetch live logs from the running backend:
# Default: last 100 console (stdout/stderr) entries
fusebase remote-logs runtime <featureId>
# Specify tail count (0-300)
fusebase remote-logs runtime <featureId> --tail 200
# Get system logs instead of console logs
fusebase remote-logs runtime <featureId> --type system
Options:
--tail <n> - Number of log entries (0-300, default: 100)--type <type> - Log type: console (stdout/stderr) or system (service/infrastructure logs)Use for:
status: failed)Use for:
console.log debug output from the backendUse for:
backend/ folder — frontend-only features do not produce remote logsfusebase deployfusebase auth| Error | Meaning | Fix |
|---|---|---|
| "No deploy found for AppFeature" | Feature has never been deployed | Run fusebase deploy first |
| "No successful deploy found" | Latest deploy failed | Check build logs, fix, redeploy |
| "Missing resource information" | Deploy metadata incomplete | Redeploy the feature |
Deploy fails → Check build logs:
fusebase remote-logs build
App crashes on startup → Check runtime console logs:
fusebase remote-logs runtime --tail 50
Container keeps restarting → Check system logs:
fusebase remote-logs runtime --type system
No obvious errors → Check more log entries:
fusebase remote-logs runtime --tail 300
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.