@imfusion/web-ui 0.5.1-dev.25.gf0207a31 → 0.5.1-dev.3.g8e0a047a

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

@@ -1,165 +0,0 @@
----
-name: imf-web-ui-update
-description:
-  "Update @imfusion/web-ui in a consumer repository: refresh the package and vendored skills, audit and optionally install
-  lifecycle hooks, verify the base update, then audit and optionally migrate affected or custom consumer components in a
-  separate approved commit."
-argument-hint: "[--dry-run] [optional version or reason]"
----
-
-# imf-web-ui-update
-
-Update a repository that consumes `@imfusion/web-ui`. Preserve existing project choices and user work. The workflow has two
-commits: the dependency/tooling update first, then an optional consumer migration. Never commit without a fresh explicit
-approval.
-
-## Rules
-
-- Work from the frontend package root. In a monorepo, inspect package manifests and `git worktree list` first, then choose
-  the frontend package in the active worktree that uses web-ui. Read repository and component instructions before changing
-  files.
-- Detect the package manager from lockfiles. Use npm for `package-lock.json`, pnpm for `pnpm-lock.yaml`, Yarn for
-  `yarn.lock`, and Bun for `bun.lock*`. If multiple lockfiles exist, stop and ask which is authoritative.
-- A dry run is read-only. Do not install, run the installer, format, stage, commit, reset, or clean. Report what would run.
-- Record the initial `git status --short`. Existing changes are held back, never staged or overwritten.
-- A dirty file that the workflow needs to modify is a conflict. Stop and report it. This includes package files, installed
-  skill directories, the `AGENTS.md` installer fence, hook files, and hook settings.
-- Do not hand-edit installer-owned skills, the `AGENTS.md` fenced block, or installer-owned hook files.
-- Keep the base update and consumer migration in separate commits. Do not begin the migration audit until the base update
-  commit is complete.
-- Treat the installed package version before the update as the comparison baseline. There is no assumed changelog.
-- A migration candidate is a custom consumer implementation whose behavior overlaps with a current web-ui component, or an
-  existing web-ui usage affected by changed types or documented API. Do not infer a replacement from a name alone; inspect
-  the implementation and the current component documentation/types.
-
-## Preflight
-
-1. Select the frontend package in the active worktree and read its instructions, `package.json`, and lockfile.
-2. Check whether `@imfusion/web-ui` is already declared and record its installed/version-marker version.
-3. Record the worktree status and identify files the update would touch.
-4. Inspect `.agents/skills/`, `.claude/skills/`, the `AGENTS.md` fence, `.claude/settings.json`, and `.agents/hooks/`.
-5. Check for another package-manager process. Stop on any conflict or ambiguous target.
-
-## Base update
-
-In a non-dry run, update the dependency with the detected manager:
-
-```sh
-npm install @imfusion/web-ui
-```
-
-Use the equivalent command for another detected manager. Pass an explicit version only when the user supplied one. Do not use
-`--force` or `--legacy-peer-deps` to make installation pass. Stop on install failure.
-
-Then refresh the existing web-ui skill target:
-
-```sh
-npx web-ui-install --skills
-```
-
-Use the detected manager's runner for non-npm projects. Preserve the existing target (`.agents`, `.claude`, or both); do not
-silently choose a new one. Stop on malformed settings or installer conflicts.
-
-## Hook audit
-
-Audit these responsibilities separately: session start, prompt submit, and post-edit verification.
-
-- If current web-ui hooks cover a responsibility, do not reinstall it.
-- If no equivalent hook exists and the installer-owned destination is clean, ask whether to run:
-
-  ```sh
-  npx web-ui-install --hooks
-  ```
-
-  Run it only after the user accepts. Use the detected runner otherwise.
-
-- If another hook covers a responsibility, do not stack a duplicate. Report the overlap and ask whether to leave hooks alone
-  or adapt the existing hook in a separate approved change.
-- Invalid settings or dirty installer-owned hook files are conflicts. Stop and ask for resolution.
-
-A declined hook offer is valid. Report `hooks: skipped by user` and continue.
-
-## Verification
-
-After each mutating command, compare `git status --short` with the preflight snapshot.
-
-Classify paths as:
-
-- **Update-owned:** package files and installer-owned files changed by this workflow.
-- **Held back:** pre-existing user changes, excluded from the commit.
-- **Conflict:** an overlapping pre-existing change, ambiguous target, or unexpected changed path.
-
-On conflict, stop. Never use `git restore`, `git reset`, `git clean`, or broad staging to hide it.
-
-Run the frontend package's documented full verification after the base update. Read its `package.json` scripts and choose
-commands that cover typechecking, linting, tests, and building. Prefer one documented aggregate `verify`/`check` script when
-it covers those responsibilities; otherwise run the documented non-watch scripts for the responsibilities that exist. Do not
-invent script names or run watch/dev scripts. A type or build failure is a base-update conflict to resolve before the base
-commit, not a migration finding to defer.
-
-Verify the dependency/lockfile, current skill markers, the `AGENTS.md` fence, hook coverage, and the final path list. In
-dry-run mode, say that mutation-dependent checks were skipped.
-
-## Base update report and approval
-
-Before the base commit, show this concise report:
-
-```text
-@imfusion/web-ui update report
-Package      : <old> -> <new> / would update
-Skills       : <status>
-Hooks        : <status>
-Verification : <status>
-Update files : <paths>
-Held back    : <paths or none>
-Conflicts    : <paths or none>
-Commit       : <imperative message or not proposed>
-```
-
-Normal mode: ask exactly, **“Approve these update-owned changes and commit them?”** Do not commit without an affirmative
-answer. If denied, leave the changes uncommitted.
-
-Dry-run mode: state **“Dry run complete; no changes or commit were made.”** Do not mutate or ask for commit approval.
-
-## Consumer migration audit
-
-Begin this phase only after the approved base update has been committed. Record the old and new package versions from the
-pre-update and current manifests/lockfile. Use the current package's exported types, generated documentation, and component
-examples as the source of truth. Use the old version's package metadata or repository history when available to identify what
-changed; do not pretend a changelog exists.
-
-Run the same documented full verification again after the base commit. Separate findings into:
-
-- **Compatibility fixes:** existing web-ui imports, props, or usage patterns that no longer typecheck, build, lint, or pass
-  tests.
-- **Changed component usages:** existing components whose current API, behavior, or documented contract changed between the
-  two versions and may need a consumer update, even when the typecheck passes.
-- **Replacement candidates:** custom consumer components, wrappers, or field implementations that overlap with a component
-  now exported by `@imfusion/web-ui`. Inspect their code, styles, and call sites before suggesting a replacement. Include the
-  current custom implementation, the proposed web-ui component, the relevant API/type evidence, and any behavior or styling
-  that still needs to be preserved.
-
-Report these findings separately from the base update. Ask whether to apply the proposed migration. If the user declines,
-leave the consumer code unchanged. If accepted, make only the approved migration changes, run the documented full
-verification again, and show a second report with the migration paths, held-back paths, conflicts, and verification result.
-
-If no findings exist, report that the installed update has no detected compatibility fixes, changed usages, or replacement
-candidates. Do not create an empty migration commit.
-
-## Migration approval
-
-Ask exactly, **“Approve these consumer migration changes and commit them separately?”** Do not commit without an affirmative
-answer. The migration approval is not implied by approval of the base update.
-
-## Commit
-
-For the base update, after approval:
-
-1. Recheck status and exclude held-back paths.
-2. Stage base update-owned paths selectively. Never use `git add .` or `git add -A`.
-3. Run the repository's commit workflow if it has one, including its required verification and documentation audit. Otherwise
-   run documented verification and follow the repository's commit convention.
-4. Commit with a concise imperative message and confirm the commit and final status.
-
-For an approved migration, repeat the same selective staging and documented commit workflow with a separate imperative
-message. Never bypass hooks or amend an unrelated commit after a hook failure.