Menu
How to develop apps that interact with Fusebase portals where they are embedded. Use when a task requires showing data based on the current parent portal or listing portal pages where the current app is embedded.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use ONLY when the operator runs "/find-wasted-code" (or explicitly asks to "scan the repo for dead-end tool calls / broken links / missing helpers / footgun configs / silent push-through"). Statically scans THIS repo for friction footguns and writes a tracked report to docs/wasted-code/report.md. Manual-trigger ONLY — do NOT auto-invoke; the skill carries disable-model-invocation and no hook wires it. Read-only except the one report write. Findings are review candidates, never auto-fixes. Do NOT use for token/transcript economy (/token-waste-audit), for process ceremony (/find-wasted-effort), or for CLI/Flow drift health (/fusebase-health).
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.
ALWAYS load at session start. After self-attesting, Read references/<role>.md for your role (Product Owner / AI Developer / Architect / Deploy phase) — role-specific don't-list, exact refusal phrasing for FR violations, and recovery pointers; shared cross-role protocols live in this file. Mandatory; not on-demand.
Use when the operator types /product-owner, asks to activate Product Owner, start a Product Owner or PO session, or searches /product in Codex for Fusebase Flow project management. Do NOT use for implementing code; route implementation to the AI Developer role.
Use when planning tasks that touch big source files, when an edit would push a file past the module-size ceiling, when the pre-commit module-size ratchet warns or blocks, or when generating policies/module-size-baseline.txt. Operationalizes FR-25 — module-size ratchet (ceiling default 800; over-ceiling files may shrink, never grow; extraction along a responsibility seam is in-scope, not scope creep). Do NOT use for docs/markdown size (FR-23 owns docs), to force decomposition of an existing monolith (that is its own explicit ticket), or to judge split quality by regex (seam-vs-mechanical is semantic — code-review owns it).
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.
| name | fusebase-portal-specific-apps |
| description | How to develop apps that interact with Fusebase portals where they are embedded. Use when a task requires showing data based on the current parent portal or listing portal pages where the current app is embedded. |
A "portal" is a user-customized website configured in the Fusebase web UI. Portals can display different blocks, including blocks that render apps/apps in an iframe.
In this case, information about the current portal is automatically added to the auth context, so requests from the embedded app/app carry portal information automatically.
When the user asks for an app that should show different information based on the portal where it is embedded, use a Fusebase database table with a view filter that uses the {{CurrentPortal}} dynamic value. See the filters reference in the fusebase-dashboards skill for details.
Important! You should not take a portal ID explicitly as a parameter (query, path, input, etc.); it should be resolved automatically when the view is configured correctly.
Requests for the data in this view automatically receive the current portal in context, and that value is substituted into the view filter.
If you need to add an entry to the table with a portal-based filter, you need to ensure that the row you have created contains the current portal. Get it via the /auth/context request described in the app-dev-practices skill. When the app runs within the portal, the response may contain runtimeContext.portalId. If it is not present, then the app is currently running outside of the portal; therefore, the current portal should not be written to a filter column.
If runtime code needs to show all portal pages where the current app is embedded, use Fusebase Gate from the app runtime:
@fusebase/fusebase-gate-sdk, not MCP.x-app-feature-token.AppEmbedTargetsApi.listAppPortalEmbeds.fusebase app update <appId> --sync-gate-permissions.