/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.
$ npx -y skills add InsForge/InsForge --skill ui --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/ui
Context preview
The summary Claude sees to decide when to auto-load this skill.
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.
SKILL.md
ui.SKILL.mdname: ui
description: 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.
InsForge Dev UI
Use this skill for `packages/ui/` work in the InsForge repository.
Scope
- `packages/ui/src/components/**`
- `packages/ui/src/lib/**`
- `packages/ui/src/index.ts`
- `packages/ui/src/styles.css`
Working Rules
1. Put only reusable primitives here.
- If the component is generic across dashboard features or other InsForge apps, it belongs in `packages/ui/`.
- If it is tightly coupled to one dashboard workflow but should ship to both OSS and cloud hosts, keep it in `packages/dashboard/`.
- If it is only for the self-hosting host app, keep it in `frontend/`.
2. Preserve the package's implementation style.
- Use `class-variance-authority` for variants when appropriate.
- Use the shared `cn()` helper for class merging.
- Follow the existing Radix-wrapper and typed-export patterns.
3. Keep the public surface in sync.
- Export new public components from `packages/ui/src/index.ts`.
- Avoid adding internal-only abstractions to the package surface unless they are meant to be consumed.
- Never use the TypeScript `any` type. Keep component props and exported helpers strictly typed.
4. Validate downstream impact.
- The shared dashboard package consumes this package directly, so UI changes can break `packages/dashboard/` even if `packages/ui/` itself builds cleanly.
Validation
- `cd packages/ui && npm run build`
- `cd packages/ui && npm run typecheck`
Also validate `packages/dashboard/` when the changed component is used in the dashboard, and validate `frontend/` if the host app integration or CSS entrypoints changed.
Read more
name: ui description: 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.
InsForge Dev UI
Use this skill for `packages/ui/` work in the InsForge repository.
Scope
- `packages/ui/src/components/**`
- `packages/ui/src/lib/**`
- `packages/ui/src/index.ts`
- `packages/ui/src/styles.css`
Working Rules
1. Put only reusable primitives here.
- If the component is generic across dashboard features or other InsForge apps, it belongs in `packages/ui/`.
- If it is tightly coupled to one dashboard workflow but should ship to both OSS and cloud hosts, keep it in `packages/dashboard/`.
- If it is only for the self-hosting host app, keep it in `frontend/`.
2. Preserve the package's implementation style.
- Use `class-variance-authority` for variants when appropriate.
- Use the shared `cn()` helper for class merging.
- Follow the existing Radix-wrapper and typed-export patterns.
3. Keep the public surface in sync.
- Export new public components from `packages/ui/src/index.ts`.
- Avoid adding internal-only abstractions to the package surface unless they are meant to be consumed.
- Never use the TypeScript `any` type. Keep component props and exported helpers strictly typed.
4. Validate downstream impact.
- The shared dashboard package consumes this package directly, so UI changes can break `packages/dashboard/` even if `packages/ui/` itself builds cleanly.
Validation
- `cd packages/ui && npm run build`
- `cd packages/ui && npm run typecheck`
Also validate `packages/dashboard/` when the changed component is used in the dashboard, and validate `frontend/` if the host app integration or CSS entrypoints changed.
The all-in-one, open-source backend platform for agentic coding. InsForge gives your coding agent database, auth, storage, compute, hosting, and AI gateway to ship full-stack apps end-to-end.
Repo: InsForge/InsForge
Other skills on insforge.
- /doc-author
Write, edit, and maintain documentation. Use for collaborative drafting, autonomous writing, or improving existing docs. Defaults to collaborative mode where the human makes final decisions. Built by Mintlify.
Open skill - /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.
Open skill - /backend
Use this skill when contributing to InsForge's backend package. This is for maintainers editing backend routes, services, providers, auth, database logic (including RLS-enforced surfaces like storage and realtime), schedules, or backend tests in the InsForge monorepo.
Open 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.
Open skill - /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 `.agents/docs`, SDK integration guides in `docs/sdks`, and OpenAPI specs in `openapi`.
Open skill - /e2e-testing
Use this skill when an InsForge maintainer has finished an OSS repo change and is ready to open, update, or submit the InsForge PR. Runs the release-quality deterministic E2E gate by building a package.json-derived InsForge test image tag, deciding whether sibling agent-e2e
Open skill