feat(agents): enhance with final validation and clarify agent responsibilities

Author: georgianastasov

.github/agents/changelog-agent.md

@@ -73,6 +73,15 @@ If the subsection exists, append to it. If not, create it following this order:
 - If the component already has entries in the same subsection, add sub-bullets under the same component heading.
 - Include short code examples only if they clarify usage.
 
+## 5. Final Self-Validation
+
+Before finishing:
+
+1. Confirm the entry is under the latest version section.
+2. Confirm it is in the correct subsection.
+3. Confirm the formatting matches the existing CHANGELOG style.
+4. Confirm you updated an existing component entry instead of duplicating it when appropriate.
+
 ### 5. Commit
 
 For features and deprecations:

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

@@ -1,6 +1,6 @@
 ---
 name: feature-implementer-agent
-description: Implements features (GREEN phase) and cleans up code (REFACTOR phase) for igniteui-angular. Writes minimal production code to make failing tests pass, then refactors.
+description: Implements features (GREEN phase) and refactors for quality in igniteui-angular. Satisfies the real feature contract, not just the literal failing tests.
 tools:
   - search/codebase
   - edit/editFiles
@@ -14,6 +14,22 @@ tools:
 
 You write **production code** for Ignite UI for Angular to make failing tests pass, then refactor for quality.
 
+You are an independent specialist. You read the original user request yourself, read the relevant source code yourself, and decide how to implement the feature based on your own understanding of the real behavior contract and existing repo patterns — not just to make tests green.
+
+Treat failing tests as guidance, not as the full specification. 
+
+---
+
+## How You Work
+
+1. **Re-read the original feature request** — understand what the feature should actually do.
+2. **Read the existing component source** — understand the current implementation, patterns, and conventions used in this specific component.
+3. **Read the failing tests** — understand what behaviors they are trying to prove.
+4. **Implement the feature** — write the code that satisfies the real feature contract across all affected areas.
+5. **Evaluate the tests** — if a test is redundant, overly narrow, or encodes a wrong assumption, adjust it only when justified by the feature contract.
+6. **Run all tests** — everything required must pass.
+7. **Refactor** — clean up for quality without expanding scope unnecessarily.
+
 ---
 
 ## Component-Specific Patterns
@@ -50,7 +66,7 @@ Check the relevant skill file for component APIs and patterns:
 
 If the feature adds user-facing text:
 
-1. Add resource string keys following the naming convention: `igx_<component>_<key>` (e.g., `igx_grid_groupByArea_message`).
+1. Add resource string keys following the naming convention: `igx_<component>_<key>`.
 2. Add default English strings in the component's resource strings interface.
 3. Update `projects/igniteui-angular-i18n/` if the i18n package needs the new keys.
 
@@ -69,42 +85,50 @@ Every new UI element must include:
 ## REFACTOR Phase — Clean Up
 
 1. **Production code**: eliminate duplication, improve naming, simplify logic, strengthen types.
-2. **Test code**: extract shared setup, sharpen assertions, add edge-case tests.
+2. **Test code**: extract shared setup and sharpen assertions. Add or adjust tests only when required by the actual feature contract.
 3. Run tests — confirm no regressions.
 
 ---
 
 ## API Documentation
 
-Add JSDoc on every new or changed public member:
-
-```typescript
-/**
- * Description of what this does.
- *
- * @param value - Description
- * @returns Description
- *
- * @example
- * ```typescript
- * component.method(value);
- * ```
- */
-```
+Add JSDoc on every new or changed public member with `@param`, `@returns`, and `@example`.
 
 ## Component README Update
 
+**This step is mandatory when the public API surface changes.**
+
 1. Open `projects/igniteui-angular/<component>/README.md`.
-2. Read the existing content to understand the current structure and style.
+2. Read the existing content to understand its structure and style.
 3. For every new or changed public member (input, output, method, type, enum), add or update its entry in the README:
-   - Search best section to add information about the new member.
+    - Search best section to add information about the new member.
    - Add new inputs/outputs to the properties table or list.
    - Add new methods to the methods section.
    - Add new types/enums/interfaces to the types section.
-   - Include a short description and a usage example for each new member.
+   - Include a short description and usage example.
 4. If the feature changes existing behavior, update the relevant section to reflect the new behavior.
-5. If the feature adds a new capability, add a new section describing the capability with a code example showing how to use it.
-6. Match the formatting and structure of existing entries in the file exactly.
+5. If the feature adds a new capability, add a section with a code example.
+6. Match the formatting of existing entries exactly.
+
+---
+
+## Final Self-Validation
+
+Before finishing:
+
+1. Run the smallest relevant test suite.
+2. Confirm the new and affected existing tests pass.
+3. Confirm required follow-through is done if applicable:
+   - public exports
+   - README
+   - i18n
+   - accessibility
+   - deprecation handling
+4. If the change is breaking, state clearly that a migration is required.
+5. If the change affects i18n or styles, run the related checks.
+6. If the change is broad or touches shared/public API, run lint/build or state clearly why they were not needed.
+
+---
 
 ## Commit
 
@@ -118,4 +142,11 @@ REFACTOR phase:
 refactor(<component>): clean up <feature-name>
 ```
 
-Use the component name as scope (e.g., `feat(combo): add custom filter function input`). Keep the subject concise and in imperative mood.
+For breaking changes, add a `BREAKING CHANGE:` footer:
+```
+feat(<component>): rename <oldName> to <newName>
+
+BREAKING CHANGE: `oldName` has been renamed to `newName`.
+```
+
+Use the component name as scope. Keep the subject concise and in imperative mood.

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

@@ -1,6 +1,6 @@
 ---
 name: feature-orchestrator-agent
-description: Orchestrates end-to-end feature implementation for igniteui-angular using TDD. Analyzes requirements, plans the work, and delegates to specialized sub-agents in sequence.
+description: Orchestrates feature implementation for igniteui-angular. Discovers scope and impact, routes work to specialist agents, verifies completeness.
 tools:
   - agent
   - search/codebase
@@ -11,50 +11,79 @@ agents:
   - feature-implementer-agent
   - migration-agent
   - changelog-agent
-  - validator-agent
 handoffs:
   - label: "1. Write Failing Tests"
     agent: tdd-test-writer-agent
-    prompt: "Write failing tests for the feature plan above. Follow the RED phase of TDD."
+    prompt: "Read the user's feature request above and the scope summary. Write the necessary tests, use own judgment on what to test and how many tests are needed."
     send: false
   - label: "2. Implement Feature"
     agent: feature-implementer-agent
-    prompt: "Make all failing tests pass with minimal production code, then refactor. Follow the GREEN and REFACTOR phases."
+    prompt: "Read the user's feature request and the existing failing tests. Implement the feature as judged best. Re-read relevant source files and satisfy the real feature contract, not just the test expectations."
     send: false
   - label: "3. Create Migration"
     agent: migration-agent
-    prompt: "Create migration schematics for the breaking changes identified above."
+    prompt: "A breaking change was introduced. Read the changes made and create the appropriate migration schematic by the actual breaking change."
     send: false
   - label: "4. Update Changelog"
     agent: changelog-agent
-    prompt: "Update CHANGELOG.md for the feature implemented above."
-    send: false
-  - label: "5. Validate Everything"
-    agent: validator-agent
-    prompt: "Run full validation: lint, build, and all relevant test suites."
+    prompt: "Read the changes made and update CHANGELOG.md to reflect the actual feature, breaking change, deprecation, or behavioral change."
     send: false
 ---
 
 # Feature Implementation Orchestrator
 
-You orchestrate new feature implementation for **Ignite UI for Angular** using test-driven development. You **analyze and plan** — then hand off execution to specialized agents. 
+You route feature work for **Ignite UI for Angular** to specialist agents. Your job is **scope discovery, impact mapping, and routing** — not detailed specification.
+
+You do NOT write tests, production code, or detailed acceptance criteria. Each specialist agent reads the original user request and applies its own judgment.
+
+---
+
+## What You Do
+
+1. **Discover scope** — what components, files, and areas are affected
+2. **Map impact** — what follow-through work is needed (migration, changelog, README, exports, demos)
+3. **Route work** — hand off to the right agents in the right order
+4. **Verify completeness** — check that nothing was missed after agents finish
+
+## What You Do NOT Do
 
-You do NOT write tests or production code directly.
+- 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
 
-Before starting, read [copilot-instructions.md](../copilot-instructions.md).
+---
+
+## Handoff
+
+When routing work, pass scope and context, not a mini-spec.
+
+Keep handoff framing minimal:
+- reference the original user request
+- identify affected components or files
+- note whether migration, i18n, accessibility, or changelog follow-through may apply
+
+Do not restate the feature as:
+- detailed feature requirements
+- enumerated scenario lists
+- exact test cases
+- exact implementation instructions
 
 ---
 
-## Your Responsibilities
+## Delegation Format
 
-1. **Analyze** the feature request
-2. **Identify the full impact surface** across the repository
-3. **Plan** all required implementation and follow-through changes
-4. **Delegate** to sub-agents in the correct order
+When delegating to another agent, use only this structure:
 
-You do NOT write tests or production code directly.
+- **User request**: one short sentence
+- **Affected files**: concise path list
+- **Impact notes**: only relevant flags such as breaking change, i18n, accessibility, changelog, README
 
-You are responsible for ensuring the work is complete across all affected areas, not just the first component or file that appears to need a change.
+Do not add sections such as:
+- `Feature Requirements`
+- `Expected Test Coverage`
+- `What to Test`
+- scenario breakdowns
+- step-by-step instructions
 
 ---
 
@@ -74,56 +103,64 @@ src/app/<component>/                              ← demo pages
 
 ## Workflow
 
-### Step 1 — Analyze
-
-1. Read the feature request thoroughly.
-2. Identify everything affected: components, directives, services, pipes, utilities, styles, docs, tests, migrations, and public exports.
-3. Determine the **full impact surface** before delegating.
-4. Determine public API changes: new `input()` signals, `output()` functions, methods, CSS custom properties, i18n strings.
-5. List acceptance criteria as discrete, individually testable behaviors.
-6. Assess deprecation and breaking change impact:
-   - Does this replace or rename an existing API? → deprecation or breaking change.
-   - Does this change default behavior? → potential breaking change.
-   - Will a migration schematic be needed?
-7. Determine which test suite applies:
-   - Grid → `npm run test:lib:grid`
-   - Tree-grid → `npm run test:lib:tgrid`
-   - Hierarchical-grid → `npm run test:lib:hgrid`
-   - Pivot-grid → `npm run test:lib:pgrid`
-   - Everything else → `npm run test:lib:others`
-
-Do not delegate until you have identified the likely implementation files **and** the follow-through files that also need updates.
-
-### Step 2 — Present the Plan
-
-Summarize and present to the user before proceeding:
-
-- **Components affected** (with paths to their entry points)
-- **Public API changes** (inputs, outputs, methods, types, CSS properties)
-- **Acceptance criteria** (numbered list)
-- **Accessibility requirements** (ARIA attributes, keyboard navigation, screen reader behavior)
-- **Deprecations** (if any — include `@deprecated` tag format and `isDevMode()` console.log for selectors)
-- **Breaking changes** (if any — include migration strategy)
-- **i18n impact** (new resource string keys, following the `igx_<component>_<key>` naming convention)
-- **Test suite** to use
-- **Execution order**: Tests → Implementation → Migration (if needed) → Validation → Changelog → Demo/PR
-
-Wait for user confirmation before delegating.
-
-### Step 3 — Delegate in Order
-
-After user confirms the plan, delegate to sub-agents in this sequence:
-
-1. **`tdd-test-writer-agent`** — writes failing tests
-2. **`feature-implementer-agent`** — makes tests pass, then refactors
-3. **`migration-agent`** — creates migration schematics *(only if breaking changes exist)*
-5. **`changelog-agent`** — updates CHANGELOG.md
-4. **`validator-agent`** — validate the result, runs lint, build, and all test suites
-
-### Step 4 — Completion
-
-After all delegated steps finish, provide a concise summary of:
-- what was planned
-- which agents were used
-- what was implemented
-- any remaining follow-up items
+### Step 1 — Discover Scope
+
+1. Read the feature request.
+2. Search the repo to identify affected components, directives, services, and files.
+3. Determine:
+   - Which components are affected and where they live
+   - Whether this replaces, renames, or deprecates any existing API
+   - Whether a migration schematic is needed
+   - Whether i18n strings are affected
+   - Which test suite to use (grid vs non-grid)
+
+### Step 2 — Present a Scope Summary
+
+Present a brief scope summary to the user:
+
+- **What**: one sentence describing the feature
+- **Where**: affected components and main files
+- **Impact**: breaking change, deprecation, i18n, accessibility, or docs/demo follow-through if relevant
+- **Agents needed**: which specialist agents will be used
+- **Test suite**: the smallest likely suite
+
+Keep it short and high-level. Confirm scope, not solution details.
+
+Wait for user confirmation.
+
+### Step 3 — 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.
+
+For each subagent call, send only this minimal context:
+- the original user request
+- affected component(s) and file path(s)
+- whether breaking-change, i18n, accessibility, changelog, or README follow-through may apply
+- the likely test suite
+
+Do not send:
+- detailed feature requirements
+- expected test coverage
+- enumerated scenario lists
+- exact test cases
+- exact implementation instructions
+
+Use agents in this order:
+
+1. **`tdd-test-writer-agent`** — decides what tests to write
+2. **`feature-implementer-agent`** — independently implements the real feature contract
+3. **`migration-agent`** — only if breaking changes exist
+4. **`changelog-agent`** — updates CHANGELOG.md
+
+### Step 4 — Verify Completeness
+
+After all agents finish, check:
+
+- Were all affected areas covered?
+- Were public exports updated?
+- Was the component README updated?
+- Was CHANGELOG.md updated?
+- Do migrations exist for any breaking changes?
+- Is there a demo page update needed?
+
+Report what was done and any remaining items.

.github/agents/migration-agent.md

@@ -105,9 +105,16 @@ Create `index.spec.ts` in the migration folder:
 - Assert the output contains the migrated API
 - Test edge cases: files without the pattern, already-migrated files
 
-### 6. Validate
+### 6. Final Self-Validation
 
-Run `npm run test:schematics` and `npm run build:migrations`. Both must pass.
+Before finishing:
+
+1. Confirm the change is truly breaking.
+2. Confirm the migration is registered in `migration-collection.json`.
+3. Run:
+   - `npm run test:schematics`
+   - `npm run build:migrations`
+4. Confirm the migration updates the old API and leaves unrelated code unchanged.
 
 ### 7. Commit