القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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.
| name | git-workflow |
| description | 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. |
Use this skill for day-to-day Git work in generated apps:
git status --shortgit rev-parse --abbrev-ref HEAD.env, credentials, or token files.Suggested message patterns:
feat: <why>fix: <why>chore: <why>Preferred shared-history rollback:
git revert <commit_sha>Temporary local rollback during active iteration:
git reset --hard <commit_sha_before_change>Use revert by default on shared branches.
fusebase feature create/update (fusebase.json changes)fusebase skills update (AGENTS.md, .claude/* changes)fusebase config ide / fusebase integrations (IDE MCP config changes)fusebase env create (.env local changes; usually not committed)Always review git status --short after these operations.