fix(agents): address comments

Author: georgianastasov

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

@@ -96,6 +96,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.
+
+---
+
 ## Final Self-Validation
 
 Before finishing:

.github/agents/migration-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/tdd-test-writer-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.
 
 ---

AGENTS.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.