You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These instructions describe how to efficiently work in the Go programming
4
-
language using the gopls MCP server. They are intended to be provided as context
5
-
for an interactive session using the gopls MCP tool: you can load this file
6
-
directly into a session where the gopls MCP server is connected.
3
+
These instructions describe how to efficiently work in the Go programming language using the gopls MCP server. You can load this file directly into a session where the gopls MCP server is connected.
7
4
8
5
## Detecting a Go workspace
9
6
10
-
Use the `go_workspace` tool to learn about the Go workspace. These instructions
11
-
apply whenever that tool indicates that the user is in a Go workspace.
12
-
13
-
## Go Programming Guidelines
14
-
15
-
These guidelines MUST be followed whenever working in a Go workspace. There
16
-
are two workflows described below: the 'Read Workflow' must be followed when
17
-
the user asks a question about a Go workspace. The 'Edit Workflow' must be
18
-
followed when the user edits a Go workspace.
19
-
20
-
You may re-do parts of each workflow as necessary to recover from errors.
21
-
However, you cannot skip any steps.
22
-
23
-
### Read Workflow
24
-
25
-
1.**Search the workspace:** When the user asks about a symbol, use
26
-
`go_search` to search for the symbol in question. If you find no matches,
27
-
search for a substring of the user's referenced symbol. If `go_search`
28
-
fails, you may fall back to regular textual search.
29
-
2.**Read files:** Read the relevant file(s). Use the `go_file_metadata` tool
30
-
to get package information for the file.
31
-
3.**Understand packages:** If the user is asking about the use of one or more Go
32
-
package, use the `go_package_outline` command to summarize their API.
33
-
34
-
### Editing Workflow
35
-
36
-
1.**Read first:** Before making any edits, follow the Read Workflow to
37
-
understand the user's request.
38
-
2.**Find references:** Before modifying the definition of any symbol, use the
39
-
`go_symbol_references` tool to find references to that identifier. These
40
-
references may need to be updated after editing the symbol. Read files
41
-
containing references to evaluate if any further edits are required.
42
-
3.**Make edits:** Make the primary edit, as well as any edits to references.
43
-
4.**Run diagnostics:** Every time, after making edits to one or more files,
44
-
you must call the `go_diagnostics` tool, passing the paths to the edited
45
-
files, to verify that the build is not broken. Apply edits to fix any
46
-
relevant diagnostics, and re-run the `go_diagnostics` tool to verify the
47
-
fixes. It is OK to ignore 'hint' or 'info' diagnostics if they are not
48
-
relevant.
49
-
5.**Run tests** run `go test` for any packages that were edited. Invoke `go
50
-
test` with the package paths returned from `go_file_metadata`. Fix any test
51
-
failures.
7
+
At the start of every session, you MUST use the `go_workspace` tool to learn about the Go workspace. The rest of these instructions apply whenever that tool indicates that the user is in a Go workspace.
8
+
9
+
## Go programming workflows
10
+
11
+
These guidelines MUST be followed whenever working in a Go workspace. There are two workflows described below: the 'Read Workflow' must be followed when the user asks a question about a Go workspace. The 'Edit Workflow' must be followed when the user edits a Go workspace.
12
+
13
+
You may re-do parts of each workflow as necessary to recover from errors. However, you must not skip any steps.
14
+
15
+
### Read workflow
16
+
17
+
The goal of the read workflow is to understand the codebase.
18
+
19
+
1.**Understand the workspace layout**: Start by using `go_workspace` to understand the overall structure of the workspace, such as whether it's a module, a workspace, or a GOPATH project.
20
+
21
+
2.**Find relevant symbols**: If you're looking for a specific type, function, or variable, use `go_search`. This is a fuzzy search that will help you locate symbols even if you don't know the exact name or location.
22
+
EXAMPLE: search for the 'Server' type: `go_search({"query":"server"})`
23
+
24
+
3.**Understand a file and its intra-package dependencies**: When you have a file path and want to understand its contents and how it connects to other files *in the same package*, use `go_file_context`. This tool will show you a summary of the declarations from other files in the same package that are used by the current file. `go_file_context` MUST be used immediately after reading any Go file for the first time, and MAY be re-used if dependencies have changed.
25
+
EXAMPLE: to understand `server.go`'s dependencies on other files in its package: `go_file_context({"file":"/path/to/server.go"})`
26
+
27
+
4.**Understand a package's public API**: When you need to understand what a package provides to external code (i.e., its public API), use `go_package_api`. This is especially useful for understanding third-party dependencies or other packages in the same monorepo.
28
+
EXAMPLE: to see the API of the `storage` package: `go_package_api({"packagePaths":["example.com/internal/storage"]})`
29
+
30
+
### Editing workflow
31
+
32
+
The editing workflow is iterative. You should cycle through these steps until the task is complete.
33
+
34
+
1.**Read first**: Before making any edits, follow the Read Workflow to understand the user's request and the relevant code.
35
+
36
+
2.**Find references**: Before modifying the definition of any exported symbol, use the `go_symbol_references` tool to find all references to that identifier. This is critical for understanding the impact of your change. Read the files containing references to evaluate if any further edits are required.
3.**Make edits**: Make the primary edit, as well as any edits to references you identified in the previous step.
40
+
41
+
4.**Check for errors**: After every code modification, you MUST call the `go_diagnostics` tool. Pass the paths of the files you have edited. This tool will report any build or analysis errors.
5.**Fix errors**: If `go_diagnostics` reports any errors, fix them. The tool may provide suggested quick fixes in the form of diffs. You should review these diffs and apply them if they are correct. Once you've applied a fix, re-run `go_diagnostics` to confirm that the issue is resolved. It is OK to ignore 'hint' or 'info' diagnostics if they are not relevant to the current task.
45
+
46
+
6.**Run tests**: Once `go_diagnostics` reports no errors (and ONLY once there are no errors), run the tests for the packages you have changed. You can do this with `go test [packagePath...]`. Don't run `go test ./...` unless the user explicitly requests it, as doing so may slow down the iteration loop.
0 commit comments