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: src/core/assistant-message/parse-assistant-message.ts
+4-1Lines changed: 4 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -55,7 +55,10 @@ export function parseAssistantMessage(assistantMessage: string) {
55
55
56
56
// special case for write_to_file where file contents could contain the closing tag, in which case the param would have closed and we end up with the rest of the file contents here. To work around this, we get the string between the starting content tag and the LAST content tag.
Copy file name to clipboardExpand all lines: src/core/prompts/commands.ts
+58Lines changed: 58 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -87,3 +87,61 @@ Example:
87
87
88
88
</explicit_instructions>\n
89
89
`
90
+
91
+
exportconstnewRuleToolResponse=()=>
92
+
`<explicit_instructions type="new_rule">
93
+
The user has explicitly asked you to help them create a new Cline rule file inside the .clinerules top-level directory based on the conversation up to this point in time. The user may have provided instructions or additional information for you to consider when creating the new Cline rule.
94
+
When creating a new Cline rule file, you should NOT overwrite or alter an existing Cline rule file. To create the Cline rule file you MUST use the new_rule tool. The new_rule tool can be used in either of the PLAN or ACT modes.
95
+
96
+
The new_rule tool is defined below:
97
+
98
+
Description:
99
+
Your task is to create a new Cline rule file which includes guidelines on how to approach developing code in tandem with the user, which can be either project specific or cover more global rules. This includes but is not limited to: desired conversational style, favorite project dependencies, coding styles, naming conventions, architectural choices, ui/ux preferences, etc.
100
+
The Cline rule file must be formatted as markdown and be a '.md' file. The name of the file you generate must be as succinct as possible and be encompassing the main overarching concept of the rules you added to the file (e.g., 'memory-bank.md' or 'project-overview.md').
101
+
102
+
Parameters:
103
+
- Path: (required) The path of the file to write to (relative to the current working directory). This will be the Cline rule file you create, and it must be placed inside the .clinerules top-level directory (create this if it doesn't exist). The filename created CANNOT be "default-clineignore.md". For filenames, use hyphens ("-") instead of underscores ("_") to separate words.
104
+
- Content: (required) The content to write to the file. ALWAYS provide the COMPLETE intended content of the file, without any truncation or omissions. You MUST include ALL parts of the file, even if they haven't been modified. The content for the Cline rule file MUST be created according to the following instructions:
105
+
1. Format the Cline rule file to have distinct guideline sections, each with their own markdown heading, starting with "## Brief overview". Under each of these headings, include bullet points fully fleshing out the details, with examples and/or trigger cases ONLY when applicable.
106
+
2. These guidelines can be specific to the task(s) or project worked on thus far, or cover more high-level concepts. Guidelines can include coding conventions, general design patterns, preferred tech stack including favorite libraries and language, communication style with Cline (verbose vs concise), prompting strategies, naming conventions, testing strategies, comment verbosity, time spent on architecting prior to development, and other preferences.
107
+
3. When creating guidelines, you should not invent preferences or make assumptions based on what you think a typical user might want. These should be specific to the conversation you had with the user. Your guidelines / rules should not be overly verbose.
108
+
4. Your guidelines should NOT be a recollection of the conversation up to this point in time, meaning you should NOT be including arbitrary details of the conversation.
109
+
110
+
Usage:
111
+
<new_rule>
112
+
<path>.clinerules/{file name}.md</path>
113
+
<content>Cline rule file content here</content>
114
+
</new_rule>
115
+
116
+
Example:
117
+
<new_rule>
118
+
<path>.clinerules/project-preferences.md</path>
119
+
<content>
120
+
## Brief overview
121
+
[Brief description of the rules, including if this set of guidelines is project-specific or global]
122
+
123
+
## Communication style
124
+
- [Description, rule, preference, instruction]
125
+
- [...]
126
+
127
+
## Development workflow
128
+
- [Description, rule, preference, instruction]
129
+
- [...]
130
+
131
+
## Coding best practices
132
+
- [Description, rule, preference, instruction]
133
+
- [...]
134
+
135
+
## Project context
136
+
- [Description, rule, preference, instruction]
137
+
- [...]
138
+
139
+
## Other guidelines
140
+
- [Description, rule, preference, instruction]
141
+
- [...]
142
+
</content>
143
+
</new_rule>
144
+
145
+
Below is the user's input when they indicated that they wanted to create a new Cline rule file.
// error handling if the user uses the /newrule command & their .clinerules is a file, for file read operations didnt work properly
3500
+
if(clinerulesError===true){
3501
+
awaitthis.say(
3502
+
"error",
3503
+
"Issue with processing the /newrule command. Double check that, if '.clinerules' already exists, it's a directory and not a file. Otherwise there was an issue referencing this file/directory.",
3504
+
)
3505
+
}
3506
+
3486
3507
userContent=parsedUserContent
3487
3508
// add environment details as its own text block, separate from tool results
// This is a temporary solution to dynamically load context mentions from tool results. It checks for the presence of tags that indicate that the tool was rejected and feedback was provided (see formatToolDeniedFeedback, attemptCompletion, executeCommand, and consecutiveMistakeCount >= 3) or "<answer>" (see askFollowupQuestion), we place all user generated content in these tags so they can effectively be used as markers for when we should parse mentions). However if we allow multiple tools responses in the future, we will need to parse mentions specifically within the user content tags.
3773
3797
// (Note: this caused the @/ import alias bug where file contents were being parsed as well, since v2 converted tool results to text blocks)
3774
-
Promise.all(
3798
+
returnawaitPromise.all(
3775
3799
userContent.map(async(block)=>{
3776
3800
if(block.type==="text"){
3777
3801
// We need to ensure any user generated content is wrapped in one of these tags so that we know to parse mentions
0 commit comments