@tencent-ai/codebuddy-code 2.27.3 → 2.28.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +40 -0
- package/dist/codebuddy.js +3 -3
- package/package.json +1 -1
- package/product.cloudhosted.json +40 -2
- package/product.internal.json +21 -2
- package/product.ioa.json +24 -6
- package/product.json +27 -3
- package/product.selfhosted.json +2 -2
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@tencent-ai/codebuddy-code",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.28.0",
|
|
4
4
|
"description": "Use CodeBuddy, Tencent's AI assistant, right from your terminal. CodeBuddy can understand your codebase, edit files, run terminal commands, and handle entire workflows for you.",
|
|
5
5
|
"main": "lib/node/index.js",
|
|
6
6
|
"typings": "lib/node/index.d.ts",
|
package/product.cloudhosted.json
CHANGED
|
@@ -7,6 +7,8 @@
|
|
|
7
7
|
"models": [
|
|
8
8
|
"glm-4.7",
|
|
9
9
|
"glm-4.6",
|
|
10
|
+
"glm-4.6v",
|
|
11
|
+
"deepseek-v3-2-volc",
|
|
10
12
|
"deepseek-v3.1",
|
|
11
13
|
"deepseek-v3-0324"
|
|
12
14
|
],
|
|
@@ -186,6 +188,25 @@
|
|
|
186
188
|
"supportsImages": false,
|
|
187
189
|
"maxAllowedSize": 56000
|
|
188
190
|
},
|
|
191
|
+
{
|
|
192
|
+
"credits": "x0.26 credits",
|
|
193
|
+
"id": "deepseek-v3-2-volc",
|
|
194
|
+
"name": "DeepSeek-V3.2",
|
|
195
|
+
"vendor": "e",
|
|
196
|
+
"maxOutputTokens": 32000,
|
|
197
|
+
"maxInputTokens": 96000,
|
|
198
|
+
"supportsToolCall": true,
|
|
199
|
+
"supportsImages": false,
|
|
200
|
+
"disabledMultimodal": true,
|
|
201
|
+
"maxAllowedSize": 96000,
|
|
202
|
+
"supportsReasoning": true,
|
|
203
|
+
"onlyReasoning": true,
|
|
204
|
+
"temperature": 1,
|
|
205
|
+
"reasoning": {
|
|
206
|
+
"effort": "medium",
|
|
207
|
+
"summary": "auto"
|
|
208
|
+
}
|
|
209
|
+
},
|
|
189
210
|
{
|
|
190
211
|
"credits": "x0.20 credits",
|
|
191
212
|
"id": "glm-4.7",
|
|
@@ -200,6 +221,23 @@
|
|
|
200
221
|
"supportsReasoning": true,
|
|
201
222
|
"temperature": 1
|
|
202
223
|
},
|
|
224
|
+
{
|
|
225
|
+
"credits": "x0.10 credits",
|
|
226
|
+
"id": "glm-4.6v",
|
|
227
|
+
"name": "GLM-4.6V",
|
|
228
|
+
"vendor": "e",
|
|
229
|
+
"maxOutputTokens": 32000,
|
|
230
|
+
"maxInputTokens": 128000,
|
|
231
|
+
"supportsToolCall": true,
|
|
232
|
+
"supportsImages": true,
|
|
233
|
+
"supportsReasoning": true,
|
|
234
|
+
"temperature": 1,
|
|
235
|
+
"reasoning": {
|
|
236
|
+
"effort": "medium",
|
|
237
|
+
"summary": "auto"
|
|
238
|
+
},
|
|
239
|
+
"maxAllowedSize": 128000
|
|
240
|
+
},
|
|
203
241
|
{
|
|
204
242
|
"credits": "x0.20 credits",
|
|
205
243
|
"id": "glm-4.6",
|
|
@@ -257,6 +295,6 @@
|
|
|
257
295
|
"BillingNotice": false,
|
|
258
296
|
"CustomModelsJSON": true
|
|
259
297
|
},
|
|
260
|
-
"commit": "
|
|
261
|
-
"date": "2026-01-
|
|
298
|
+
"commit": "f9d1137d488807bbbaa1e00d7e5022b103bda0e9",
|
|
299
|
+
"date": "2026-01-05T15:02:36.307Z"
|
|
262
300
|
}
|
package/product.internal.json
CHANGED
|
@@ -9,6 +9,7 @@
|
|
|
9
9
|
"models": [
|
|
10
10
|
"glm-4.7",
|
|
11
11
|
"glm-4.6",
|
|
12
|
+
"glm-4.6v",
|
|
12
13
|
"deepseek-v3-2-volc",
|
|
13
14
|
"deepseek-v3.1",
|
|
14
15
|
"deepseek-v3-0324"
|
|
@@ -202,6 +203,7 @@
|
|
|
202
203
|
"maxAllowedSize": 56000
|
|
203
204
|
},
|
|
204
205
|
{
|
|
206
|
+
"credits": "x0.26 credits",
|
|
205
207
|
"id": "deepseek-v3-2-volc",
|
|
206
208
|
"name": "DeepSeek-V3.2",
|
|
207
209
|
"vendor": "e",
|
|
@@ -233,6 +235,23 @@
|
|
|
233
235
|
"supportsReasoning": true,
|
|
234
236
|
"temperature": 1
|
|
235
237
|
},
|
|
238
|
+
{
|
|
239
|
+
"credits": "x0.10 credits",
|
|
240
|
+
"id": "glm-4.6v",
|
|
241
|
+
"name": "GLM-4.6V",
|
|
242
|
+
"vendor": "e",
|
|
243
|
+
"maxOutputTokens": 32000,
|
|
244
|
+
"maxInputTokens": 128000,
|
|
245
|
+
"supportsToolCall": true,
|
|
246
|
+
"supportsImages": true,
|
|
247
|
+
"supportsReasoning": true,
|
|
248
|
+
"temperature": 1,
|
|
249
|
+
"reasoning": {
|
|
250
|
+
"effort": "medium",
|
|
251
|
+
"summary": "auto"
|
|
252
|
+
},
|
|
253
|
+
"maxAllowedSize": 128000
|
|
254
|
+
},
|
|
236
255
|
{
|
|
237
256
|
"credits": "x0.20 credits",
|
|
238
257
|
"id": "glm-4.6",
|
|
@@ -278,6 +297,6 @@
|
|
|
278
297
|
"BillingNotice": false,
|
|
279
298
|
"CustomModelsJSON": true
|
|
280
299
|
},
|
|
281
|
-
"commit": "
|
|
282
|
-
"date": "2026-01-
|
|
300
|
+
"commit": "f9d1137d488807bbbaa1e00d7e5022b103bda0e9",
|
|
301
|
+
"date": "2026-01-05T15:02:33.732Z"
|
|
283
302
|
}
|
package/product.ioa.json
CHANGED
|
@@ -20,6 +20,7 @@
|
|
|
20
20
|
"gpt-5.1-codex-mini",
|
|
21
21
|
"glm-4.7-ioa",
|
|
22
22
|
"glm-4.6-ioa",
|
|
23
|
+
"glm-4.6v-ioa",
|
|
23
24
|
"deepseek-v3-2-volc-ioa"
|
|
24
25
|
],
|
|
25
26
|
"commands": [
|
|
@@ -88,7 +89,9 @@
|
|
|
88
89
|
"name": "compact",
|
|
89
90
|
"instructions": "compact-agent-prompt",
|
|
90
91
|
"description": "compact agent",
|
|
91
|
-
"tools": [
|
|
92
|
+
"tools": [
|
|
93
|
+
"Read"
|
|
94
|
+
],
|
|
92
95
|
"tags": [
|
|
93
96
|
"cli",
|
|
94
97
|
"compact"
|
|
@@ -102,9 +105,7 @@
|
|
|
102
105
|
"cli",
|
|
103
106
|
"content-analyzer"
|
|
104
107
|
],
|
|
105
|
-
"tools": [
|
|
106
|
-
"Read"
|
|
107
|
-
]
|
|
108
|
+
"tools": []
|
|
108
109
|
},
|
|
109
110
|
{
|
|
110
111
|
"name": "terminalTitleGenerator",
|
|
@@ -226,6 +227,23 @@
|
|
|
226
227
|
"supportsReasoning": true,
|
|
227
228
|
"temperature": 1
|
|
228
229
|
},
|
|
230
|
+
{
|
|
231
|
+
"credits": "x0.00 credits",
|
|
232
|
+
"id": "glm-4.6v-ioa",
|
|
233
|
+
"name": "GLM-4.6V",
|
|
234
|
+
"vendor": "e",
|
|
235
|
+
"maxOutputTokens": 32000,
|
|
236
|
+
"maxInputTokens": 128000,
|
|
237
|
+
"supportsToolCall": true,
|
|
238
|
+
"supportsImages": true,
|
|
239
|
+
"supportsReasoning": true,
|
|
240
|
+
"temperature": 1,
|
|
241
|
+
"reasoning": {
|
|
242
|
+
"effort": "medium",
|
|
243
|
+
"summary": "auto"
|
|
244
|
+
},
|
|
245
|
+
"maxAllowedSize": 128000
|
|
246
|
+
},
|
|
229
247
|
{
|
|
230
248
|
"credits": "x0.00 credits",
|
|
231
249
|
"id": "glm-4.6-ioa",
|
|
@@ -486,6 +504,6 @@
|
|
|
486
504
|
"BillingNotice": false,
|
|
487
505
|
"CustomModelsJSON": true
|
|
488
506
|
},
|
|
489
|
-
"commit": "
|
|
490
|
-
"date": "2026-01-
|
|
507
|
+
"commit": "f9d1137d488807bbbaa1e00d7e5022b103bda0e9",
|
|
508
|
+
"date": "2026-01-05T15:02:35.009Z"
|
|
491
509
|
}
|
package/product.json
CHANGED
|
@@ -367,6 +367,10 @@
|
|
|
367
367
|
"name": "compact-prompt",
|
|
368
368
|
"template": "CRITICAL INSTRUCTION: DO NOT call ANY tools during this summarization task. This is a READ-ONLY analysis task. You should ONLY output text analysis and summary. NO tool calls (Read, Write, Edit, Bash, Grep, Glob, etc.) are needed or permitted.\n\nYour task is to create a detailed summary of the conversation so far, paying close attention to the user's explicit requests and your previous actions.\nThis summary should be thorough in capturing technical details, code patterns, and architectural decisions that would be essential for continuing development work without losing context.\n\nIMPORTANT: This is a summarization task ONLY. Do not use Read, Write, Edit, Bash, Grep, Glob, or any other tools. Simply analyze the conversation history that has been provided to you and create a text summary.\n\nBefore providing your final summary, wrap your analysis in <analysis> tags to organize your thoughts and ensure you've covered all necessary points. In your analysis process:\n\n1. Chronologically analyze each message and section of the conversation. For each section thoroughly identify:\n - The user's explicit requests and intents\n - Your approach to addressing the user's requests\n - Key decisions, technical concepts and code patterns\n - Specific details like:\n - file names\n - full code snippets\n - function signatures\n - file edits\n - Errors that you ran into and how you fixed them\n - Pay special attention to specific user feedback that you received, especially if the user told you to do something differently.\n2. Double-check for technical accuracy and completeness, addressing each required element thoroughly.\n\nYour summary should include the following sections:\n\n1. Primary Request and Intent: Capture all of the user's explicit requests and intents in detail\n2. Key Technical Concepts: List all important technical concepts, technologies, and frameworks discussed.\n3. Files and Code Sections: Enumerate specific files and code sections examined, modified, or created. Pay special attention to the most recent messages and include full code snippets where applicable and include a summary of why this file read or edit is important.\n4. Errors and fixes: List all errors that you ran into, and how you fixed them. Pay special attention to specific user feedback that you received, especially if the user told you to do something differently.\n5. Problem Solving: Document problems solved and any ongoing troubleshooting efforts.\n6. All user messages: List ALL user messages that are not tool results. These are critical for understanding the users' feedback and changing intent.\n6. Pending Tasks: Outline any pending tasks that you have explicitly been asked to work on.\n7. Current Work: Describe in detail precisely what was being worked on immediately before this summary request, paying special attention to the most recent messages from both user and assistant. Include file names and code snippets where applicable. DO NOT read files or call tools - only describe what was already discussed in the conversation.\n8. Optional Next Step: List the next step that you will take that is related to the most recent work you were doing. This should be a description of what to do next, NOT an actual execution. Do not call any tools. Simply describe the intended action. IMPORTANT: ensure that this step is DIRECTLY in line with the user's most recent explicit requests, and the task you were working on immediately before this summary request. If your last task was concluded, then only list next steps if they are explicitly in line with the users request. Do not start on tangential requests or really old requests that were already completed without confirming with the user first.\n If there is a next step, include direct quotes from the most recent conversation showing exactly what task you were working on and where you left off. This should be verbatim to ensure there's no drift in task interpretation.\n\nHere's an example of how your output should be structured:\n\n<example>\n<analysis>\n[Your thought process, ensuring all points are covered thoroughly and accurately]\n</analysis>\n\n<summary>\n1. Primary Request and Intent:\n [Detailed description]\n\n2. Key Technical Concepts:\n - [Concept 1]\n - [Concept 2]\n - [...]\n\n3. Files and Code Sections:\n - [File Name 1]\n - [Summary of why this file is important]\n - [Summary of the changes made to this file, if any]\n - [Important Code Snippet]\n - [File Name 2]\n - [Important Code Snippet]\n - [...]\n\n4. Errors and fixes:\n - [Detailed description of error 1]:\n - [How you fixed the error]\n - [User feedback on the error if any]\n - [...]\n\n5. Problem Solving:\n [Description of solved problems and ongoing troubleshooting]\n\n6. All user messages:\n - [Detailed non tool use user message]\n - [...]\n\n7. Pending Tasks:\n - [Task 1]\n - [Task 2]\n - [...]\n\n8. Current Work:\n [Precise description of current work]\n\n9. Optional Next Step:\n [Optional Next step to take]\n\n</summary>\n</example>\n\nPlease provide your summary based on the conversation so far, following this structure and ensuring precision and thoroughness in your response.\n\nThere may be additional summarization instructions provided in the included context. If so, remember to follow these instructions when creating the above summary. Examples of instructions include:\n<example>\n## Compact Instructions\nWhen summarizing the conversation focus on typescript code changes and also remember the mistakes you made and how you fixed them.\n</example>\n\n<example>\n# Summary instructions\nWhen you are using compact - please focus on test output and code changes. Include file reads verbatim.\n</example>\n\n"
|
|
369
369
|
},
|
|
370
|
+
{
|
|
371
|
+
"name": "command-security-review-prompt",
|
|
372
|
+
"template": "You are a senior security engineer conducting a focused security review of the changes on this branch.\n\nGIT STATUS:\n\n```\n!`git status`\n```\n\nFILES MODIFIED:\n\n```\n!`git diff --name-only origin/HEAD...`\n```\n\nCOMMITS:\n\n```\n!`git log --no-decorate origin/HEAD...`\n```\n\nDIFF CONTENT:\n\n```\n!`git diff --merge-base origin/HEAD`\n```\n\nReview the complete diff above. This contains all code changes in the PR.\n\n\nOBJECTIVE:\nPerform a security-focused code review to identify HIGH-CONFIDENCE security vulnerabilities that could have real exploitation potential. This is not a general code review - focus ONLY on security implications newly added by this PR. Do not comment on existing security concerns.\n\nCRITICAL INSTRUCTIONS:\n1. MINIMIZE FALSE POSITIVES: Only flag issues where you're >80% confident of actual exploitability\n2. AVOID NOISE: Skip theoretical issues, style concerns, or low-impact findings\n3. FOCUS ON IMPACT: Prioritize vulnerabilities that could lead to unauthorized access, data breaches, or system compromise\n4. EXCLUSIONS: Do NOT report the following issue types:\n - Denial of Service (DOS) vulnerabilities, even if they allow service disruption\n - Secrets or sensitive data stored on disk (these are handled by other processes)\n - Rate limiting or resource exhaustion issues\n\nSECURITY CATEGORIES TO EXAMINE:\n\n**Input Validation Vulnerabilities:**\n- SQL injection via unsanitized user input\n- Command injection in system calls or subprocesses\n- XXE injection in XML parsing\n- Template injection in templating engines\n- NoSQL injection in database queries\n- Path traversal in file operations\n\n**Authentication & Authorization Issues:**\n- Authentication bypass logic\n- Privilege escalation paths\n- Session management flaws\n- JWT token vulnerabilities\n- Authorization logic bypasses\n\n**Crypto & Secrets Management:**\n- Hardcoded API keys, passwords, or tokens\n- Weak cryptographic algorithms or implementations\n- Improper key storage or management\n- Cryptographic randomness issues\n- Certificate validation bypasses\n\n**Injection & Code Execution:**\n- Remote code execution via deseralization\n- Pickle injection in Python\n- YAML deserialization vulnerabilities\n- Eval injection in dynamic code execution\n- XSS vulnerabilities in web applications (reflected, stored, DOM-based)\n\n**Data Exposure:**\n- Sensitive data logging or storage\n- PII handling violations\n- API endpoint data leakage\n- Debug information exposure\n\nAdditional notes:\n- Even if something is only exploitable from the local network, it can still be a HIGH severity issue\n\nANALYSIS METHODOLOGY:\n\nPhase 1 - Repository Context Research (Use file search tools):\n- Identify existing security frameworks and libraries in use\n- Look for established secure coding patterns in the codebase\n- Examine existing sanitization and validation patterns\n- Understand the project's security model and threat model\n\nPhase 2 - Comparative Analysis:\n- Compare new code changes against existing security patterns\n- Identify deviations from established secure practices\n- Look for inconsistent security implementations\n- Flag code that introduces new attack surfaces\n\nPhase 3 - Vulnerability Assessment:\n- Examine each modified file for security implications\n- Trace data flow from user inputs to sensitive operations\n- Look for privilege boundaries being crossed unsafely\n- Identify injection points and unsafe deserialization\n\nREQUIRED OUTPUT FORMAT:\n\nYou MUST output your findings in markdown. The markdown output should contain the file, line number, severity, category (e.g. `sql_injection` or `xss`), description, exploit scenario, and fix recommendation.\n\nFor example:\n\n# Vuln 1: XSS: `foo.py:42`\n\n* Severity: High\n* Description: User input from `username` parameter is directly interpolated into HTML without escaping, allowing reflected XSS attacks\n* Exploit Scenario: Attacker crafts URL like /bar?q=<script>alert(document.cookie)</script> to execute JavaScript in victim's browser, enabling session hijacking or data theft\n* Recommendation: Use Flask's escape() function or Jinja2 templates with auto-escaping enabled for all user inputs rendered in HTML\n\nSEVERITY GUIDELINES:\n- **HIGH**: Directly exploitable vulnerabilities leading to RCE, data breach, or authentication bypass\n- **MEDIUM**: Vulnerabilities requiring specific conditions but with significant impact\n- **LOW**: Defense-in-depth issues or lower-impact vulnerabilities\n\nCONFIDENCE SCORING:\n- 0.9-1.0: Certain exploit path identified, tested if possible\n- 0.8-0.9: Clear vulnerability pattern with known exploitation methods\n- 0.7-0.8: Suspicious pattern requiring specific conditions to exploit\n- Below 0.7: Don't report (too speculative)\n\nFINAL REMINDER:\nFocus on HIGH and MEDIUM findings only. Better to miss some theoretical issues than flood the report with false positives. Each finding should be something a security engineer would confidently raise in a PR review.\n\nFALSE POSITIVE FILTERING:\n\n> You do not need to run commands to reproduce the vulnerability, just read the code to determine if it is a real vulnerability. Do not use the bash tool or write to any files.\n>\n> HARD EXCLUSIONS - Automatically exclude findings matching these patterns:\n> 1. Denial of Service (DOS) vulnerabilities or resource exhaustion attacks.\n> 2. Secrets or credentials stored on disk if they are otherwise secured.\n> 3. Rate limiting concerns or service overload scenarios.\n> 4. Memory consumption or CPU exhaustion issues.\n> 5. Lack of input validation on non-security-critical fields without proven security impact.\n> 6. Input sanitization concerns for GitHub Action workflows unless they are clearly triggerable via untrusted input.\n> 7. A lack of hardening measures. Code is not expected to implement all security best practices, only flag concrete vulnerabilities.\n> 8. Race conditions or timing attacks that are theoretical rather than practical issues. Only report a race condition if it is concretely problematic.\n> 9. Vulnerabilities related to outdated third-party libraries. These are managed separately and should not be reported here.\n> 10. Memory safety issues such as buffer overflows or use-after-free-vulnerabilities are impossible in rust. Do not report memory safety issues in rust or any other memory safe languages.\n> 11. Files that are only unit tests or only used as part of running tests.\n> 12. Log spoofing concerns. Outputting un-sanitized user input to logs is not a vulnerability.\n> 13. SSRF vulnerabilities that only control the path. SSRF is only a concern if it can control the host or protocol.\n> 14. Including user-controlled content in AI system prompts is not a vulnerability.\n> 15. Regex injection. Injecting untrusted content into a regex is not a vulnerability.\n> 16. Regex DOS concerns.\n> 16. Insecure documentation. Do not report any findings in documentation files such as markdown files.\n> 17. A lack of audit logs is not a vulnerability.\n>\n> PRECEDENTS -\n> 1. Logging high value secrets in plaintext is a vulnerability. Logging URLs is assumed to be safe.\n> 2. UUIDs can be assumed to be unguessable and do not need to be validated.\n> 3. Environment variables and CLI flags are trusted values. Attackers are generally not able to modify them in a secure environment. Any attack that relies on controlling an environment variable is invalid.\n> 4. Resource management issues such as memory or file descriptor leaks are not valid.\n> 5. Subtle or low impact web vulnerabilities such as tabnabbing, XS-Leaks, prototype pollution, and open redirects should not be reported unless they are extremely high confidence.\n> 6. React and Angular are generally secure against XSS. These frameworks do not need to sanitize or escape user input unless it is using dangerouslySetInnerHTML, bypassSecurityTrustHtml, or similar methods. Do not report XSS vulnerabilities in React or Angular components or tsx files unless they are using unsafe methods.\n> 7. Most vulnerabilities in github action workflows are not exploitable in practice. Before validating a github action workflow vulnerability ensure it is concrete and has a very specific attack path.\n> 8. A lack of permission checking or authentication in client-side JS/TS code is not a vulnerability. Client-side code is not trusted and does not need to implement these checks, they are handled on the server-side. The same applies to all flows that send untrusted data to the backend, the backend is responsible for validating and sanitizing all inputs.\n> 9. Only include MEDIUM findings if they are obvious and concrete issues.\n> 10. Most vulnerabilities in ipython notebooks (*.ipynb files) are not exploitable in practice. Before validating a notebook vulnerability ensure it is concrete and has a very specific attack path where untrusted input can trigger the vulnerability.\n> 11. Logging non-PII data is not a vulnerability even if the data may be sensitive. Only report logging vulnerabilities if they expose sensitive information such as secrets, passwords, or personally identifiable information (PII).\n> 12. Command injection vulnerabilities in shell scripts are generally not exploitable in practice since shell scripts generally do not run with untrusted user input. Only report command injection vulnerabilities in shell scripts if they are concrete and have a very specific attack path for untrusted input.\n>\n> SIGNAL QUALITY CRITERIA - For remaining findings, assess:\n> 1. Is there a concrete, exploitable vulnerability with a clear attack path?\n> 2. Does this represent a real security risk vs theoretical best practice?\n> 3. Are there specific code locations and reproduction steps?\n> 4. Would this finding be actionable for a security team?\n>\n> For each finding, assign a confidence score from 1-10:\n> - 1-3: Low confidence, likely false positive or noise\n> - 4-6: Medium confidence, needs investigation\n> - 7-10: High confidence, likely true vulnerability\n\nSTART ANALYSIS:\n\nBegin your analysis now. Do this in 3 steps:\n\n1. Use a sub-task to identify vulnerabilities. Use the repository exploration tools to understand the codebase context, then analyze the PR changes for security implications. In the prompt for this sub-task, include all of the above.\n2. Then for each vulnerability identified by the above sub-task, create a new sub-task to filter out false-positives. Launch these sub-tasks as parallel sub-tasks. In the prompt for these sub-tasks, include everything in the \"FALSE POSITIVE FILTERING\" instructions.\n3. Filter out any vulnerabilities where the sub-task reported a confidence less than 8.\n\nYour final reply must contain the markdown report and nothing else.\n"
|
|
373
|
+
},
|
|
370
374
|
{
|
|
371
375
|
"name": "content-analyzer-agent-instructions",
|
|
372
376
|
"template": "You are CodeBuddy Code.\n\nYou are a specialized web content analyzer. Your role is to help users extract, analyze, and understand content from web pages based on their specific requests.\n\n## Core Capabilities:\n- Extract key information from web content\n- Summarize articles, documentation, and web pages\n- Identify relevant data points based on user queries\n- Present information in clear, structured formats\n- Answer specific questions about web content\n\n## Analysis Guidelines:\n1. **Read the user's request carefully** - Understand exactly what they're looking for\n2. **Scan the content systematically** - Look for relevant sections, headings, and data\n3. **Extract pertinent information** - Focus on content that directly addresses the user's query\n4. **Structure your response clearly** - Use headings, bullet points, and formatting for readability\n5. **Be concise yet comprehensive** - Include all relevant details without unnecessary information\n\n## Response Format:\n- Start with a brief summary of what you found\n- Organize information logically (chronological, categorical, or by importance)\n- Use markdown formatting for better readability\n- Include direct quotes when relevant\n- Highlight key findings or insights\n\n## Quality Standards:\n- Accuracy: Ensure all extracted information is correct\n- Relevance: Focus only on content that addresses the user's request\n- Clarity: Present information in an easy-to-understand format\n- Completeness: Don't miss important details that relate to the query\n\nRemember: Your goal is to be a helpful intermediary between the user and the web content, making complex or lengthy content accessible and actionable.\n"
|
|
@@ -385,7 +389,7 @@
|
|
|
385
389
|
},
|
|
386
390
|
{
|
|
387
391
|
"name": "system-reminder-md",
|
|
388
|
-
"template": "<system-reminder>\nAs you answer the user's questions, you can use the following context:\n#
|
|
392
|
+
"template": "<system-reminder>\nAs you answer the user's questions, you can use the following context:\n# codebuddyMd\nCodebase and user instructions are shown below. Be sure to adhere to these instructions. IMPORTANT: These instructions OVERRIDE any default behavior and you MUST follow them exactly as written.\n{%- for item in userMemory %}\n\nContents of {{item.filePath}} (user's private global instructions for all projects):\n\n{{item.content}}\n\n{%- endfor %}\n{%- for memoryItem in projectMemory %}\n\nContents of {{memoryItem.filePath}} (project instructions, checked into the codebase):\n\n{{memoryItem.content}}\n\n{%- endfor %}\n{%- for item in localMemory %}\n\nContents of {{item.filePath}} (user's private project instructions, not checked in):\n\n{{item.content}}\n\n{%- endfor %}\n{%- if not (userMemory.length > 0 or projectMemory.length > 0 or localMemory.length > 0) %}\n\n{%- endif %}\n IMPORTANT: this context may or may not be relevant to your tasks. You should not respond to this context unless it is highly relevant to your task.\n</system-reminder>\n"
|
|
389
393
|
},
|
|
390
394
|
{
|
|
391
395
|
"name": "system-reminder-todo-list",
|
|
@@ -776,6 +780,26 @@
|
|
|
776
780
|
"name": "statusline",
|
|
777
781
|
"description": "Set up Codebuddy Code's status line UI",
|
|
778
782
|
"prompt": "command-statusline-prompt"
|
|
783
|
+
},
|
|
784
|
+
{
|
|
785
|
+
"name": "security-review",
|
|
786
|
+
"description": "Complete a security review of the pending changes on the current branch",
|
|
787
|
+
"prompt": "command-security-review-prompt",
|
|
788
|
+
"tags": [
|
|
789
|
+
"custom"
|
|
790
|
+
],
|
|
791
|
+
"allowedTools": [
|
|
792
|
+
"Bash(git diff:*)",
|
|
793
|
+
"Bash(git status:*)",
|
|
794
|
+
"Bash(git log:*)",
|
|
795
|
+
"Bash(git show:*)",
|
|
796
|
+
"Bash(git remote show:*)",
|
|
797
|
+
"Read",
|
|
798
|
+
"Glob",
|
|
799
|
+
"Grep",
|
|
800
|
+
"LS",
|
|
801
|
+
"Task"
|
|
802
|
+
]
|
|
779
803
|
}
|
|
780
804
|
],
|
|
781
805
|
"productFeatures": {
|
|
@@ -972,6 +996,6 @@
|
|
|
972
996
|
"description": "tool-ask-user-question-description"
|
|
973
997
|
}
|
|
974
998
|
],
|
|
975
|
-
"commit": "
|
|
976
|
-
"date": "2026-01-
|
|
999
|
+
"commit": "f9d1137d488807bbbaa1e00d7e5022b103bda0e9",
|
|
1000
|
+
"date": "2026-01-05T15:02:32.478Z"
|
|
977
1001
|
}
|
package/product.selfhosted.json
CHANGED
|
@@ -196,6 +196,6 @@
|
|
|
196
196
|
"BillingNotice": false,
|
|
197
197
|
"CustomModelsJSON": true
|
|
198
198
|
},
|
|
199
|
-
"commit": "
|
|
200
|
-
"date": "2026-01-
|
|
199
|
+
"commit": "f9d1137d488807bbbaa1e00d7e5022b103bda0e9",
|
|
200
|
+
"date": "2026-01-05T15:02:37.560Z"
|
|
201
201
|
}
|