Merge branch 'master' into didimmova/update-splitter

Author: simeonoff

.github/AGENTS-README.md

@@ -401,15 +401,32 @@ CHANGELOG.md                                      root changelog
 src/app/<component>/                              demo pages
 ```
 
-The system also relies on repository-specific guidance in:
+The system also relies on repository-specific guidance and internal operational skills in:
 
 ```text
 .github/copilot-instructions.md
 skills/igniteui-angular-components/SKILL.md
 skills/igniteui-angular-grids/SKILL.md
 skills/igniteui-angular-theming/SKILL.md
+.github/skills/igniteui-angular-build/SKILL.md
+.github/skills/igniteui-angular-testing/SKILL.md
+.github/skills/igniteui-angular-linting/SKILL.md
 ```
 
+Repository-specific skills for implementation guidance:
+
+- `igniteui-angular-components` — shared guidance for general component patterns, structure, and repository conventions.
+- `igniteui-angular-grids` — shared guidance for grid architecture, patterns, and grid-specific implementation work.
+- `igniteui-angular-theming` — shared guidance for SCSS structure, theme wiring, and style-system conventions.
+
+The internal operational skills are shared references for repository commands and validation flow:
+
+- `igniteui-angular-build` — build command reference for full and partial builds such as library, schematics, migrations, elements, i18n, and related repo build targets.
+- `igniteui-angular-testing` — test suite selection guide, Karma config mapping, and command reference for choosing the smallest relevant test run.
+- `igniteui-angular-linting` — lint command reference, ESLint and Stylelint config locations, and lint expectations before work is considered complete.
+
+Orchestrators should use these skills for command selection instead of repeating command lists inline.
+
 ---
 
 ## Maintenance Notes

.github/CONTRIBUTING.md

@@ -88,38 +88,15 @@ Accessibility is an integral part of any UI component. We as a team are committe
 2. `status: localized` this status is for issues that were with a pending translation status and have already been localized. Place this status label once these translation changes have been included in the current pull request, or the changes are already pulled with a different pull request.
 
 ## Localization (i18n) - applicable to components' string resources
-There are several ways to localize components' string resources:
+There are several ways to localize components' string resources. For more information on how it works, refer to our [Documentation - Localization (i18n)](https://www.infragistics.com/products/ignite-ui-angular/angular/components/general/localization#localization-i18n-1).
 
-1. Using custom resource strings:
-    1.1. Localize a given instance of component - each component which supports localization has input property `resourceStrings`. Setting a newly instantiated object to this property will localize only that given component's instance.
-    1.2. Localize all resources for a component type - each component which supports localization has input property `resourceStrings`. To localize all instances of a given component in the application the following steps should be performed - get the value of the input property `resourceStrings` of the component to be localized; do not create a new instance but replace the existing strings within the object. By default all components of a given type in an application share one instance of the resource strings. Replacing a value in that instance affects all components of that type in the application.
-    1.3. Localize all resources for all components - use global method `getCurrentResourceStrings` to get an object containing current resource strings for all components. To provide localized resources just pass an object of type `IResourceStrings` to the global method `changei18n`.
-    1.4 As of 21.1.x the localization has new implementation and you can use the new API `registerI18n` to register resource string for a component or all components for the whole app, as well as which locale it corresponds to. To localize a single component you will need to get is corresponding resource string keys using one of the available resources and provide only those keys.
+**NOTE** As of 21.1.x, the localization resource strings have been moved to the [`igniteui-i18n`](https://github.com/IgniteUI/igniteui-i18n) repository under `projects/igniteui-i18n-resources`. The package `igniteui-angular-i18n` under `./projects/igniteui-angular-i18n` remains as a source of the localization resources for Ignite UI for Angular, that derives the resources from [`igniteui-i18n`](https://github.com/IgniteUI/igniteui-i18n).
 
-2. Using npm package:
-We've created new repository which will hold the resource strings for languages different than English:
-https://github.com/IgniteUI/igniteui-angular-i18n 
-
-**NOTE** The localization repo has been moved to live inside the `igniteui-angular` repository under `./projects/igniteui-angular-i18n`
-**NOTE** As of 21.1.x the localization resource strings have been moved to the [`igniteui-i18n`](https://github.com/IgniteUI/igniteui-i18n) repository under `projects/igniteui-i18n-resources`.
+**NOTE (21.0.x and lower)** The localization resource strings live inside the `igniteui-angular` repository under `./projects/igniteui-angular-i18n`.
 
 A npm package should be published each time we release new version of Ignite UI for Angular. Its version should correspond to the version of the igniteui-angular npm package.
 One could localize an application by importing the corresponding localized resource strings from the localization package (`igniteui-angular-i18n`) and use the methods described in the previous bullet to localize the whole application or part of it.
 
-**Example:**
-
-Inside app.module you can perform:
-```ts
-import { IgxResouceStringsJA } from ‘igniteui-angular-i18n’;
-changei18n(IgxResouceStringsJA);
-```
-
-**Example new API:**
-```ts
-import { ResouceStringsJA } from ‘igniteui-i18n-resources’;
-registerI18n(IgxResouceStringsJA, 'ja');
-```
-
 ### Resource strings keys naming convention
 Each key in the `IResourceStrings` (and `IGridResourceStrings`, `ITimePickerResourceStrings`, etc.) is prefixed with components' selector and followed by the resource string key. Having components' selectors as prefixes allows us to have same resource strings keys for more than one component.
 Example: _igx_grid_groupByArea_message_.

.github/agents/bug-fixing-implementer-agent.md

@@ -114,6 +114,7 @@ If the bug requires SCSS, theme wiring, or style-test changes, do not implement
 - Do not update `README.md` — the `component-readme-agent` handles that.
 - Do not create migration schematics — the `migration-agent` handles that.
 - Do not update `CHANGELOG.md` — the `changelog-agent` handles that.
+- Do not modify dependency manifests or lock files (`package.json`, `package-lock.json`, etc.). Ask for approval first if a dependency change is truly required.
 
 ---
 

.github/agents/bug-fixing-orchestrator-agent.md

@@ -68,6 +68,7 @@ You do NOT write tests, production code, or detailed implementation instructions
 - Do not write tests or production code
 - Do not specify exact test cases, exact implementations, or exact file changes
 - Do not over-constrain the handoff prompts — give scope and root cause, not specs
+- Do not modify dependency manifests or lock files (`package.json`, `package-lock.json`, etc.). Ask for approval first if a dependency change is truly required.
 
 ---
 
@@ -108,16 +109,9 @@ Do not add sections such as:
 
 ---
 
-## Component-Specific Patterns
-
-Check the relevant skill file for component APIs and patterns:
-- Non-grid components → `skills/igniteui-angular-components/SKILL.md`
-- Grid components → `skills/igniteui-angular-grids/SKILL.md`
-- Theming & styling → `skills/igniteui-angular-theming/SKILL.md`
-
-Each skill file is a routing hub pointing to detailed reference files under its `references/` folder. **Read the relevant reference files** when investigating the root cause.
-
-If the bug touches component SCSS or theme wiring, read `skills/igniteui-angular-theming/references/contributing.md` during investigation and plan a dedicated `theming-styles-agent` handoff.
+> Skills:
+> - APIs: `skills/igniteui-angular-{components,grids,theming}/SKILL.md`
+> - Build / test / lint: `.github/skills/`
 
 ---
 
@@ -171,10 +165,15 @@ Present a brief scope summary to the user:
 
 Keep it short and high-level. Confirm scope, not solution details.
 
-Wait for user confirmation.
+Before routing any work, ask:
+
+**`Do you want me to proceed with this implementation flow?`**
+
+If the fix is user-visible, also ask:
+
+**`Do you want a demo/sample update for this feature?`**
 
-If a demo/sample is relevant, ask explicitly:
-`Do you want a demo/sample update for this change? Yes / No`
+Wait for the user's answer before routing work.
 
 ### Step 4 — Route Work
 
@@ -217,6 +216,7 @@ After all agents finish, check:
 - If a demo/sample was requested, was the existing demo structure updated appropriately?
 - If a demo/sample was not requested, was it correctly skipped?
 - Is multi-branch cherry-picking needed?
+- Run `npm run lint:lib` and verify it passes.
 
 Report what was done and any remaining items.
 

.github/agents/changelog-agent.md

@@ -5,6 +5,7 @@ tools:
   - search/codebase
   - edit/editFiles
   - read/problems
+  - web
 ---
 
 # Changelog Agent
@@ -13,6 +14,12 @@ You update `CHANGELOG.md` at the repository root for Ignite UI for Angular. Only
 
 ---
 
+## What You Do NOT Do
+
+- Do not modify production source code.
+
+---
+
 ## Steps
 
 ### 1. Find the Latest Version

.github/agents/component-readme-agent.md

@@ -5,6 +5,7 @@ tools:
   - search/codebase
   - edit/editFiles
   - read/problems
+  - web
 ---
 
 # Component README Agent
@@ -58,7 +59,8 @@ Component documentation is located at:
    - examples when needed
 5. If behavior changed, update the related explanatory text.
 6. If a new capability was added, add a short example only if the README style supports it.
-7. Match existing formatting exactly.
+7. If API was renamed or deprecated, update or remove stale examples and snippets that still reference the old usage.
+8. Match existing formatting exactly.
 
 ---
 

.github/agents/demo-sample-agent.md

@@ -7,6 +7,7 @@ tools:
   - read/problems
   - execute/runTests
   - read/terminalLastCommand
+  - web
 ---
 
 # Demo / Sample Agent
@@ -39,6 +40,7 @@ You do not implement the library change itself, create new samples or demo folde
 - Do not update component `README.md`.
 - Do not update `CHANGELOG.md`.
 - Do not create migrations.
+- Do not modify dependency manifests or lock files (`package.json`, `package-lock.json`, etc.). Ask for approval first if a dependency change is truly required.
 
 ---
 

.github/agents/feature-implementer-agent.md

@@ -8,6 +8,7 @@ tools:
   - read/problems
   - execute/runTests
   - read/terminalLastCommand
+  - web
 ---
 
 # Implementer — GREEN + REFACTOR Phases
@@ -118,6 +119,7 @@ Update component agent skills if you need to guide other agents on how to use th
 - Do not update `README.md` — the `component-readme-agent` handles that.
 - Do not create migration schematics — the `migration-agent` handles that.
 - Do not update `CHANGELOG.md` — the `changelog-agent` handles that.
+- Do not modify dependency manifests or lock files (`package.json`, `package-lock.json`, etc.). Ask for approval first if a dependency change is truly required.
 
 ---
 

.github/agents/feature-orchestrator-agent.md

@@ -6,6 +6,7 @@ tools:
   - search/codebase
   - search/changes
   - read/problems
+  - web
 agents:
   - tdd-test-writer-agent
   - feature-implementer-agent
@@ -64,6 +65,7 @@ You do NOT write tests, production code, or detailed acceptance criteria. Each s
 - Do not write detailed acceptance criteria that downstream agents must encode literally
 - Do not specify exact test cases, exact implementations, or exact file changes
 - Do not over-constrain the handoff prompts — give scope, not specs
+- Do not modify dependency manifests or lock files (`package.json`, `package-lock.json`, etc.). Ask for approval first if a dependency change is truly required.
 
 ---
 
@@ -101,6 +103,12 @@ Do not add sections such as:
 
 ---
 
+> Skills:
+> - APIs: `skills/igniteui-angular-{components,grids,theming}/SKILL.md`
+> - Build / test / lint: `.github/skills/`
+
+---
+
 ## Key Repository Paths
 
 ```
