Feature Request: Leverage LSP (e.g., gopls) to inject internal function/type definitions into the LLM prompt

[luxixing]

Description

Hi Kilo-Code team—thank you for your continuous effort in delivering such an excellent AI coding assistant! 🙏
During day-to-day use, I noticed that when generating unit tests or refactorings for Go projects, the language model often lacks the real signatures and return types of internal packages’ functions or methods. This gap can lead to “hallucinated” code or incorrect refactors.

Below are two simplified scenarios that illustrate the issue.

Scenario 1 – Return-type mis-assumption during refactor

func Example(ctx context.Context) error {
    result1, err := client1.SomeFunc()
    ...
    result2, err := client2.SomeFunc()
    return nil
}

Both client1 and client2 are internal packages.
If Kilo-Code calls the LLM without providing the real definition of SomeFunc(), the model typically infers return types solely from variable names (result1, result2) and produces incorrect code suggestions.

---

Scenario 2 – Variable name ≠ actual type

package xxx

import (
    ...
    "my/internal/node"
    "my/internal/cascade"
    ...
)

func GetLocalOverviewInfo(ctx context.Context) (*node.Meta, error) {
    data := &node.Meta{}
    nodeInfo, err := cascade.GetNodeWithoutCache(ctx) // actually returns *cascade.NodeInfo
    ...
    return data, err
}

Although the variable is named nodeInfo, the real return type is *cascade.NodeInfo.
Without the signature of GetNodeWithoutCache, the model often keeps propagating node-related code, resulting in compilation errors.

Proposed Solution

Call the language’s LSP (for Go, gopls) or VS Code Definition APIs while assembling the prompt, and inject:

The full signature of every referenced function/method (package path, parameters, return values).

Nearby comments / docstrings to enrich semantic context.

When necessary, key type definitions (structs/interfaces) used by those symbols.

With this extra context, the model can produce far more accurate code for unit-test scaffolds, API docs, and refactor suggestions, reducing manual review and fixes.

Implementation Sketch (for discussion)

Step	Possible approach	Notes
1	Keep existing logic to extract the current selection / file	–
2	For each CallExpr, invoke textDocument/definition via LSP (or VS Code DefinitionProvider)	Returns URI + range
3	Read and trim the target file (e.g., keep the declaration, signature, head/tail comments)	Respect token limits
4	Insert this info into a dedicated “Referenced Symbols” block inside the prompt	Keeps prompt structure clear
5	Add a user setting to enable/disable and/or limit depth of lookup	Prevents prompt bloat

Expected Benefits

Lower hallucination rate: Real signatures beat guesswork based on variable names.

Higher refactor accuracy: Generated replacements are closer to “compiles-out-of-the-box.”

Better unit-test generation: Correct mocks/stubs are produced automatically.

Cross-language scalability: Works wherever an LSP is available.

Closing

If the proposal sounds viable, I’m happy to help with a PoC or PR—especially around integrating gopls or VS Code APIs.
Thanks again for your hard work, and looking forward to your feedback!

Best regards

[Juice10]

This is a very powerful idea @luxixing, as a typescript user myself I think this would be really helpful! Maybe @kevinvandijk or @beatlevic can take a look at this to see if they think this proposal could be viable?

[janpaul123]

I'm curious if there's any Cline/Roo work on this yet, would be good to link if so!

[luxixing]

I haven't seen any relevant capabilities from Cline or roo-code in this area.
Recently, I've tried augment and cursor.
In such scenarios, cursor's performance is mediocre — especially when the original code is poorly designed with lots of dependencies. It ends up using mocks to handle the situation, and I'd rate the result around 60 out of 100.
augment performs much better. It leverages its own context engine to analyze and extract dependency definitions. As a result, the generated code quality is significantly higher — I'd rate it around 90 out of 100.

[adamhill]

Coolio!

In addition to using the LSP's + Hover info that is always there for an LSP supported language, there are a few other possible avenues available to us, especially if you just want local info + references out.

• The Bifrost MCP has examples of calling all the LSP apis we would need in (esp. getReferences) we would just urn all the MCP tool calls into internal ones - https://github.com/biegehydra/BifrostMCP/blob/6101e4833c837d990821994d68e1a0bc950e8166/src/toolRunner.ts#L8 and https://github.com/biegehydra/BifrostMCP/blob/6101e4833c837d990821994d68e1a0bc950e8166/src/tools.ts#L1

• Use codebase indexing + the appropriate tree-sitter grammar and queries. go is supported by our current tree-sitter implementation, so it can be chunked intelligently by CBI. See -

  kilocode/src/services/tree-sitter/index.ts

  Line 30 in 9e59973

  const extensions = [

• Another intriguing possibility is now we can use the Semantic indexing API just exposed to us via the open source release of the copilot-chat extension -
  https://github.com/microsoft/vscode-copilot-chat/blob/33e7bb1b1ec61cec57d5d491bb36adeaabaf6ed5/src/extension/workspaceSemanticSearch/node/semanticSearchTextSearchProvider.ts#L500-L508