Merge branch 'ganastasov/add-agents' into simenoff/theming-agent-rules

Author: georgianastasov

.github/README.md

@@ -39,8 +39,6 @@ Check the relevant skill file for component APIs and patterns:
 - 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 in full** before modifying any component code.
-
 ---
 
 ## GREEN Phase — Fix the Bug

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

@@ -147,7 +147,13 @@ projects/igniteui-angular/core/src/core/styles/   ← component SCSS themes
 
 Run `npm start` if the bug involves UI behavior or user interaction to visually confirm the issue.
 
-### Step 2 — Present a Scope Summary
+### Step 2 — Request Missing Context
+
+If the report is missing information needed to reproduce or scope the bug safely, pause and ask for the missing context before routing any work.
+
+Keep the follow-up short and specific.
+
+### Step 3 — Present a Scope Summary
 
 Present a brief scope summary to the user:
 
@@ -166,7 +172,7 @@ Wait for user confirmation.
 If a demo/sample is relevant, ask explicitly:
 `Do you want a demo/sample update for this change? Yes / No`
 
-### Step 3 — Route Work
+### Step 4 — Route Work
 
 Delegate work only through isolated subagent execution when available. If isolated subagents are not available in the current environment, stop after investigation and require specialist work to continue in a new chat session with minimal context.
 
@@ -192,11 +198,11 @@ If the user declined, skip that handoff and continue with the remaining agents.
 
 If the bug is purely in theming or styling, route directly from `tdd-test-writer-agent` to `theming-styles-agent` and skip the general implementer.
 
-### Step 4 — Verify Completeness
+### Step 5 — Verify Completeness
 
 After all agents finish, check:
 
-- Does the failing test now pass?
+- Does the newly added failing test now pass?
 - Were all affected areas covered?
 - Were public exports preserved or updated?
 - Were theming and style changes delegated when SCSS or theme wiring was affected?
@@ -225,7 +231,7 @@ Report what was done and any remaining items.
 
 ## Multi-branch Fixes
 
-When a bug exists in multiple release branches:
+When a bug exists in multiple supported release branches:
 1. Target the fix at the **oldest affected branch** first.
 2. Cherry-pick the commit to each newer branch up to and including `master`.
 3. Create separate PRs for each cherry-pick.

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

@@ -106,6 +106,12 @@ Add JSDoc on every new or changed public member with `@param`, `@returns`, and `
 
 ---
 
+## Agent Skills
+
+Update component agent skills if you need to guide other agents on how to use the newly added feature.
+
+---
+
 ## What You Do NOT Do
 
 - Do not modify component SCSS or theme infrastructure — the `theming-styles-agent` handles that.

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

@@ -132,7 +132,13 @@ projects/igniteui-angular/core/src/core/styles/   ← component SCSS themes
    - Whether styles or component themes are affected
    - Which test suite to use (grid vs non-grid)
 
-### Step 2 — Present a Scope Summary
+### Step 2 — Request Missing Context
+
+If the request is missing information needed to discover scope safely, pause and ask for the missing context before routing any work.
+
+Keep the follow-up short and specific.
+
+### Step 3 — Present a Scope Summary
 
 Present a brief scope summary to the user:
 
@@ -150,7 +156,7 @@ Wait for user confirmation.
 If a demo/sample is relevant, ask explicitly:
 `Do you want a demo/sample update for this feature? Yes / No`
 
-### Step 3 — Route Work
+### Step 4 — Route Work
 
 Delegate work only through isolated subagent execution when available. If isolated subagents are not available in the current environment, stop after scope discovery and require specialist work to continue in a new chat session with minimal context.
 
@@ -183,7 +189,7 @@ 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.
 
-### Step 4 — Verify Completeness
+### Step 5 — Verify Completeness
 
 After all agents finish, check:
 

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

@@ -18,7 +18,7 @@ You create **`ng update` migration schematics** for breaking changes in Ignite U
 
 ## When to Create Migrations
 
-- API removed or renamed
+- API removed, renamed, or deprecated
 - Type or enum member renamed
 - Selector deprecated or changed
 - Component/directive moved to a different entry point

.github/agents/migration-agent.md

@@ -21,24 +21,26 @@ You are an independent specialist, not a plan executor. Read the user's request
 ## How You Work
 
 1. **Read the original request** — understand the real behavior being added, changed, or fixed.
-2. **Read the existing component source and spec files** — understand the current implementation, current coverage, and the best place to extend tests.
-3. **Decide the smallest meaningful test set** — for a small change, prefer **1 or 2 focused tests** that prove different behavior contracts.
-4. **Write the tests** — prefer **2 small meaningful tests that cover different things** over 1 oversized test or many near-duplicate tests.
-5. Add a **third test only** if it proves a clearly distinct contract that the first 1 or 2 tests do not cover.
-6. **Run the tests** — confirm they fail for the intended missing behavior.
+2. **Identify the task type** — determine whether the request is a **bug fix** or a **feature implementation**.
+3. **Read the existing component source and spec files** — understand the current implementation, current coverage, and the best place to extend tests.
+4. **Decide the test scope based on task type** — for a **bug fix**, focus on reproducing the issue and proving the fix with the smallest useful test set; for a **feature implementation**, cover the meaningful contracts of the new behavior while keeping the test set focused.
+5. **Write focused failing tests** that prove the intended behavior.
+6. **Run the tests** — confirm they fail for the intended missing functionality, or for existing functionality that does not function as intended.
 
 You may collapse multiple requirements into fewer tests when one test can prove the contract clearly.
-Do not add extra scenarios or extra tests unless they are explicitly requested, clearly required by the feature contract, or needed for accessibility or backward compatibility.
+
+Do not add extra scenarios unless they are explicitly requested, clearly required by the feature contract, or needed for accessibility or backward compatibility.
 
 ---
 
 ## Rules
 
-1. **Default to the smallest useful test set.**
-   - For a small additive change or bug fix, prefer **1 or 2 focused tests**.
-   - Prefer **2 focused tests that cover different behaviors** over 1 oversized test.
-   - Add a **third test only** if it proves a clearly distinct contract that the first 1 or 2 tests do not cover.
-   - Do **not** write more than **3 new tests total** unless the user explicitly asks for broader coverage.
+1. **Choose test count based on task type.**
+   - For a **bug fix**, prefer **1 or 2 focused tests**.
+   - Add a **third bug-fix test only** if it proves a clearly distinct contract that the first 1 or 2 tests do not cover.
+   - Do **not** write more than **3 new bug-fix tests total** unless the user explicitly asks for broader coverage.
+   - For a **feature implementation**, add the meaningful tests needed to cover the feature contract.
+   - Keep feature test sets focused, avoid unnecessary scenario matrices, and prefer distinct tests over repetition.
 2. **Prefer behavior-focused tests over API existence checks.**
    - Test observable behavior, emitted events, rendered state, or accessibility state.
    - Do not add tests whose only purpose is to verify that a symbol is exported, a member exists, or a property is publicly accessible.
@@ -52,7 +54,7 @@ Do not add extra scenarios or extra tests unless they are explicitly requested,
    - No shared mutable state.
    - No execution-order dependency.
 6. **Never write production code.**
-   - Only test code in this phase.
+   - Only test code in this phase to ensure the test does not give false negatives. The test MUST fail if the functionality is missing, or not behaving as intended.
 
 ---
 
@@ -88,10 +90,11 @@ For bug fixes, write a test that reproduces the broken behavior — it must fail
 
 Default to the smallest useful test set.
 
-- Prefer **1 or 2 meaningful tests** for a small additive behavior or bug fix.
-- Prefer **2 smaller tests that cover different contracts** over **1 large test** that tries to verify everything.
-- Add a **third test only** when it proves a clearly distinct behavior that the first 1 or 2 tests do not cover.
-- **Maximum: 3 new tests total.**
+- For **bug fixes**, prefer **1 or 2 meaningful tests**.
+- For **bug fixes**, add a **third test only** when it proves a clearly distinct behavior that the first 1 or 2 tests do not cover.
+- For **bug fixes**, **maximum: 3 new tests total** unless the user explicitly asks for broader coverage.
+- For **feature implementations**, add the meaningful tests needed to cover the feature contract.
+- For **both** prefer smaller tests that cover distinct contracts over 1 large test that tries to verify everything.
 - Do not generate scenario matrices unless the user explicitly requests broad scenario coverage.
 - Do not split one small behavior into many tiny repetitive tests.
 
@@ -152,9 +155,9 @@ Before finishing:
 
 1. Run the smallest relevant test suite.
 2. Confirm the new tests fail for the intended missing behavior.
-3. Confirm the test set stays small and meaningful:
-   - prefer 1 or 2 tests
-   - add a 3rd only if it proves a clearly distinct contract
+3. Confirm the test set matches the task:
+   - for **bug fixes**, prefer 1 or 2 tests and add a 3rd only if it proves a clearly distinct contract
+   - for **feature implementations**, ensure the tests meaningfully cover the feature without padding or repetition
 4. Confirm you did not write production code.
 
 ---

.github/agents/tdd-test-writer-agent.md

@@ -56,6 +56,7 @@ css-naming-convention.md           ← CSS naming rules
 - Add JSDoc with `@param`, `@returns`, and `@example` on every new public member.
 - Add or update `ng update` migrations for true breaking changes such as removals, renames, moved entry points, selector changes, or incompatible default-behavior changes.
 - Update the component `README.md` when the public API surface changes.
+- Update relevant Agent skills if a change is significant and/or you need to tell other agents how to use the newly introduced feature.
 - Consider demo/sample updates in `src/app/` for user-visible changes.
 - Update `CHANGELOG.md` for new features, deprecations, breaking changes, and notable user-visible fixes when they fit the existing changelog section structure.
 
@@ -120,6 +121,9 @@ Feature implementation is handled by a set of specialized agents in `.github/age
 | `migration-agent` | `migration-agent.md` | Creates `ng update` migration schematics for breaking changes |
 | `changelog-agent` | `changelog-agent.md` | Updates `CHANGELOG.md` following repo conventions |
 
+Feature and bug orchestrators route work in this order:
+TDD → implementer → README (if needed) → migration (if breaking) → changelog (if needed).
+
 ## Commit Message Conventions
 
 When creating or suggesting a commit message, follow this format:

AGENTS.md

@@ -9,6 +9,11 @@ All notable changes for each version of this project will be documented in this
 - `IgxCombo`, `IgxSimpleCombo`
     - Introduced the `selectionChanged` event for both components. The event is not cancelable and is emitted after the selection is committed and the component state is updated.
 
+## 21.1.3
+
+### Security Fixes
+- Bumped `jspdf` dependency to `4.2.1` to address a security vulnerability present in earlier versions.
+
 ## 21.1.0
 
 ### New Features