@@ -130,7 +138,7 @@ projects/igniteui-angular/core/src/core/styles/   ← component SCSS themes
    - Whether a migration schematic is needed
    - Whether i18n strings are affected
    - Whether styles or component themes are affected
-   - Which test suite to use (grid vs non-grid)
+   - Which test suite to use (grid vs non-grid vs schematics/styles/i18n)
 
 ### Step 2 — Request Missing Context
 
@@ -151,10 +159,15 @@ Present a brief scope summary to the user:
 
 Keep it short and high-level. Confirm scope, not solution details.
 
-Wait for user confirmation.
+Before routing any work, ask:
+
+**`Do you want me to proceed with this implementation flow?`**
+
+If the feature is user-visible, also ask:
+
+**`Do you want a demo/sample update for this feature?`**
 
-If a demo/sample is relevant, ask explicitly:
-`Do you want a demo/sample update for this feature? Yes / No`
+Wait for the user's answer before routing work.
 
 ### Step 4 — Route Work
 
@@ -181,26 +194,25 @@ Use agents in this order:
 4. **`demo-sample-agent`** — only if the user explicitly wants a demo/sample update
 5. **`component-readme-agent`** — updates affected component `README.md` files
 6. **`migration-agent`** — only if breaking changes exist
-7. **`changelog-agent`** — updates `CHANGELOG.md`
+7. **`changelog-agent`** — only if the change warrants an entry under the existing `CHANGELOG.md` structure
 
 Only invoke `demo-sample-agent` if the user explicitly requested a demo/sample update.
 If the user declined, skip that handoff and continue with the remaining agents.
 
