feat(*): Add AGENTS.md file and custom agents#17053
feat(*): Add AGENTS.md file and custom agents#17053georgianastasov wants to merge 25 commits intomasterfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Adds repository-wide AI guidance and a set of internal custom agent definitions to standardize AI-assisted workflows (planning → tests → implementation → docs/migrations/changelog), and aligns Copilot instructions with the repo’s current Angular version.
Changes:
- Added
AGENTS.mdwith repo structure, working rules, commands, skills, and agent index. - Added multiple
.github/agents/*.mdfiles defining roles for orchestration, TDD test writing, implementation, migrations, changelog, and README updates. - Updated
.github/copilot-instructions.mdto reference Angular v21+.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| AGENTS.md | New top-level guidance for AI agents (structure, rules, commands, skills, agent list). |
| .github/copilot-instructions.md | Updates the default Copilot persona to Angular v21+. |
| .github/agents/tdd-test-writer-agent.md | Defines the RED-phase test-writing agent workflow and constraints. |
| .github/agents/feature-orchestrator-agent.md | Defines a feature orchestration workflow and handoffs to specialist agents. |
| .github/agents/feature-implementer-agent.md | Defines GREEN/REFACTOR implementation guidance for features. |
| .github/agents/component-readme-agent.md | Defines responsibility and workflow for component README updates. |
| .github/agents/migration-agent.md | Defines ng update migration workflow, structure, and testing guidance. |
| .github/agents/changelog-agent.md | Defines how to update CHANGELOG.md following existing conventions. |
| .github/agents/bug-fixing-orchestrator-agent.md | Defines bug-fix investigation/orchestration workflow and handoffs. |
| .github/agents/bug-fixing-implementer-agent.md | Defines minimal-fix (GREEN) guidance for bugs. |
You can also share your feedback on Copilot code review. Take the survey.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Removed specific version reference to Angular and streamlined the persona description.
There was a problem hiding this comment.
Pull request overview
Adds repository-wide AI guidance and a set of internal custom agent definitions to standardize AI-assisted workflows (planning → tests → implementation → docs/migrations/changelog) across Ignite UI for Angular.
Changes:
- Added
AGENTS.mdwith repo structure, working rules, commands, and a catalog of the custom agents. - Added multiple
.github/agents/*.mdcustom agent definition files (orchestrators + specialists). - Updated
.github/copilot-instructions.mdPersona text to align with current Angular usage.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
AGENTS.md |
Introduces repo-wide guidance (structure, rules, commands, skills, agent catalog). |
.github/copilot-instructions.md |
Updates Persona wording for “latest Angular” guidance. |
.github/agents/tdd-test-writer-agent.md |
Defines RED-phase unit test writing guidance and constraints. |
.github/agents/feature-orchestrator-agent.md |
Defines feature workflow orchestration and handoff structure. |
.github/agents/feature-implementer-agent.md |
Defines GREEN/REFACTOR implementation guidance. |
.github/agents/component-readme-agent.md |
Defines responsibilities for updating component README docs. |
.github/agents/migration-agent.md |
Defines ng update migration workflow and testing expectations. |
.github/agents/changelog-agent.md |
Defines CHANGELOG update workflow and formatting expectations. |
.github/agents/bug-fixing-orchestrator-agent.md |
Defines bug-fix investigation + orchestration workflow. |
.github/agents/bug-fixing-implementer-agent.md |
Defines minimal-fix (GREEN) guidance for bug fixes. |
Comments suppressed due to low confidence (1)
.github/copilot-instructions.md:7
- The updated Persona paragraph has a couple of grammar issues (e.g., missing “the” in “immersed in latest Angular”, and the “Performance is paramount to you, who…” clause reads awkwardly). Also, the next line still says “Angular 20 component”, which now conflicts with the new “latest Angular” wording—please align the version wording for consistency.
You are a dedicated Angular developer who thrives on leveraging the absolute latest features of the framework to build cutting-edge applications. You are currently immersed in latest Angular, passionately adopting signals for reactive state management, embracing standalone components for streamlined architecture, and utilizing the new control flow for more intuitive template logic. Performance is paramount to you, who constantly seeks to optimize change detection and improve user experience through these modern Angular paradigms. When prompted, assume you are familiar with all the newest APIs and best practices, valuing clean, efficient, and maintainable code.
## Examples
These are modern examples of how to write an Angular 20 component with signals
You can also share your feedback on Copilot code review. Take the survey.
|
|
||
| 1. **Read the original bug report** — understand expected vs. actual behavior. | ||
| 2. **Read the existing component source** — understand the current implementation, patterns, and conventions. | ||
| 3. **Read the failing test** — understand what behavior it is trying to reproduce. |
There was a problem hiding this comment.
The skill references a failing reproduction test, which nothing told it to write. Consider either instructing the agent to write it, or making it userinvocable: false
| - 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. |
There was a problem hiding this comment.
This is not needed, it knows it by default
| 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) | ||
| 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 |
There was a problem hiding this comment.
All of this seems to be covered already by the bug-fixing-implementer
| ## Handoff | ||
|
|
||
| When routing work, pass scope, root cause, and context — not a mini-spec. | ||
|
|
||
| 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 | ||
|
|
||
| Do not restate the bug as: | ||
| - detailed fix requirements | ||
| - exact test cases | ||
| - exact implementation instructions |
There was a problem hiding this comment.
OK, this may actually cover my previous comment.
| ### Step 1 — Investigate and Root-Cause | ||
|
|
||
| 1. Read the bug report carefully. | ||
| 2. Identify reproduction steps and expected vs. actual behavior. |
There was a problem hiding this comment.
Maybe add a step to request additional context if required information is missing.
|
|
||
| After all agents finish, check: | ||
|
|
||
| - Does the failing test now pass? |
There was a problem hiding this comment.
| - Does the failing test now pass? | |
| - Does the newly added failing test now pass? |
|
|
||
| ## Multi-branch Fixes | ||
|
|
||
| When a bug exists in multiple release branches: |
There was a problem hiding this comment.
| When a bug exists in multiple release branches: | |
| When a bug exists in multiple supported release branches: |
| ## Multi-branch Fixes | ||
|
|
||
| When a bug exists in multiple release branches: | ||
| 1. Target the fix at the **oldest affected branch** first. |
There was a problem hiding this comment.
Tell the agent how to extract what the currently supported branches are.
| - Keep i18n intact when user-facing text changes. | ||
| - 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. |
There was a problem hiding this comment.
| - Update the component `README.md` when the public API surface 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 | |
| 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. |
There was a problem hiding this comment.
| 6. **Run the tests** — confirm they fail for the intended missing behavior. | |
| 6. **Run the tests** — confirm they fail for the intended missing functionality, or for existing functionality that does not function as intended. |
| 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. |
There was a problem hiding this comment.
These instructions only apply to bug fixing. When doing feature development, the agent may want to plan a larger test suite by initial broader design of the feature and then to iteratively implement the feature and iteratively make the tests pass 1 by 1 or in batches related to the implemented functionality.
| 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. |
There was a problem hiding this comment.
Again the same comment as above.
| - No shared mutable state. | ||
| - No execution-order dependency. | ||
| 6. **Never write production code.** | ||
| - Only test code in this phase. |
There was a problem hiding this comment.
| - 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. |
|
|
||
| ## When to Create Migrations | ||
|
|
||
| - API removed or renamed |
There was a problem hiding this comment.
| - API removed or renamed | |
| - API removed, renamed, or deprecated |
|
|
||
| Add JSDoc on every new or changed public member with `@param`, `@returns`, and `@example`. | ||
|
|
||
| --- |
There was a problem hiding this comment.
| --- | |
| --- | |
| ## Agent Skills | |
| Update component agent skills if you need to guide other agents on how to use the newly added feature. | |
| --- |
Closes: #17054
Summary
This PR adds a new
AGENTS.mdfile and a set of internal custom agents to guide AI-assisted work in the repository.It also updates
.github/copilot-instructions.mdso the default Copilot guidance is better aligned with the repository structure.Why
The goal of these changes is to make AI-assisted contributions more consistent, more repo-aware, and easier to guide through a structured workflow.
What changed
Updated
.github/copilot-instructions.mdAdded
AGENTS.md.github/agents/feature-orchestrator-agent.md.github/agents/bug-fixing-orchestrator-agent.md.github/agents/tdd-test-writer-agent.md.github/agents/feature-implementer-agent.md.github/agents/bug-fixing-implementer-agent.md.github/agents/component-readme-agent.mdREADME.mdfiles when public API or documented behavior changes..github/agents/migration-agent.mdng updatemigration schematics when a breaking change is introduced..github/agents/changelog-agent.mdResult
Together, these files introduce a more structured internal AI workflow for the repository across both feature delivery and bug fixing:
This should make AI-assisted development more predictable, more maintainable, and more aligned with the repository’s existing standards.
Notes