Agent skill
dashboard
Use this skill when contributing to InsForge's shared dashboard package. This is for maintainers editing `packages/dashboard`, which ships in `self-hosting` and `cloud-hosting` modes, and the local `frontend/` shell used for `self-hosting` in this repo.
Install this agent skill to your Project
npx add-skill https://github.com/InsForge/InsForge/tree/main/.codex/skills/insforge-dev/dashboard
SKILL.md
InsForge Dev Dashboard
Use this skill for dashboard work in the InsForge repository.
Scope
packages/dashboard/src/**packages/dashboard/package.jsonpackages/dashboard/README.mdpackages/dashboard/*.config.*frontend/src/**frontend/package.json
Working Rules
-
Respect the shared-package versus host-app boundary.
- This dashboard is built with React and TypeScript.
packages/dashboard/is the source of truth for the dashboard product.- The package must support both
self-hostingandcloud-hostingmodes. - Keep self-hosting-only bootstrap, local env defaults, and shell styling in
frontend/. - Do not let
packages/dashboard/depend onfrontend/. - If both modes need a capability, define it in the package API first.
-
Preserve dashboard data-flow conventions.
- Follow the flow
service -> hook -> UI. - Use
apiClientfor HTTP calls so auth refresh and error handling stay consistent. - Put request logic in services, data fetching and mutation state in hooks, and rendering/orchestration in UI components and pages.
- Reuse existing contexts, host abstractions, and hooks before creating new global state.
- Follow the flow
-
Reuse the existing component layers.
- Use
@insforge/uifor generic primitives. - Use shared dashboard components when the pattern is already present.
- Keep reusable dashboard UI in
packages/dashboard/. - Only add UI to
frontend/when it is specific to the local self-hosting shell. - Keep package styles scoped to the dashboard container.
- Use
-
Keep the package surface aligned with shared contracts.
- Import cross-package types and Zod-derived shapes from
@insforge/shared-schemas. - When backend payloads change, update the related services, hooks, UI, and exported types together.
- Keep
packages/dashboard/src/index.tsandpackages/dashboard/src/typesaligned with the public package API. - Never use the TypeScript
anytype. Prefer precise prop, state, API, and hook result types.
- Import cross-package types and Zod-derived shapes from
Local debug: viewing cloud-hosting-only UI in self-hosting
Use when previewing UI gated on useIsCloudHostingMode(), isInsForgeCloudProject(), or a PostHog feature flag (e.g. the CTest dashboard variant, dashboard-v3-experiment === 'c_test', the CLI connect panel) while running the local frontend/ self-hosting shell.
The lowest-friction approach is to temporarily hardcode the three gates below to true/the new branch, then restart the Vite dev server. These edits bypass real host/project detection and MUST be fully reverted before committing — landing them breaks both self-hosting and cloud-hosting users.
Hardcodes
packages/dashboard/src/lib/config/DashboardHostContext.tsx—useIsCloudHostingMode()→return true;(wasuseDashboardHost().mode === 'cloud-hosting').packages/dashboard/src/lib/utils/utils.ts—isInsForgeCloudProject()→return true;(was the.insforge.apphostname check).- If the UI is also feature-flag-gated, hardcode the consumer. For CTest:
AppRoutes.tsx→const DashboardHomePage = CTestDashboardPage;and, if relevant, the matching branch inAppLayout.tsxfor<ConnectDialogV2>.
Mark every hardcode with a trailing // LOCAL DEBUG: <original expression> comment so revert is a mechanical search.
Revert checklist — run all before committing
git grep -n "LOCAL DEBUG" packages/dashboard/src/returns zero matches.- Each gate is restored to its original expression, not just an equivalent value (the
mode === 'cloud-hosting'comparison, the hostname check, thegetFeatureFlag(...)call must all be back). - Any imports deleted during debug (commonly
DashboardPage,getFeatureFlag,ConnectDialog) are restored. cd packages/dashboard && npm run lint && npm run typecheckboth pass.git diffof the four files above shows only intended changes — noreturn true;, no missing imports.
Rationalizations to reject
| Excuse | Reality |
|---|---|
| "I'll revert in a follow-up PR." | Follow-up = a window where prod is broken. Revert now. |
| "The original check was effectively the same." | If it were, you wouldn't have needed the hardcode. Restore the expression, not a value-equivalent. |
| "Lint passed, so the deleted import doesn't matter." | Lint passed because the import was deleted; on revert the original code needs it back. |
| "I'll ship the env-var override instead." | No env-var override is wired in the code. Don't invent one on the commit path — restore the original. |
Validation
cd packages/dashboard && npm run typecheckcd packages/dashboard && npm run buildcd frontend && npm run buildwhen the local self-hosting shell changes
For shared contract changes, also validate packages/shared-schemas/ and the affected backend surface.
Didn't find tool you were looking for?