-If the feature is purely theming or styling, route directly from `tdd-test-writer-agent` to `theming-styles-agent` and skip the general
-implementer.
+If the feature is purely theming or styling, route directly from `tdd-test-writer-agent` to `theming-styles-agent` and skip the general implementer.
 
 ### Step 5 — Verify Completeness
 
 After all agents finish, check:
 
 - Were all affected areas covered?
 - Were public exports updated?
-- Were theming and style changes delegated when SCSS or theme wiring was
-  affected?
-- Was the component README updated?
-- Was `CHANGELOG.md` updated?
+- Were theming and style changes delegated when SCSS or theme wiring was affected?
+- Was the component README updated if needed?
+- Was `CHANGELOG.md` updated if needed?
 - Do migrations exist for any breaking changes?
 - If a demo/sample was requested, was the existing demo structure updated appropriately?
 - If a demo/sample was not requested, was it correctly skipped?
+- Run `npm run lint:lib` and verify it passes.
 
 Report what was done and any remaining items.

.github/agents/migration-agent.md

@@ -8,6 +8,7 @@ tools:
   - execute/runTests
   - read/problems
   - read/terminalLastCommand
+  - web
 ---
 
 # Migration Schematic Agent
@@ -28,6 +29,12 @@ You create **`ng update` migration schematics** for breaking changes in Ignite U
 
 ---
 
+## What You Do NOT Do
+
+- Do not modify dependency manifests or lock files (`package.json`, `package-lock.json`, etc.). Ask for approval first if a dependency change is truly required.
+
+---
+
 ## Steps
 
 ### 1. Determine Version and Number
@@ -114,6 +121,7 @@ Before finishing:
 3. Run:
    - `npm run test:schematics`
    - `npm run build:migrations`
+   - `npm run lint:lib`
 4. Confirm the migration updates the old API and leaves unrelated code unchanged.
 
 ### 7. Commit