limitless-angular
diff --git a/.agents/skills/angular-version-support/SKILL.md b/.agents/skills/angular-version-support/SKILL.md
@@ -15,25 +15,36 @@ Before changing files, read
 
 1. Identify the requested Angular major from the user prompt.
    - If no target major is present, ask for the Angular major before mutating files.
-   - Treat prompts like "Angular 20", "v20", and "major 20" as target major `20`.
-2. Use the deterministic helper when the task is to add a stable Angular major:
+   - Recognize forms like "Angular <major>", "v<major>", and
+     "major <major>".
+2. Use the deterministic helper when the task is to add a stable Angular major
+   or move the workspace package manifests to that major:
 
    ```bash
    node .agents/skills/angular-version-support/scripts/add-angular-version.ts --major <major>
    ```
 
-   Use `--dry-run` before applying when the user asks for a preview.
-3. Audit the project-specific compatibility files listed in the reference.
-4. Run the focused validation commands from the reference.
-5. If general Angular coding changes are required, use `$angular-developer` after
+   Use `--dry-run` before applying when the user asks for a preview. Use
+   `--library-only` only when the user explicitly asks not to update demo/e2e
+   app manifests.
+3. Update the lockfile and any Angular-adjacent packages the helper calls out.
+4. Run official Angular migrations where possible before making manual code
+   fixes.
+5. Audit the project-specific compatibility files listed in the reference.
+6. Run the focused validation and workspace test commands from the reference.
+7. If general Angular coding changes are required, use `$angular-developer` after
    the compatibility matrix has been updated.
+8. Report target-version-specific migration failures or fixes in your final
+   output. Add them to this skill only when they describe a durable repo rule.
 
 ## Rules
 
 - Do not use Python for this skill's workflow or bundled scripts.
 - Keep bundled scripts executable with plain Node 22; do not require `tsx`,
   `ts-node`, build steps, or a custom runner.
-- Do not mass-upgrade demo app Angular dependency pins unless the user
-  explicitly asks for a workspace upgrade.
+- Update Angular package pins across workspace apps and packages by default so
+  the repo can install, build, and test against the requested Angular major.
 - Keep stable compatibility rows deterministic: one `floor` row and one
   `latest` row for every supported Angular major.
+- Keep the skill version-neutral. Do not bake in one-off findings from a single
+  target major unless they generalize across future Angular upgrades.
diff --git a/.agents/skills/angular-version-support/agents/openai.yaml b/.agents/skills/angular-version-support/agents/openai.yaml
@@ -1,4 +1,4 @@
 interface:
   display_name: "Angular Version Support"
-  short_description: "Update this repo's Angular support matrix"
-  default_prompt: "Use $angular-version-support to add support for Angular 20."
+  short_description: "Update this repo's Angular support and apps"
+  default_prompt: "Use $angular-version-support to add support for Angular <major>."
diff --git a/.agents/skills/angular-version-support/references/limitless-angular-compat.md b/.agents/skills/angular-version-support/references/limitless-angular-compat.md
@@ -2,8 +2,10 @@
 
 This workspace publishes `@limitless-angular/sanity` and verifies Angular
 support through the private `@limitless-angular/angular-compat` package.
-Adding support for a stable Angular major means updating the public peer range
-and the generated-consumer compatibility matrix.
+Adding support for a stable Angular major means updating the public peer range,
+the generated-consumer compatibility matrix, and every workspace app/package
+manifest that pins Angular packages so the repo can install, build, and test on
+that major.
 
 ## Required Files
 
@@ -17,24 +19,102 @@ and the generated-consumer compatibility matrix.
   - Add `angular-<major>-latest` with `mode: "latest"`.
   - Set `buildAngularMajor` to the newest stable major represented by
     `consumerVersionSets`.
+- Workspace `package.json` files with direct Angular toolchain dependencies
+  - Update direct `@angular/*` dependency and devDependency ranges.
+  - Update direct `@angular-devkit/*` devDependency ranges.
+  - Update direct `angular-eslint` and `ng-packagr` devDependency ranges.
+  - Update demo/e2e app manifests by default; they must run with the requested
+    Angular major unless the user explicitly asks for library-only support.
 
 Use the helper for this deterministic edit:
 
 ```bash
 node .agents/skills/angular-version-support/scripts/add-angular-version.ts --major <major>
 ```
 
