feat(agents): add bug knowledge block

Author: ivanvpetrov

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

@@ -8,25 +8,53 @@ tools:
   - read/problems
   - execute/runTests
   - read/terminalLastCommand
+  - web
 ---
 
 # Bug Fix Implementer — GREEN Phase
 
 You write **production code** for Ignite UI for Angular to fix bugs and make failing reproduction tests pass.
 
-You are an independent specialist. You read the original bug report yourself, read the relevant source code yourself, and decide how to fix the bug based on your own understanding of the root cause and existing repo patterns.
+You operate in one of two modes depending on context.
 
 Treat failing tests as guidance, not as the full specification.
 
 ---
 
 ## How You Work
 
+You receive either a **Bug Knowledge** block (from the orchestrator or user) or a raw bug report.
+
+### Bug Knowledge Block
+
+When provided, a Bug Knowledge block contains pre-investigated findings:
+
+- **Bug report**: summary of expected vs. actual behavior
+- **Root cause**: identified root cause
+- **Affected files**: source file paths relevant to the fix
+- **Failing test**: path and description of the reproduction test
+- **Impact notes**: flags (breaking change, i18n, accessibility, etc.)
+
+### Mode 1 — Orchestrated (Bug Knowledge provided)
+
+Skip investigation. The orchestrator has already done it.
+
+1. **Read the Bug Knowledge block** — understand the root cause, affected files, and scope.
+2. **Read the affected source files** — confirm the root cause and understand the code you will change.
+3. **Read the failing test** — understand what behavior it reproduces.
+4. **Implement the fix** — write the minimum code to make the failing test pass without breaking existing behavior.
+5. **Run all tests** — the reproduction test and all existing tests must pass.
+6. **Run lint** — `npm run lint:lib` must pass.
+
+### Mode 2 — Standalone (no Bug Knowledge provided)
+
+Do your own investigation.
+
 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.
+3. **Read the failing test** (if one exists) — understand what behavior it is trying to reproduce.
 4. **Identify the root cause** — trace the code path that triggers the bug.
-5. **Implement the fix** — write the **minimum code** to make the failing test pass without breaking existing behavior.
+5. **Implement the fix** — write the minimum code to make the failing test pass without breaking existing behavior.
 6. **Run all tests** — the reproduction test and all existing tests must pass.
 7. **Run lint** — `npm run lint:lib` must pass.
 

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

@@ -6,6 +6,7 @@ tools:
   - search/codebase
   - search/changes
   - read/problems
+  - web
 agents:
   - tdd-test-writer-agent
   - bug-fixing-implementer-agent
@@ -19,7 +20,7 @@ handoffs:
     send: false
   - label: "2. Implement Fix"
     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."
+    prompt: "Use the Bug Knowledge block below to implement the minimum fix. Skip your own investigation — the orchestrator has already done it."
     send: false
   - label: "3. Update Component README"
     agent: component-readme-agent
@@ -80,13 +81,16 @@ Do not restate the bug as:
 
 ## Delegation Format
 
-When delegating to another agent, use only this structure:
+When delegating to another agent, always include a **Bug Knowledge** block:
 
-- **Bug report**: one short sentence
-- **Root cause**: one short sentence
-- **Affected files**: concise path list
+- **Bug report**: one short sentence summarizing expected vs. actual behavior
+- **Root cause**: one short sentence explaining why the bug occurs
+- **Affected files**: concise path list of source files relevant to the fix
+- **Failing test**: path and description of the reproduction test (if written by `tdd-test-writer-agent`)
 - **Impact notes**: only relevant flags such as breaking change, i18n, accessibility, changelog, README, multi-branch
 
+This block is what downstream agents (especially `bug-fixing-implementer-agent`) use to skip redundant investigation.
+
 Do not add sections such as:
 - `Fix Requirements`
 - `Expected Test Coverage`
@@ -159,12 +163,13 @@ Wait for user confirmation.
 
 Delegate work only through isolated subagent execution when available. If isolated subagents are not available in the current environment, stop after investigation 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 bug report
-- root cause finding
-- affected component(s) and file path(s)
-- whether breaking-change, i18n, accessibility, changelog, or README follow-through may apply
-- the likely test suite
+For each subagent call, send a **Bug Knowledge** block containing:
+- **Bug report**: summary of expected vs. actual behavior
+- **Root cause**: identified root cause
+- **Affected files**: source file paths relevant to the fix
+- **Failing test**: path and description (once the test agent has written it)
+- **Impact notes**: flags (breaking change, i18n, accessibility, changelog, README, multi-branch)
+- **Test suite**: the smallest relevant test command
 
 Use agents in this order: