forked from olimorris/codecompanion.nvim
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathcodecompanion-workspace.json
More file actions
145 lines (145 loc) · 7.98 KB
/
Copy pathcodecompanion-workspace.json
File metadata and controls
145 lines (145 loc) · 7.98 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
{
"name": "CodeCompanion.nvim",
"version": "1.0.0",
"workspace_spec": "1.0",
"system_prompt": "CodeCompanion.nvim is an AI-powered productivity tool integrated into Neovim, designed to enhance the development workflow by seamlessly interacting with various large language models (LLMs). It offers features like inline code transformations, code creation, refactoring, and supports multiple LLMs such as OpenAI, Anthropic, and Google Gemini, among others. With tools for variable management, agents, and custom workflows, CodeCompanion.nvim streamlines coding tasks and facilitates intelligent code assistance directly within the Neovim editor.",
"groups": [
{
"name": "Chat Buffer",
"system_prompt": "I've grouped a number of files together into a group I'm calling \"${group_name}\". The chat buffer is a Neovim buffer which allows a user to interact with an LLM. The buffer is formatted as Markdown with a user's content residing under a H2 header. The user types their message, saves the buffer and the plugin then uses Tree-sitter to parse the buffer, extracting the contents and sending to an adapter which connects to the user's chosen LLM. The response back from the LLM is streamed into the buffer under another H2 header. The user is then free to respond back to the LLM.\n\nBelow are the relevant files which we will be discussing:\n\n${group_files}",
"opts": {
"remove_config_system_prompt": true
},
"vars": {
"base_dir": "lua/codecompanion/strategies/chat"
},
"files": [
{
"description": "The `${filename}` file is the entry point for the chat strategy. All methods directly relating to the chat buffer reside here.",
"path": "${base_dir}/init.lua"
}
],
"symbols": [
{
"description": "References are files, buffers, symbols or URLs that are shared with an LLM to provide additional context. The `${filename}` is where this logic sits and I've shared its symbolic outline below.",
"path": "${base_dir}/references.lua"
},
{
"description": "A watcher is when a user has toggled a specific buffer to be watched. When a message is sent to the LLM by the user, any changes made to the watched buffer are also sent, giving the LLM up to date context. The `${filename}` is where this logic sits and I've shared its symbolic outline below.",
"path": "${base_dir}/watchers.lua"
}
]
},
{
"name": "Workflows",
"system_prompt": "Within the plugin, workflows are a way for users to be able to automatically send or chain multiple prompts, sequentially, to an LLM. They do this by \"subscribing\" to a chat buffer.\n\nFocus on:\n 1. How workflows integrate with the chat buffer\n2. How they can be refactored\n3. How they can work better with the chat buffer itself.\n\nThe files to analyze are:\n${group_files}",
"opts": {
"remove_config_system_prompt": true
},
"vars": {
"base_dir": "lua/codecompanion/strategies"
},
"files": [
{
"description": "The `${filename}` is where the workflow are initiated from.",
"path": "${base_dir}/init.lua"
},
{
"description": "The `${filename}` is where the subscribers logic resides.",
"path": "${base_dir}/chat/subscribers.lua"
},
{
"description": "The `${filename}` file is the entry point for the chat strategy, which is called the `chat buffer`. All methods directly relating to the chat buffer reside here.",
"path": "${base_dir}/chat/init.lua"
},
{
"description": "An example workflow can be seen below:",
"path": "tests/stubs/workflow.lua"
}
]
},
{
"name": "Tests",
"system_prompt": "The plugin uses a testing framework called Mini.Test. The tests are written in Lua and are located in the `tests` directory. The tests are run using the `make test` command. The tests are written in a BDD style and are used to ensure the plugin is functioning as expected.",
"opts": {
"remove_config_system_prompt": true
},
"urls": [
{
"auto_restore_cache": true,
"description": "Below is the Mini.Test documentation:",
"url": "https://raw.githubusercontent.com/echasnovski/mini.nvim/refs/heads/main/TESTING.md"
}
],
"files": [
{
"description": "I've included the test helper file as well:",
"path": "tests/helpers.lua"
}
]
},
{
"name": "Adapters",
"system_prompt": "In the CodeCompanion plugin, adapters are used to connect to LLMs. The adapters contain various options for the LLM's endpoint alongside a defined schema for properties such as the model, temperature, top k, top p etc. The adapters also contain various handler functions which define how messages which are sent to the LLM should be formatted alongside how output from the LLM should be received and displayed in the chat buffer. The adapters are defined in the `adapters` directory.",
"opts": {
"remove_config_system_prompt": true
},
"vars": {
"base_dir": "lua/codecompanion"
},
"files": [
{
"description": "Each LLM has their own adapter. This allows for LLM settings to be generated from the schema table in an adapter before they're sent to the LLM via the http file. ",
"path": "${base_dir}/adapters/init.lua"
},
{
"description": "Adapters are then passed to the http client which sends requests to LLMs via Curl:",
"path": "${base_dir}/http.lua"
},
{
"description": "Adapters must follow a schema. The validation and how schema values are extracted from the table schema is defined in:",
"path": "${base_dir}/schema.lua"
}
]
},
{
"name": "Inline",
"system_prompt": "In the CodeCompanion plugin, the inline strategy allows user's to prompt LLMs to write code directly into a Neovim buffer. To make the experience as smooth as possible, the user can just send a prompt like 'refactor this class' and the LLM will generate code to answer the question, alongside providing a determination on where to place the code. This is called the placement.",
"opts": {
"remove_config_system_prompt": true
},
"vars": {
"base_dir": "lua/codecompanion"
},
"files": [
{
"description": "This is the entry point for the inline strategy. All methods directly relating to the inline strategy reside here. I'm in the process of refactoring this which is where I will seek your guidance. You can see how it leverages adapters to connect to an LLM and receive the response before feeding it back into a Neovim buffer.",
"path": "${base_dir}/strategies/inline/init.lua"
},
{
"description": "Adapters are then passed to the http client which sends requests to LLMs via Curl. Note that inline adapters have streaming turned off.",
"path": "${base_dir}/http.lua"
},
{
"description": "I'm including an example adapter. In this case for OpenAI. You'll see that it has a handler called 'inline_output' which handles how the output is fed back to the inline strategy.",
"path": "${base_dir}/adapters/openai.lua"
},
{
"description": "There are many entry points to make an inline edit. Most commonly is via the `:CodeCompanion` command:",
"path": "${base_dir}/commands.lua"
},
{
"description": "Including a link to the test file:",
"path": "tests/strategies/inline/test_inline.lua"
}
],
"urls": [
{
"auto_restore_cache": true,
"description": "This is the inline strategy file before I started the refactorng:",
"url": "https://raw.githubusercontent.com/olimorris/codecompanion.nvim/refs/heads/main/lua/codecompanion/strategies/inline/init.lua"
}
]
}
]
}