This document describes the custom AI agents used in this repository, what each one is responsible for, how they work together, and how to use them effectively.
- Purpose
- Agent System at a Glance
- Agent List
- How the System Is Structured
- Quick Start
- Feature Workflow
- Bug-Fix Workflow
- When to Use Which Agent
- Using Agents Individually
- Repository Areas the Agents Care About
- Maintenance Notes
- Final Summary
The agent system keeps AI-assisted work modular, consistent, and reviewable.
Instead of one general agent doing everything, work is split into two roles:
- Orchestrators analyze scope, decide follow-through, and route work.
- Specialists handle one focused responsibility well, such as tests, implementation, theming/styles, demo updates, docs, migrations, or changelog updates.
┌──────────────────────────────┐
│ User Request │
└──────────────┬───────────────┘
│
┌────────┴────────┐
│ │
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ Feature workflow │ │ Bug workflow │
└────────┬─────────┘ └────────┬─────────┘
│ │
▼ ▼
┌──────────────────────────┐ ┌──────────────────────────┐
│ feature-orchestrator- │ │ bug-fixing-orchestrator- │
│ agent │ │ agent │
└──────────────┬───────────┘ └──────────────┬───────────┘
│ │
└──────────────┬──────────────┘
│
▼
┌──────────────────────────┐
│ tdd-test-writer-agent │
└──────────────┬───────────┘
│
┌──────────────┴──────────────┐
│ │
▼ ▼
┌──────────────────────────┐ ┌──────────────────────────┐
│ feature-implementer- │ │ bug-fixing-implementer- │
│ agent │ │ agent │
└──────────────┬───────────┘ └──────────────┬───────────┘
│ │
└──────────────┬──────────────┘
│
▼
┌──────────────────────────────┐
│ theming-styles-agent │
│ (if needed) │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ demo-sample-agent │
│ (if explicitly requested) │
└──────────────┬───────────────┘
│
▼
┌───────────────────────────┐
│ Optional when needed │
└──────────────┬────────────┘
│
▼
┌──────────────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ component-readme-agent │ │ migration-agent │ │ changelog-agent │
└──────────────────────────┘ └──────────────────┘ └──────────────────┘
- one core workflow is selected: feature or bug
- TDD tests come first
- implementation follows
- theming/style work follows implementation when needed
- demo/sample work happens only when explicitly requested
- README, migration, and changelog work are optional follow-through
| Agent | Role | Use it for |
|---|---|---|
feature-orchestrator-agent |
Orchestrator | New features, enhancements, broader feature work |
bug-fixing-orchestrator-agent |
Orchestrator | Bug reports, regressions, investigation-first work |
tdd-test-writer-agent |
Specialist | Small failing tests before production code |
feature-implementer-agent |
Specialist | Feature implementation and refactor |
bug-fixing-implementer-agent |
Specialist | Minimum safe bug fix |
theming-styles-agent |
Specialist | Component theming, structural SCSS, theme wiring, and style validation |
demo-sample-agent |
Specialist | Demo/sample updates in src/app/ for explicitly requested user-visible changes |
component-readme-agent |
Specialist | Component README updates |
migration-agent |
Specialist | ng update migration for breaking changes |
changelog-agent |
Specialist | CHANGELOG.md updates |
Orchestrators are responsible for:
- understanding the request at a high level
- identifying affected components and files
- mapping impact such as breaking changes, docs impact, changelog impact, accessibility, i18n, theming/styles impact, or demo/sample follow-through
- deciding which specialist agents are needed
- routing work in the correct order
- verifying that nothing important was missed
Orchestrators do not act as detailed spec writers. They should pass minimal context and avoid over-constraining downstream agents.
Orchestrators also decide whether optional follow-through is needed after implementation or bug fixing.
Specialist agents own a single focused responsibility.
Examples:
- the TDD agent writes failing tests
- implementer agents write production code
- the theming agent handles SCSS, theme wiring, and style validation
- the demo agent updates demo/sample pages in
src/app/when a demo is explicitly requested - the README agent updates component docs
- the migration agent handles
ng updatemigrations for breaking changes - the changelog agent updates release notes in the correct section
| Goal | Start with |
|---|---|
| Add or expand a feature | feature-orchestrator-agent |
| Investigate and fix a bug | bug-fixing-orchestrator-agent |
| Write failing tests first | tdd-test-writer-agent |
| Implement a known feature | feature-implementer-agent |
| Implement a known bug fix | bug-fixing-implementer-agent |
| Style or theme a component | theming-styles-agent |
| Update demo for an explicitly requested user-visible change | demo-sample-agent |
| Update docs after public change | component-readme-agent |
| Add migration for breaking change | migration-agent |
| Add release-note coverage | changelog-agent |
Use the feature flow when the task is about new behavior, new public API, enhancements, refactors tied to a feature, or deprecation follow-through.
feature-orchestrator-agent
┌──────────────────────────────┐
│ Feature request │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ feature-orchestrator-agent │
├──────────────────────────────┤
│ - discovers scope │
│ - identifies affected areas │
│ - checks follow-through │
│ - routes the work │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ tdd-test-writer-agent │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ feature-implementer-agent │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ theming-styles-agent │
│ (if needed) │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ demo-sample-agent │
│ (if explicitly requested) │
└──────────────┬───────────────┘
│
▼
┌────────────────────────┐
│ Optional follow-through│
└───────────┬────────────┘
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌───────────┐ ┌──────────────┐
│ component- │ │ migration-│ │ changelog- │
│ readme-agent │ │ agent │ │ agent │
└──────────────┘ └───────────┘ └──────────────┘
│
▼
┌──────────────────────────────┐
│ feature-orchestrator-agent │
│ verifies completeness │
└──────────────────────────────┘
Orchestrator checks before routing:
- affected files and components
- deprecations or API changes
- accessibility and i18n impact
- whether theming/style follow-through is needed
- whether a demo/sample update was explicitly requested
- whether README, migration, or changelog work is needed
- smallest relevant test suite
The order keeps the workflow grounded:
- Tests first — define the missing behavior.
- Implementation second — satisfy the real feature contract, not just the tests literally.
- Theming/style follow-through — handle SCSS and theme-system work when needed.
- Demo follow-through — update samples only when explicitly requested.
- Documentation follow-through — reflect actual public changes.
- Migration follow-through — automate breaking changes.
- Changelog follow-through — record notable release information.
Use the bug-fix flow when the task is about broken existing behavior, regressions, unexpected runtime behavior, or incorrect output caused by an existing implementation.
bug-fixing-orchestrator-agent
┌──────────────────────────────┐
│ Bug report │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ bug-fixing-orchestrator- │
│ agent │
├──────────────────────────────┤
│ - investigates reproduction │
│ - finds affected areas │
│ - performs root-cause review │
│ - checks follow-through │
│ - routes the work │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ tdd-test-writer-agent │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ bug-fixing-implementer-agent │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ theming-styles-agent │
│ (if needed) │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ demo-sample-agent │
│ (if explicitly requested) │
└──────────────┬───────────────┘
│
▼
┌────────────────────────┐
│ Optional follow-through│
└───────────┬────────────┘
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌───────────┐ ┌──────────────┐
│ component- │ │ migration-│ │ changelog- │
│ readme-agent │ │ agent │ │ agent │
└──────────────┘ └───────────┘ └──────────────┘
│
▼
┌──────────────────────────────┐
│ bug-fixing-orchestrator- │
│ agent verifies completeness │
└──────────────────────────────┘
Bug flow differs because it emphasizes: Compared with feature work, bug fixing adds stronger emphasis on:
- root-cause analysis before routing
- reproduction-first testing
- minimal fixes rather than scope expansion
- theming/style separation when the required fix belongs in SCSS or theme wiring
- multi-branch handling when the bug affects release branches
- edge-case escalation when the issue is not reproducible, is by design, or is caused by a third party
Use this quick decision guide:
| Situation | Best starting agent |
|---|---|
| New feature or enhancement | feature-orchestrator-agent |
| Bug report or regression | bug-fixing-orchestrator-agent |
| Only need failing tests first | tdd-test-writer-agent |
| Already have failing tests and need implementation | feature-implementer-agent or bug-fixing-implementer-agent |
| Styling or theming a component | theming-styles-agent |
| Demo update explicitly requested for a user-visible change | demo-sample-agent |
| Public behavior changed and docs must be updated | component-readme-agent |
Breaking change needs ng update support |
migration-agent |
| User-visible change needs release-note coverage | changelog-agent |
If the task is broad or uncertain, start with an orchestrator.
If the task is narrow and clearly scoped, start directly with the specialist that owns that responsibility.
| Agent | Call directly when | Avoid when |
|---|---|---|
feature-orchestrator-agent |
the task is a feature and scope still needs analysis | you already only need one narrow follow-up task |
bug-fixing-orchestrator-agent |
the task is a bug and root cause is not yet confirmed | root cause is already known and you only need the fix |
tdd-test-writer-agent |
you need RED-phase tests or a failing repro | you need production code |
feature-implementer-agent |
feature scope is known and implementation is next | the task is really a bug fix |
bug-fixing-implementer-agent |
the bug is understood and needs the smallest safe fix | the task is actually a feature |
theming-styles-agent |
SCSS, theme wiring, or style validation is needed | no styling impact exists |
demo-sample-agent |
a demo is explicitly requested for a user-visible change | the change has no UI impact or no demo/sample was requested |
component-readme-agent |
public API or documented behavior changed | no docs impact exists |
migration-agent |
a breaking change needs migration support | the change is additive only |
changelog-agent |
the change deserves release-note coverage | the change is too minor for changelog |
These paths appear repeatedly in the workflow and are worth knowing:
projects/igniteui-angular/<component>/src/ source + tests
projects/igniteui-angular/<component>/index.ts public barrel
projects/igniteui-angular/<component>/README.md component documentation
projects/igniteui-angular/test-utils/ shared test helpers
projects/igniteui-angular/migrations/ migration schematics
projects/igniteui-angular/core/src/core/styles/ theming and shared style infrastructure
CHANGELOG.md root changelog
src/app/<component>/ demo pages
The system also relies on repository-specific guidance and internal operational skills in:
.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.
When adding a new agent, update these places:
- Agent List
- Agent System at a Glance
- When to Use Which Agent
- Using Agents Individually
Whenever you add a new agent, document:
- its exact name
- its one-sentence purpose
- whether it is an orchestrator or specialist
- where it fits in the workflow
- when to call it directly
- what it explicitly should not do
Use names that make role and scope obvious, for example:
<domain>-orchestrator-agent<domain>-implementer-agent<responsibility>-agent
That naming pattern makes the workflow easier to understand at a glance.
This agent system is built around a clear separation of concerns:
- Orchestrators think in scope, impact, and routing
- Specialists think in focused execution
- Optional follow-through agents keep release quality high
That structure makes feature delivery and bug fixing more predictable, easier to review, and more aligned with repository conventions.