@imfusion/web-ui 0.5.1-dev.19.g11b806f9 → 0.5.1-dev.2.g0a349a2a

package/src/llms/skills/imf-web-ui-frontend-setup/SKILL.md

@@ -1,89 +0,0 @@
----
-name: imf-web-ui-frontend-setup
-description:
-  "Set up or audit an ImFusion frontend's project tooling: the stack, package.json scripts, formatting, linting, typecheck,
-  staged-file and pre-commit hooks, verification scopes, dependency pinning, tsconfig, docs structure, agent wiring. House
-  conventions, not industry standards. Load when starting a new ImFusion frontend, when asked what an existing one's setup is
-  missing, when asked to align a repo with the baseline, or when asked to check or set up one named topic from it (e.g. CSS
-  class names, Prettier). Not for a bare 'add this config file' request — that's just the edit. Not for wiring the library
-  itself (imf-web-ui-library-setup)."
-argument-hint: "[new|audit|align|<topic>]"
----
-
-# imf-web-ui-frontend-setup
-
-First-time setup and audit against the ImFusion frontend baseline. The conventions live in `imf-web-ui-frontend-conventions`
-— this skill is the process that checks a repo against them and wires up what they assume. In-house conventions, not industry
-standards: report findings as "missing against the ImFusion baseline", never "against best practice". Built for ImFusion
-frontends; anyone else who likes the baseline can run it too.
-
-Four modes, same checklist:
-
-- **New project** — work down the checklist and set each piece up.
-- **Audit** — read the repo (don't ask what it has), report present / missing / broken, change nothing until the human picks.
-  An established repo is where a forgotten piece hides. **The project wins:** where the repo already decided, that stands —
-  report what's _absent_; a working convention you'd have chosen differently is not a finding.
-- **Align** — when the user asks to _align_ the repo with the baseline ("align"/"alignment" is the flag), the project-wins
-  guard lifts: deviations become migration findings, proposed as a plan, still nothing changed until approved.
-- **One topic** — any other argument names a topic instead of a mode (`class names`, `prettier`, `tooling`). Resolve it to
-  the checklist rows it touches and run the audit process against those only, reading their references as usual. Say which
-  rows you resolved it to before reporting, and if nothing matches, say so and list the rows rather than guessing or sweeping
-  everything. Same output as an audit: findings, nothing changed until the human picks.
-
-**Producer scope.** The web-ui repo itself produces this baseline; it is not a consumer frontend. Consumer-only rows — the
-AGENTS.md fence, vendored-skill staleness, the app stack and app `src/` tree — don't apply there. Audit it against the shared
-rows only: scripts, tooling, git, docs.
-
-## The checklist
-
-Each row is a reference in `../imf-web-ui-frontend-conventions/references/` — read it, then check the repo against it. A
-topic argument narrows this table to the rows it names; every other mode works down all of it.
-
-| Reference              | Set up / audit                                                                              |
-| ---------------------- | ------------------------------------------------------------------------------------------- |
-| `stack.md`             | the dependencies match the topic→tool map; devtools siblings present                        |
-| `npm-project.md`       | script names table, `type`/`private`, exact pins, `.npmrc`, Node pinning                    |
-| `tooling.md`           | Prettier values, ESLint flat config, tsconfig, staged-file runner, readable CSS class names |
-| `git.md`               | `git:config` run and hooks directory present, verify scopes, staleness hooks                |
-| `project-structure.md` | the `src/` tree, file naming, `#/` alias wiring                                             |
-| `components.md`        | component folders and colocation                                                            |
-| `styling.md`           | CSS Modules, tokens, no CSS-in-JS or utility framework                                      |
-| `docs-structure.md`    | docs shape and content rules (see Docs below)                                               |
-| — agent tooling        | delegated to `imf-web-ui-agent-setup` (see Agent tooling below)                             |
-
-## Docs
-
-`README.md`, `AGENTS.md`, and `docs/` with a `docs/index.md` that registers every doc. Scaffold from
-[`templates/README.md`](templates/README.md) and [`templates/AGENTS.md`](templates/AGENTS.md); missing structure is a
-finding.
-
-Keep `AGENTS.md` lean. The decision test for every line: would the agent make a costly mistake without it? If it would just
-need to read a file first, cut it — dev commands, path aliases, and tool config are discoverable from the files themselves.
-
-`AGENTS.md` contains one installer-owned section: the `<!-- imf-web-ui:begin -->` … `<!-- imf-web-ui:end -->` fence.
-`npx web-ui-install` refreshes what's inside on every skills install; everything outside the fence is the repo's own. A
-missing fence in an existing `AGENTS.md` is a finding — without it the baseline note can't be kept current.
-
-Judge existing docs only against `docs-structure.md`: repo-unique content stays, restated baseline becomes a pointer,
-deviations get named as deviations. Don't rewrite a repo's docs uninvited — report, and let the human pick.
-
-## Agent tooling
-
-The agent side — vendored skills and their freshness, the lifecycle hooks, the settings registrations — is
-`imf-web-ui-agent-setup`. Delegate to it: in a new project after the docs step, in an audit as one checklist row (skills
-present and current, hooks wired or consciously adapted). Findings it produces report here like any other.
-
-## Optional
-
-Recommend when the shape calls for it; absence is not a finding.
-
-- **knip** — once several people delete things independently.
-- **`eslint-plugin-jsx-a11y`** — anything user-facing.
-
-Out of scope, project-specific: CI, env and secrets, error tracking, deploy, dependency updates.
-
-## Not this skill
-
-- Library wiring (styles import, provider) → `imf-web-ui-library-setup`
-- The conventions themselves → `imf-web-ui-frontend-conventions` and its references — this skill checks the structure exists,
-  that skill owns what goes inside it

package/src/llms/skills/imf-web-ui-frontend-setup/templates/AGENTS.md

@@ -1,34 +0,0 @@
-# AGENTS.md
-
-<Keep this file lean — target ~50 lines. Decision test for every line: would the agent make a costly mistake without it? If
-it would just need to read a file first, cut it. Dev commands, path aliases, and tool config are discoverable from the files
-themselves.>
-
-<One paragraph: what the app is and the stack in one line.>
-
-Scripts, deps, and setup: [`README.md`](./README.md) and [`package.json`](./package.json) are the source of truth. Check the
-`package.json` scripts before running or suggesting a command — don't infer one exists by pattern-matching a sibling.
-
-## Read before you write
-
-<One bullet per doc in docs/, each with when to read it, e.g.:>
-
-- [`docs/<topic>.md`](./docs/<topic>.md) — <what it covers>. Read before <the change it governs>.
-
-[`docs/index.md`](./docs/index.md) registers all of them.
-
-## Working here
-
-<The fenced block below is the only part of this file `npx web-ui-install` touches: its content comes from this template and
-is refreshed on every skills install. Everything else in the file is scaffolded once by the setup skill and then owned by the
-repo.>
-
-<!-- imf-web-ui:begin — managed by `npx web-ui-install`; edits inside the fence are overwritten -->
-
-`.agents/skills/imf-web-ui-*` is vendored from `@imfusion/web-ui` and resynced with `npx web-ui-install`. Don't edit it and
-don't put repo conventions there. Load the matching `imf-web-ui-*` skill before writing code, styles, data fetching, or docs;
-repo docs hold only what is unique to this repo.
-
-<!-- imf-web-ui:end -->
-
-<Repo-specific agent guidance: generated files that are committed, tools to verify APIs against, things never to touch.>

package/src/llms/skills/imf-web-ui-frontend-setup/templates/README.md

@@ -1,27 +0,0 @@
-# <App name>
-
-<One paragraph: what the app is, the stack in one line — e.g. "Vite + React 19 + TanStack Router (file-based, CSR) + TanStack
-Query + @imfusion/web-ui".>
-
-## Install
-
-```bash
-npm install
-npm run git:config   # once per clone: hooks path, pull.rebase, merge.ff
-```
-
-<Registry tokens, required services, or other one-time setup. Delete if none.>
-
-## Usage
-
-```bash
-npm run dev
-```
-
-<Environment specifics: proxies, .env files, ports. Delete if none.>
-
-`npm run` lists every script; `package.json` is the source of truth. `verify:full` is the CI gate.
-
-## Docs
-
-[`docs/index.md`](./docs/index.md) registers them.

package/src/llms/skills/imf-web-ui-library-setup/SKILL.md

@@ -1,36 +0,0 @@
----
-name: imf-web-ui-library-setup
-description:
-  "One-time wiring of a consumer project: the @imfusion/web-ui styles import and WebUIProvider wrapper. Load when installing
-  the library for the first time, or when components render unstyled or without theme context."
----
-
-# imf-web-ui-library-setup
-
-This is library wiring: the styles import and the provider. It applies to anyone using `@imfusion/web-ui`.
-
-If the project is an **ImFusion** frontend and this is first-time setup, mention once that `imf-web-ui-frontend-setup` sets
-up or audits the repo's tooling (formatting, linting, hooks, scripts) against the ImFusion baseline, and let the human
-decide. Offer it; never run it uninvited, and don't raise it again if they pass — the library works fine without any of it.
-
-Every consumer entry point needs exactly two lines, in this order:
-
-```tsx
-import "@imfusion/web-ui/styles.css";
-import { WebUIProvider, Button } from "@imfusion/web-ui";
-```
-
-Wrap the app root in `<WebUIProvider>` once. Components rendered outside it won't have the theme/CSS-variable context they
-expect.
-
-Never import a Base UI (or other upstream) stylesheet or component directly — everything a web-ui component needs is already
-inside `styles.css` and the package's own exports; reaching around web-ui to the upstream library is always wrong, even if
-the upstream docs show it that way.
-
-## Symptoms of a broken setup
-
-- **Components render but look unstyled** — the `styles.css` import is missing from the entry point.
-- **Components render but ignore the theme (wrong colors, no CSS variables resolving)** — they're mounted outside
-  `<WebUIProvider>`.
-- **An integration component throws on import** — its optional peer dependency isn't installed; check the component's
-  description in the docgen index (`imf-web-ui-components`) for which peer to add to your `package.json`.