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.
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
insforge-dev
Use this skill set when contributing to the InsForge monorepo itself. This is for InsForge maintainers and contributors editing the platform, the shared dashboard package, the self-hosting shell, the UI library, shared schemas, tests, or docs.
ui
Use this skill when contributing to InsForge's reusable UI package. This is for maintainers editing design-system primitives, exports, styles, and package-level component behavior in the InsForge monorepo.
backend
Use this skill when contributing to InsForge's backend package. This is for maintainers editing backend routes, services, providers, auth, database logic, realtime, schedules, or backend tests in the InsForge monorepo.
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.
docs
Use this skill when contributing to InsForge's product documentation in this repository. This is for maintainers editing public docs in `docs/core-concepts`, agent docs in `docs/agent-docs`, SDK integration guides in `docs/sdks`, and OpenAPI specs in `openapi`.
shared-schemas
Use this skill when contributing to InsForge's shared schema package. This is for maintainers editing published Zod contracts, exported types, and shared API payload definitions consumed by InsForge packages in this repo and other InsForge tooling.
Didn't find tool you were looking for?