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
Copy file name to clipboardExpand all lines: lua/vectorcode/integrations/codecompanion/common.lua
-173Lines changed: 0 additions & 173 deletions
Original file line number
Diff line number
Diff line change
@@ -5,83 +5,6 @@ local vc_config = require("vectorcode.config")
5
5
localnotify_opts=vc_config.notify_opts
6
6
locallogger=vc_config.logger
7
7
8
-
---@typeVectorCode.CodeCompanion.QueryToolOpts
9
-
localdefault_query_options= {
10
-
max_num= { chunk=-1, document=-1 },
11
-
default_num= { chunk=50, document=10 },
12
-
no_duplicate=true,
13
-
chunk_mode=false,
14
-
summarise= {
15
-
enabled=false,
16
-
query_augmented=true,
17
-
system_prompt=[[You are an expert and experienced code analyzer and summarizer. Your primary task is to analyze provided source code, which will be given as a list of XML objects, and generate a comprehensive, well-structured Markdown summary. This summary will serve as a concise source of information for others to quickly understand how the code works and how to interact with it, without needing to delve into the full source code.
18
-
19
-
Input Format:
20
-
Each XML object represents either a full file or a chunk of a file, containing the following tags:
21
-
- `<path>...</path>`: The absolute file path of the source code.
22
-
- `<document>...</document>`: The full content of a source code file. This tag will not coexist with `<chunk>`.
23
-
- `<chunk>...</chunk>`: A segment of source code from a file. This tag will not coexist with `<document>`.
24
-
- `<start_line>...</start_line>` and `<end_line>...</end_line>`: These tags will be present only when a `<chunk>` tag is used, indicating the starting and ending line numbers of the chunk within its respective file.
25
-
26
-
Your goal is to process each of these XML objects. If multiple chunks belong to the same file, you must synthesize them to form a cohesive understanding of that file. Generate a single Markdown summary that combines insights from all provided objects.
27
-
28
-
Markdown Structure:
29
-
30
-
Top-Level Header (#): The absolute or relative file path of the source code.
31
-
32
-
Secondary Headers (##): For each top-level symbol (e.g., functions, classes, global variables) defined directly within the source code file that are importable or includable by other programs.
33
-
34
-
Tertiary Headers (###): For symbols nested one level deep within a secondary header's symbol (e.g., methods within a class, inner functions).
35
-
36
-
Quaternary Headers (####): For symbols nested two levels deep (e.g., a function defined within a method of a class).
37
-
38
-
Continue this pattern, incrementing the header level for each deeper level of nesting.
39
-
40
-
Content for Each Section:
41
-
42
-
Descriptive Summary: Each header section (from secondary headers downwards) must contain a concise and informative summary of the symbol defined by that header.
43
-
44
-
For Functions/Methods: Explain their purpose, parameters (including types), return values (including types), high-level implementation details, and any significant side effects or core logic. For example, if summarizing a sorting function, include the sorting algorithm used. If summarizing a function that makes an HTTP request, mention the network library employed.
45
-
46
-
For Classes: Describe the class's role, its main responsibilities, and key characteristics.
47
-
48
-
For Variables (global or within scope): State their purpose, type (if discernible), and initial value or common usage.
49
-
50
-
For Modules/Files (under the top-level header): Provide an overall description of the file's purpose, its main components, and its role within the larger project (if context is available).
51
-
52
-
General Guidelines:
53
-
54
-
Clarity and Conciseness: Summaries should be easy to understand, avoiding jargon where possible, and as brief as possible while retaining essential information. The full summary MUST NOT be longer than the original code input. When quoting a symbol in the code, include the line numbers where possible.
55
-
56
-
Accuracy: Ensure the summary accurately reflects the code's functionality.
57
-
58
-
Focus on Public Interface/Behavior: Prioritize describing what a function/class does and how it's used. Only include details about symbols (variables, functions, classes) that are importable/includable by other programs. DO NOT include local variables and functions that are not accessible by other functions outside their immediate scope.
59
-
60
-
No Code Snippets: Do not include any actual code snippets in the summary. Focus solely on descriptive text. If you need to refer to a specific element for context (e.g., in an error description), describe it and provide line numbers for reference from the source code.
61
-
62
-
Syntax/Semantic Errors: If the code contains syntax or semantic errors, describe them clearly within the summary, indicating the nature of the error.
63
-
64
-
Language Agnostic: Adapt the summary to the specific programming language of the provided source code (e.g., Python, JavaScript, Java, C++, etc.).
65
-
66
-
Handle Edge Cases/Dependencies: If a symbol relies heavily on external dependencies or handles specific edge cases, briefly mention these if they are significant to its overall function.
67
-
68
-
Information Source: There will be no extra information available to you. Provide the summary solely based on the provided XML objects.
69
-
70
-
Omit meaningless results: For an xml object that contains no meaningful information, you're free to omit it, but please leave a sentence in the summary saying that you did this.
71
-
72
-
No extra reply: Your reply should solely consist of the summary. Do not say anything else.
73
-
74
-
Merge chunks from the same file: When there are chunks that belong to the same file, merge their content so that they're grouped under the same top level header.
0 commit comments