Document the Diagnostics Integration feature

[akaihola]

Roo Code documents its Diagnostics Integration feature on a dedicated page.

The implementation seems to be virtually identical in Kilo Code (see Copilot analysis below), but I couldn't find any mentions for it in Kilo Code documentation.

The diagnostics integration of course becomes evident once one uses Kilo Code, but what I wanted to specifically understand is what logic is used to choose which diagnostic messages are included in the context ("Only reports new errors (not pre-existing ones)" as documented in Roo Code).

GitHub Copilot's comparison of Diagnostics Integration between Roo Code and Kilo Code

---

I'll search for diagnostic integration features in the Kilo-Org/kilocode repository to compare with Roo Code's implementation.

Now let me look at the specific implementation of the diagnostics integration to see if it follows the same pattern as Roo Code.

Based on my analysis of the Kilo Code repository, yes, Kilo Code implements the Diagnostics Integration feature in a very similar way to Roo Code. Here's a detailed comparison:

Key Similarities:

1. Differential Approach - Only New Problems

Both implementations focus on identifying and reporting only newly introduced problems by comparing old vs new diagnostics:

Kilo Code:

• Has getNewDiagnostics() function that filters out existing problems
• Uses deepEqual comparison to identify truly new diagnostics
• Only feeds new problems to the LLM, not all existing ones

Roo Code:

• Same getNewDiagnostics() function with identical logic
• Same differential analysis approach

2. Core Implementation Structure

Both have nearly identical file structures:

• Main file: src/integrations/diagnostics/index.ts
• Helper utilities: In src/integrations/editor/EditorUtils.ts
• Same core functions: getNewDiagnostics() and diagnosticsToProblemsString()

3. Integration Points

Both integrate diagnostics checking at the same points:

File Edit Workflow:

• Capture diagnostics before applying changes (preDiagnostics)
• Apply file changes
• Capture diagnostics after changes (postDiagnostics)
• Compare and identify new problems
• Only show new problems to the user/LLM

This is evident in Kilo Code's DiffViewProvider.ts:

// Getting diagnostics before and after the file edit is a better approach than
// automatically tracking problems in real-time. This method ensures we only
// report new problems that are a direct result of this specific edit.
const newProblems = await diagnosticsToProblemsString(
    getNewDiagnostics(this.preDiagnostics, postDiagnostics),
    [vscode.DiagnosticSeverity.Error], // only including errors
    this.cwd,
)

4. Severity Filtering

Both allow filtering by diagnostic severity levels and typically focus on errors to avoid overwhelming the LLM with warnings.

Minor Differences:

• Function naming: Kilo Code has getNewDiagnostics() vs Roo Code's getNewProblems()
• Variable naming: Some slight naming variations but same core logic
• Branding: Comments reference "Kilo Code" vs "Roo Code" but functionality is identical

Conclusion:

Yes, Kilo Code implements the Diagnostics Integration feature in essentially the same way as Roo Code. Both systems:

• ✅ Only feed newly introduced problems to the LLM prompt
• ✅ Use differential analysis comparing before/after diagnostics
• ✅ Filter out existing problems to avoid distraction
• ✅ Integrate at the same workflow points (file edits, code actions)
• ✅ Have nearly identical implementation code

This approach ensures the LLM stays focused on problems directly caused by its recent changes rather than getting distracted by pre-existing issues in the codebase.

Note: The search results may be incomplete. You can view more results in GitHub if needed.