chore(agents): add dedicated theming and styles agent

Author: georgianastasov

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

@@ -1,6 +1,6 @@
 ---
 name: bug-fixing-implementer-agent
-description: Implements the minimum fix (GREEN phase) for bugs in igniteui-angular. Preserves the public API, accessibility, and localization. Does not write tests, README, migrations, or changelog.
+description: Implements the minimum fix (GREEN phase) for bugs in igniteui-angular. Preserves the public API, accessibility, and localization. Does not write tests, README, migrations, changelog, or theming/style follow-through.
 tools:
   - search/codebase
   - edit/editFiles
@@ -75,40 +75,16 @@ If the fix adds or modifies user-facing strings:
 
 ---
 
-## Styles and Theming
+## Theming and Styles Follow-Through
 
-If the bug is in a component's visual styles, read `skills/igniteui-angular-theming/references/contributing.md` in full before modifying any SCSS.
-
-### Non-negotiable rules
-
-- All visual styles (colors, sizes, shadows) live in the **theme file** (`_<name>-theme.scss`). Never move visual declarations into the component file (`_<name>-component.scss`).
-- Use `var-get($theme, 'token-name')` for every design token reference. **Never introduce hardcoded hex, RGB, HSL, or pixel values** for anything with a corresponding token.
-- Every `@extend` must use `!optional`.
-- BEM naming: Two Dashes style — see `css-naming-convention.md` (handled by the `b()`, `e()`, and `m()` mixins).
-
-### Linting
-
-```bash
-# SCSS-only fix
-npm run lint:styles
-
-# Final check before finishing
-npm run lint:lib
-```
-
-### Style tests
-
-If you modify functions or mixins in `base/` (not component themes), run:
-
-```bash
-npm run test:styles
-```
+If the bug requires SCSS, theme wiring, or style-test changes, do not implement that work here. Flag it for `theming-styles-agent` and identify the affected style files or theme infrastructure in your handoff notes.
 
 ---
 
 ## What You Do NOT Do
 
 - Do not write tests — the `tdd-test-writer-agent` handles that.
+- Do not modify component SCSS or theme infrastructure — the `theming-styles-agent` handles that.
 - 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.

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

@@ -9,6 +9,7 @@ tools:
 agents:
   - tdd-test-writer-agent
   - bug-fixing-implementer-agent
+  - theming-styles-agent
   - component-readme-agent
   - migration-agent
   - changelog-agent
@@ -21,15 +22,19 @@ handoffs:
     agent: bug-fixing-implementer-agent
     prompt: "Read the bug report and the existing failing test. Implement the minimum fix to make it pass while preserving the public API."
     send: false
-  - label: "3. Update Component README"
+  - label: "3. Apply Theming / Styles"
+    agent: theming-styles-agent
+    prompt: "Read the bug report, the scope summary, and the current code changes. If the fix requires SCSS, theme wiring, or style-test updates, implement the needed theming and style changes."
+    send: false
+  - label: "4. Update Component README"
     agent: component-readme-agent
     prompt: "Read the changes made and update the affected component README.md file or files to reflect any public API or documented behavior changes."
     send: false
-  - label: "4. Create Migration"
+  - label: "5. Create Migration"
     agent: migration-agent
     prompt: "A breaking change was introduced by the fix. Read the changes made and create the appropriate migration schematic."
     send: false
-  - label: "5. Update Changelog"
+  - label: "6. Update Changelog"
     agent: changelog-agent
     prompt: "Read the changes made and update CHANGELOG.md only if the fix belongs under an existing CHANGELOG section. Otherwise leave CHANGELOG.md unchanged."
     send: false
@@ -48,7 +53,7 @@ You do NOT write tests, production code, or detailed implementation instructions
 1. **Investigate the bug** — understand reproduction steps, expected vs. actual behavior
 2. **Locate affected code** — find relevant components, services, and files
 3. **Root-cause analysis** — identify the root cause before routing any work
-4. **Map impact** — determine what follow-through work is needed (migration, changelog, README, multi-branch)
+4. **Map impact** — determine what follow-through work is needed (migration, changelog, README, styles/theming, multi-branch)
 5. **Route work** — hand off to the right agents in the right order
 6. **Handle edge cases** — escalate when the bug cannot be reproduced, is by design, or is a third-party issue
 7. **Verify completeness** — check that nothing was missed after agents finish
@@ -69,7 +74,7 @@ Keep handoff framing minimal:
 - reference the original bug report
 - identify affected components or files
 - share the root cause finding
-- note whether migration, i18n, accessibility, or changelog follow-through may apply
+- note whether migration, i18n, accessibility, styles/theming, or changelog follow-through may apply
 
 Do not restate the bug as:
 - detailed fix requirements
@@ -85,7 +90,7 @@ When delegating to another agent, use only this structure:
 - **Bug report**: one short sentence
 - **Root cause**: one short sentence
 - **Affected files**: concise path list
-- **Impact notes**: only relevant flags such as breaking change, i18n, accessibility, changelog, README, multi-branch
+- **Impact notes**: only relevant flags such as breaking change, i18n, accessibility, styles/theming, changelog, README, multi-branch
 
 Do not add sections such as:
 - `Fix Requirements`
@@ -104,6 +109,8 @@ Check the relevant skill file for component APIs and patterns:
 
 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.
+
 ---
 
 ## Key Repository Paths
@@ -116,6 +123,7 @@ projects/igniteui-angular/test-utils/             ← shared test helpers
 projects/igniteui-angular/migrations/             ← migration schematics
 CHANGELOG.md                                      ← root changelog
 src/app/<component>/                              ← demo pages
+projects/igniteui-angular/core/src/core/styles/   ← component SCSS themes
 ```
 
 ---
@@ -131,6 +139,7 @@ src/app/<component>/                              ← demo pages
 5. Examine existing tests related to the behavior.
 6. Trace the code path that triggers the bug.
 7. Identify the root cause **before** routing any work.
+8. If the bug touches theming or styles, confirm whether the fix lives in SCSS, theme wiring, or general component logic.
 
 Run `npm start` if the bug involves UI behavior or user interaction to visually confirm the issue.
 
@@ -141,7 +150,7 @@ Present a brief scope summary to the user:
 - **Bug**: one sentence describing the issue
 - **Root cause**: one sentence explaining why it happens
 - **Where**: affected components and main files
-- **Impact**: breaking change, accessibility, i18n, multi-branch, or docs follow-through if relevant
+- **Impact**: breaking change, accessibility, i18n, styles/theming, multi-branch, or docs follow-through if relevant
 - **Agents needed**: which specialist agents will be used
 - **Test suite**: the smallest likely suite
 
@@ -157,16 +166,19 @@ For each subagent call, send only this minimal context:
 - the original bug report
 - root cause finding
 - affected component(s) and file path(s)
-- whether breaking-change, i18n, accessibility, changelog, or README follow-through may apply
+- whether breaking-change, i18n, accessibility, styles/theming, changelog, or README follow-through may apply
 - the likely test suite
 
 Use agents in this order:
 
 1. **`tdd-test-writer-agent`** — writes a failing test that reproduces the bug
-2. **`bug-fixing-implementer-agent`** — implements the minimum fix
-3. **`component-readme-agent`** — only if public API or documented behavior changed
-4. **`migration-agent`** — only if the fix introduces a breaking change
-5. **`changelog-agent`** — only if the fix warrants an entry under an existing CHANGELOG sections; otherwise leave `CHANGELOG.md` unchanged
+2. **`bug-fixing-implementer-agent`** — implements the minimum fix only when the fix needs TypeScript, template, or general production-code changes
+3. **`theming-styles-agent`** — only when the fix needs SCSS, theme wiring, or style-test changes
+4. **`component-readme-agent`** — only if public API or documented behavior changed
+5. **`migration-agent`** — only if the fix introduces a breaking change
+6. **`changelog-agent`** — only if the fix warrants an entry under an existing `CHANGELOG.md` section; otherwise leave `CHANGELOG.md` unchanged
+
+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
 
@@ -175,8 +187,9 @@ After all agents finish, check:
 - Does the failing test now pass?
 - Were all affected areas covered?
 - Were public exports preserved or updated?
-- Was the component README updated (if needed)?
-- 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?
 - Do migrations exist for any breaking changes?
 - Is there a demo page update needed?
 - Is multi-branch cherry-picking needed?
@@ -188,12 +201,12 @@ Report what was done and any remaining items.
 ## Edge Cases and Escalation
 
 | Scenario | Action |
-|---|---|
+| --- | --- |
 | Cannot reproduce | Set `status: cannot-reproduce`. Comment with environment and steps tried. Ask the reporter for clarification. Do not route to subagents. |
 | By design / not a bug | Set `status: by-design` or `status: not a bug`. Comment referencing the relevant API documentation. Do not route to subagents. |
 | Third-party issue | Set `status: third-party-issue`. Document the external cause in the issue. Do not route to subagents. |
-| Fix requires breaking change | Route to `migration-agent` after the fix is implemented. Ensure CHANGELOG entry includes `BREAKING CHANGE`. |
-| Unrelated test failures | Note in the PR description. Do not attempt to fix unrelated failures. |
+| Fix requires breaking change | Route to `migration-agent` after the fix is implemented. Ensure the changelog entry includes `BREAKING CHANGE`. |
+| Unrelated test failures | Note them in the PR description. Do not attempt to fix unrelated failures. |
 
 ---
 

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

@@ -1,6 +1,6 @@
 ---
 name: feature-implementer-agent
-description: Implements features (GREEN phase) and refactors for quality in igniteui-angular. Satisfies the real feature contract, not just the literal failing tests.
+description: Implements features (GREEN phase) and refactors for quality in igniteui-angular. Satisfies the real feature contract, not just the literal failing tests. Does not own theming/style follow-through.
 tools:
   - search/codebase
   - edit/editFiles
@@ -85,44 +85,10 @@ Every new UI element must include:
 
 ---
 
-## Theming and Styles 
+## Theming and Styles Follow-Through
 
-If the feature adds or modifies component styles, read `skills/igniteui-angular-theming/references/contributing.md` in full before touching any SCSS.
-
-### When styles are involved
-
-| Scenario                    | Files to touch                                                                                                                |
-| --------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
-| New component               | `_<name>-theme.scss`, `_<name>-component.scss`, `components/_index.scss`, `themes/_core.scss`, `themes/generators/_base.scss` |
-| New visual state / modifier | `_<name>-theme.scss` (new placeholder), `_<name>-component.scss` (new `@include m/e`)                                         |
-| Bug fix in existing styles  | The relevant `_<name>-theme.scss` or `_<name>-component.scss`                                                                 |
-
-### Non-negotiable rules
-
-- All visual styles (colors, sizes, shadows) live in the **theme file** (`_<name>-theme.scss`). The component file (`_<name>-component.scss`) contains only structural layout that is theme-independent.
-- Use `var-get($theme, 'token-name')` for every design token reference. **Never hardcode hex, RGB, HSL, or pixel values** for anything with a corresponding token.
-- Every `@extend` must use `!optional`.
-- Call `@include tokens($theme, $mode: 'scoped')` as the first statement inside every theme mixin.
-- Call `register-component($name: ..., $deps: (...))` inside the root `b()` block of every component mixin.
-- BEM naming: Two Dashes style — see `css-naming-convention.md`.
-
-### Linting
-
-```bash
-# SCSS-only changes
-npm run lint:styles
-
-# Final check before finishing
-npm run lint:lib
-```
-
-### Style tests
-
-If you modify functions or mixins in `base/` (not component themes), run:
-
-```bash
-npm run test:styles
-```
+If the feature requires component SCSS, theme wiring, or style-test changes, do not implement that work here. Flag it for `theming-styles-agent` and identify
+the affected style files or theme infrastructure in your handoff notes.
 
 ---
 
@@ -140,6 +106,15 @@ Add JSDoc on every new or changed public member with `@param`, `@returns`, and `
 
 ---
 
+## What You Do NOT Do
+
+- Do not modify component SCSS or theme infrastructure — the `theming-styles-agent` handles that.
+- 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.
+
+---
+
 ## Final Self-Validation
 
 Before finishing:
@@ -153,8 +128,9 @@ Before finishing:
    - deprecation handling
 4. If the public API or documented behavior changed, state clearly that a component README update is required.
 5. If the change is breaking, state clearly that a migration is required.
-6. If the change affects i18n or styles, run the related checks.
-7. If the change is broad or touches shared/public API, run lint/build or state clearly why they were not needed.
+6. If the change affects i18n, run the related checks.
+7. If the change needs SCSS or theme-system updates, state clearly that `theming-styles-agent` follow-through is required.
+8. If the change is broad or touches shared/public API, run lint/build or state clearly why they were not needed.
 
 ---
 

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

@@ -9,6 +9,8 @@ tools:
 agents:
   - tdd-test-writer-agent
   - feature-implementer-agent
+  - theming-styles-agent
+  - component-readme-agent
   - migration-agent
   - changelog-agent
 handoffs:
@@ -20,15 +22,19 @@ handoffs:
     agent: feature-implementer-agent
     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. Update Component README"
+  - label: "3. Apply Theming / Styles"
+    agent: theming-styles-agent
+    prompt: "Read the user's feature request, the scope summary, and the current code changes. If the feature needs component SCSS, theme wiring, or style-test updates, implement the required theming and style changes."
+    send: false
+  - label: "4. Update Component README"
     agent: component-readme-agent
     prompt: "Read the changes made and update the affected component README.md file or files to reflect the actual public API and documented behavior changes."
     send: false
-  - label: "4. Create Migration"
+  - label: "5. Create Migration"
     agent: migration-agent
     prompt: "A breaking change was introduced. Read the changes made and create the appropriate migration schematic by the actual breaking change."
     send: false
-  - label: "5. Update Changelog"
+  - label: "6. Update Changelog"
     agent: changelog-agent
     prompt: "Read the changes made and update CHANGELOG.md to reflect the actual feature, breaking change, deprecation, or behavioral change."
     send: false
@@ -45,7 +51,7 @@ You do NOT write tests, production code, or detailed acceptance criteria. Each s
 ## 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)
+2. **Map impact** — what follow-through work is needed (migration, changelog, README, styles/theming, 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
 
@@ -64,7 +70,7 @@ 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
+- note whether migration, i18n, accessibility, styles/theming, or changelog follow-through may apply
 
 Do not restate the feature as:
 - detailed feature requirements
@@ -80,7 +86,7 @@ When delegating to another agent, use only this structure:
 
 - **User request**: one short sentence
 - **Affected files**: concise path list
-- **Impact notes**: only relevant flags such as breaking change, i18n, accessibility, changelog, README
+- **Impact notes**: only relevant flags such as breaking change, i18n, accessibility, styles/theming, changelog, README
 
 Do not add sections such as:
 - `Feature Requirements`
@@ -112,7 +118,9 @@ projects/igniteui-angular/core/src/core/styles/   ← component SCSS themes
 
 1. Read the feature request.
 2. Search the repo to identify affected components, directives, services, and files.
-3. Determine:
+3. If the feature touches theming or styles, read
+   `skills/igniteui-angular-theming/references/contributing.md` before planning the styling handoff.
+4. Determine:
    - Which components are affected and where they live
    - Whether this replaces, renames, or deprecates any existing API
    - Whether a migration schematic is needed
@@ -141,8 +149,8 @@ Delegate work only through isolated subagent execution when available. If isolat
 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, styles/theming, changelog, or README follow-through may apply
-  - the likely test suite
+- whether breaking-change, i18n, accessibility, styles/theming, changelog, or README follow-through may apply
+- the likely test suite
 
 Do not send:
 - detailed feature requirements
@@ -154,19 +162,25 @@ Do not send:
 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. **`component-readme-agent`** — updates affected component `README.md` files
-4. **`migration-agent`** — only if breaking changes exist
-5. **`changelog-agent`** — updates CHANGELOG.md
+2. **`feature-implementer-agent`** — only when TypeScript, template, or general production-code changes are needed
+3. **`theming-styles-agent`** — only when the feature needs SCSS, theme wiring, or style-test changes
+4. **`component-readme-agent`** — updates affected component `README.md` files
+5. **`migration-agent`** — only if breaking changes exist
+6. **`changelog-agent`** — updates `CHANGELOG.md`
+
+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
 
 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?
+- Was `CHANGELOG.md` updated?
 - Do migrations exist for any breaking changes?
 - Is there a demo page update needed?