-The helper also backfills missing `floor`/`latest` rows for stable Angular
-majors that are already declared by the peer range or compatibility config.
+The helper also updates workspace Angular package pins and backfills missing
+`floor`/`latest` rows for stable Angular majors that are already declared by
+the peer range or compatibility config.
 
 For a preview:
 
 ```bash
 node .agents/skills/angular-version-support/scripts/add-angular-version.ts --major <major> --dry-run
 ```
 
+For explicit library-only support without demo/e2e app manifest upgrades:
+
+```bash
+node .agents/skills/angular-version-support/scripts/add-angular-version.ts --major <major> --library-only
+```
+
 ## Required Audit
 
+After the helper runs, update packages that require registry-specific
+compatibility decisions:
+
+- `typescript`: resolve the version range required by
+  `@angular/compiler-cli@<major>` and update all workspace manifests that pin
+  TypeScript.
+- Angular-adjacent adapters such as `@analogjs/vite-plugin-angular`,
+  `@analogjs/vitest-angular`, and `@testing-library/angular`: inspect current
+  peer compatibility and update when the requested Angular major requires it.
+- `pnpm-lock.yaml`: run `pnpm install` after package manifest edits so the
+  lockfile matches the workspace upgrade.
+
+Do not stop after the helper if any TypeScript, adapter, or lockfile updates
+are still required for the workspace to install and run tests on the requested
+Angular major.
+
+For every target major, treat validation failures as evidence to inspect the
+matching Angular release notes, official migrations, and dependency peer ranges.
+Update code and toolchain packages only when the target major requires it.
+Report target-specific findings in the final output or PR notes so the next
+skill revision can decide whether they are durable enough to encode here.
+
+Do not add new Angular framework dependencies to `packages/sanity` only to
+satisfy transitive peer resolution. Add a framework package only when source or
+tests directly import it, or when the repo intentionally broadens its Angular
+test surface. Otherwise investigate test setup, adapters, and lockfile
+resolution first, then report the exact failure if the fix is unclear.
+
+## Official Angular Migrations
+
+Prefer official Angular migrations before manual code edits. Angular supports
+update automation through `ng update`, and the CLI can run code migrations as
+part of an update.
+
+Use the Angular Update Guide for the current-to-target major pair, then run the
+CLI migrations where this repo has Angular projects:
+
+```bash
+rg --files -g angular.json apps packages
+```
+
+Run app migrations from the workspace root with `pnpm --filter` so Volta and
+pnpm use the repo Node version. Verify the filtered command sees the repo Node:
+
+```bash
+pnpm --filter <workspace-package-name> exec node -v
+```
+
+If the helper already updated package manifests and you only need code
+migrations, run migration-only commands one workspace package at a time. Include
+`--allow-dirty` because the helper and dependency updates make the worktree
+dirty before migrations run:
+
+```bash
+pnpm --filter <workspace-package-name> exec ng update @angular/core --migrate-only --from <from> --to <target> --allow-dirty
+pnpm --filter <workspace-package-name> exec ng update @angular/cli --migrate-only --from <from> --to <target> --allow-dirty
+```
+
+This repo's app-local `angular.json` files may cause some Angular core
+migrations to resolve `../../tsconfig.base.json` incorrectly. If `ng update`
+fails with a tsconfig path error, record the failure, inspect the migration's
+targeted patterns, and manually audit/apply the relevant code changes. Do not
+replace official migrations with manual text edits unless no applicable
+migration is available or the migration fails and the failure is understood.
+
 After the deterministic edit, search for version-specific branches and stale
 contract text:
 
@@ -59,21 +139,18 @@ Treat these as compatibility contract surfaces:
 Do not change these files only because a new major was added. Change them when
 tests reveal a contract drift or when the user asks to update the orchestration.
 
-## Demo App Pins
-
-The demo and e2e Angular apps currently pin their own Angular toolchains. Do
-not upgrade those app dependencies as part of "add Angular support" unless the
-user asks for a workspace or example-app upgrade. The compatibility harness
-builds and tests generated consumers separately from the demo apps.
-
 ## Validation
 
-Run focused validation after updating the support matrix:
+Run focused validation after updating the support matrix and workspace package
+manifests:
 
 ```bash
+pnpm install
 node --test tools/angular-compat/*.test.mjs
 pnpm run compat:assert
 pnpm run compat:matrix
+pnpm run build
+pnpm run test
 ```
 
 For real support changes, also run: