@imfusion/web-ui 0.5.1-dev.53.gb710322e → 0.5.1-dev.6.g9d275fa8

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

@@ -1,157 +0,0 @@
----
-name: imf-web-ui-update
-description:
-  "Update @imfusion/web-ui in a consumer repository: refresh the package, vendored skills, and 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]"
-allowed-tools: Bash Read Grep
----
-
-# 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.
-- This workflow uses npm. `package-lock.json` is the expected lockfile. Another lockfile is a conflict: stop and ask.
-- 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 `package-lock.json`.
-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 npm process. Stop on any conflict or ambiguous target.
-
-## Base update
-
-In a non-dry run, update the dependency:
-
-```sh
-npm install @imfusion/web-ui
-```
-
-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 and lifecycle hooks:
-
-```sh
-npx web-ui-install
-npx web-ui-install --hooks
-```
-
-Run these from the consumer package root, the directory holding the `node_modules` that the dependency install just wrote.
-`npx` resolves `web-ui-install` from the installed `@imfusion/web-ui` there; from any other directory it cannot find the
-binary. Preserve the existing target (`.agents`, `.claude`, or both); do not silently choose a new one.
-
-Always run both installer commands after the package update. Skills and installer-owned hook scripts may have changed even
-when their existing registrations already cover session start, subagent start, prompt submit, and the stop gate. The hook
-installer refreshes those scripts wholesale, prunes retired scripts and their registrations, and merges registrations
-idempotently into both host files (`.claude/settings.json` and `.codex/hooks.json`). Stop on malformed settings or installer
-conflicts.
-
-## 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.
-
-Whatever the migration outcome, close the phase by asking whether to run `imf-web-ui-audit full`: an update can shift the
-baseline (new components, hooks, conventions), and the audit shows where the project now stands against it. Run it only on an
-explicit yes.
-
-## 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.