@tencent-ai/codebuddy-code 2.97.4 → 2.97.5-next.a49ca3c.20260523

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tencent-ai/codebuddy-code",
-  "version": "2.97.4",
+  "version": "2.97.5-next.a49ca3c.20260523",
   "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.",
   "main": "lib/node/index.js",
   "typings": "lib/node/index.d.ts",
@@ -29,7 +29,8 @@
     "url": "https://cnb.cool/codebuddy/codebuddy-code/-/issues"
   },
   "publishConfig": {
-    "access": "public"
+    "access": "public",
+    "tag": "next"
   },
   "scripts": {},
   "devDependencies": {},

package/product.cloudhosted.json

@@ -389,6 +389,283 @@
       "maxAllowedSize": 164000
     },
     {
+      "credits": "x0.25 credits",
+      "id": "deepseek-v4-pro",
+      "name": "Deepseek-V4-Pro",
+      "vendor": "f",
+      "maxOutputTokens": 50000,
+      "maxInputTokens": 1000000,
+      "supportsToolCall": true,
+      "supportsImages": true,
+      "maxAllowedSize": 1000000,
+      "supportsReasoning": true,
+      "onlyReasoning": true,
+      "temperature": 1,
+      "reasoning": {
+        "effort": "high",
+        "summary": "auto"
+      },
+      "descriptionEn": "DeepSeek flagship model, supporting 1M context window",
+      "descriptionZh": "DeepSeek 旗舰模型，支持 1M 上下文窗口"
+    },
+    {
+      "credits": "x0.13 credits",
+      "id": "deepseek-v4-flash",
+      "name": "Deepseek-V4-Flash",
+      "vendor": "f",
+      "maxOutputTokens": 50000,
+      "maxInputTokens": 1000000,
+      "supportsToolCall": true,
+      "supportsImages": true,
+      "maxAllowedSize": 1000000,
+      "supportsReasoning": true,
+      "onlyReasoning": true,
+      "temperature": 1,
+      "reasoning": {
+        "effort": "high",
+        "summary": "auto"
+      },
+      "descriptionEn": "DeepSeek flagship model, supporting 1M context window",
+      "descriptionZh": "DeepSeek 旗舰模型，支持 1M 上下文窗口"
+    },
+    {
+      "credits": "x0.18 credits",
+      "id": "minimax-m2.5",
+      "name": "MiniMax-M2.5",
+      "vendor": "e",
+      "maxOutputTokens": 48000,
+      "maxInputTokens": 200000,
+      "supportsToolCall": true,
+      "supportsImages": false,
+      "maxAllowedSize": 200000,
+      "supportsReasoning": true,
+      "onlyReasoning": true,
+      "temperature": 1,
+      "reasoning": {
+        "effort": "high",
+        "summary": "auto"
+      }
+    },
+    {
+      "credits": "x0.26 credits",
+      "id": "minimax-m2.7",
+      "name": "MiniMax-M2.7",
+      "vendor": "f",
+      "maxOutputTokens": 48000,
+      "maxInputTokens": 200000,
+      "supportsToolCall": true,
+      "supportsImages": true,
+      "maxAllowedSize": 200000,
+      "supportsReasoning": true,
+      "onlyReasoning": true,
+      "temperature": 1,
+      "reasoning": {
+        "effort": "medium",
+        "summary": "auto"
+      }
+    },
+    {
+      "credits": "x1.06 credits",
+      "id": "glm-5.1",
+      "name": "GLM-5.1",
+      "vendor": "e",
+      "maxOutputTokens": 48000,
+      "maxInputTokens": 200000,
+      "supportsToolCall": true,
+      "supportsImages": false,
+      "maxAllowedSize": 200000,
+      "supportsReasoning": true,
+      "onlyReasoning": true,
+      "temperature": 1,
+      "reasoning": {
+        "effort": "medium",
+        "summary": "auto"
+      }
+    },
+    {
+      "credits": "x0.80 credits",
+      "id": "glm-5.0",
+      "name": "GLM-5.0",
+      "vendor": "e",
+      "maxOutputTokens": 48000,
+      "maxInputTokens": 200000,
+      "supportsToolCall": true,
+      "supportsImages": false,
+      "disabledMultimodal": true,
+      "maxAllowedSize": 200000,
+      "supportsReasoning": true,
+      "temperature": 1
+    },
+    {
+      "credits": "x0.95 credits",
+      "id": "glm-5.0-turbo",
+      "name": "GLM-5.0-Turbo",
+      "vendor": "e",
+      "maxOutputTokens": 48000,
+      "maxInputTokens": 200000,
+      "supportsToolCall": true,
+      "supportsImages": false,
+      "maxAllowedSize": 200000,
+      "supportsReasoning": true,
+      "onlyReasoning": true,
+      "temperature": 1,
+      "reasoning": {
+        "effort": "medium",
+        "summary": "auto"
+      }
+    },
+    {
+      "credits": "x0.95 credits",
+      "id": "glm-5v-turbo",
+      "name": "GLM-5v-Turbo",
+      "vendor": "e",
+      "maxOutputTokens": 38000,
+      "maxInputTokens": 200000,
+      "supportsToolCall": true,
+      "supportsImages": true,
+      "maxAllowedSize": 200000,
+      "supportsReasoning": true,
+      "onlyReasoning": true,
+      "temperature": 1,
+      "reasoning": {
+        "effort": "medium",
+        "summary": "auto"
+      }
+    },
+    {
+      "credits": "x0.11 credits",
+      "id": "glm-4.6v",
+      "name": "GLM-4.6V",
+      "vendor": "e",
+      "maxOutputTokens": 32000,
+      "maxInputTokens": 128000,
+      "supportsToolCall": true,
+      "supportsImages": true,
+      "supportsReasoning": true,
+      "temperature": 1,
+      "reasoning": {
+        "effort": "high",
+        "summary": "auto"
+      },
+      "maxAllowedSize": 128000
+    },
+    {
+      "credits": "x0.59 credits",
+      "id": "kimi-k2.6",
+      "name": "Kimi-K2.6",
+      "vendor": "f",
+      "maxOutputTokens": 32000,
+      "maxInputTokens": 256000,
+      "supportsToolCall": true,
+      "supportsImages": true,
+      "supportsReasoning": true,
+      "temperature": 1,
+      "onlyReasoning": true,
+      "reasoning": {
+        "effort": "medium",
+        "summary": "auto"
+      },
+      "maxAllowedSize": 256000
+    },
+    {
+      "credits": "x0.45 credits",
+      "id": "kimi-k2.5",
+      "name": "Kimi-K2.5",
+      "vendor": "f",
+      "maxOutputTokens": 32000,
+      "maxInputTokens": 164000,
+      "supportsToolCall": true,
+      "supportsImages": true,
+      "supportsReasoning": true,
+      "temperature": 1,
+      "onlyReasoning": true,
+      "reasoning": {
+        "effort": "high",
+        "summary": "auto"
+      },
+      "maxAllowedSize": 164000
+    },
+    {
+      "credits": "x0.37 credits",
+      "id": "hy3-preview",
+      "name": "Hy3 preview",
+      "vendor": "j",
+      "maxOutputTokens": 64000,
+      "maxInputTokens": 192000,
+      "maxAllowedSize": 192000,
+      "supportsToolCall": true,
+      "supportsImages": true,
+      "disabledMultimodal": false,
+      "supportsReasoning": true,
+      "temperature": 0.9,
+      "onlyReasoning": true,
+      "top_p": 1,
+      "reasoning": {
+        "effort": "high",
+        "summary": "auto"
+      }
+    },
+    {
+      "id": "auto",
+      "name": "Auto",
+      "vendor": "f",
+      "maxOutputTokens": 32000,
+      "maxInputTokens": 168000,
+      "supportsToolCall": true,
+      "supportsImages": true,
+      "disabledMultimodal": false,
+      "maxAllowedSize": 168000,
+      "isDefault": true,
+      "temperature": 1,
+      "descriptionEn": "Balanced performance and speed",
+      "descriptionZh": "平衡效果与速度",
+      "tags": [
+        "craft"
+      ]
+    },
+    {
+      "credits": "x0.25 credits",
+      "id": "deepseek-v4-pro-exclusive",
+      "name": "Deepseek-V4-Pro",
+      "vendor": "f",
+      "maxOutputTokens": 50000,
+      "maxInputTokens": 1000000,
+      "supportsToolCall": true,
+      "supportsImages": true,
+      "maxAllowedSize": 1000000,
+      "supportsReasoning": true,
+      "onlyReasoning": true,
+      "temperature": 1,
+      "reasoning": {
+        "effort": "high",
+        "summary": "auto"
+      },
+      "descriptionEn": "DeepSeek flagship model, supporting 1M context window",
+      "descriptionZh": "DeepSeek 旗舰模型，支持 1M 上下文窗口"
+    },
+    {
+      "credits": "x0.04 credits",
+      "id": "hunyuan-2.0-instruct",
+      "name": "Hunyuan-2.0-Instruct",
+      "vendor": "j",
+      "maxOutputTokens": 16000,
+      "maxInputTokens": 128000,
+      "supportsToolCall": true,
+      "supportsImages": true,
+      "disabledMultimodal": false,
+      "supportsReasoning": true,
+      "temperature": 0.7,
+      "onlyReasoning": true,
+      "top_p": 0.8,
+      "top_k": 20,
+      "repetition_penalty": 1.05,
+      "reasoning": {
+        "effort": "medium",
+        "summary": "auto"
+      }
+    },
+    {
+      "credits": "x5.00 credits",
       "id": "hunyuan-image-v3.0",
       "name": "Hunyuan Image V3",
       "tags": [
@@ -417,6 +694,6 @@
     "SkillManage": false,
     "SelectImage": true
   },
-  "commit": "2c25888c2325404baecf54369991a928f8b78111",
-  "date": "2026-05-21T10:59:22.809Z"
+  "commit": "a49ca3c72eecb5bf18280b14b7be4386bbcfdd27",
+  "date": "2026-05-22T16:20:42.707Z"
 }

package/product.internal.json

@@ -643,6 +643,6 @@
       }
     }
   },
-  "commit": "2c25888c2325404baecf54369991a928f8b78111",
-  "date": "2026-05-21T10:59:22.713Z"
+  "commit": "a49ca3c72eecb5bf18280b14b7be4386bbcfdd27",
+  "date": "2026-05-22T16:20:42.618Z"
 }

package/product.ioa.json

@@ -952,6 +952,6 @@
       }
     }
   },
-  "commit": "2c25888c2325404baecf54369991a928f8b78111",
-  "date": "2026-05-21T10:59:22.763Z"
+  "commit": "a49ca3c72eecb5bf18280b14b7be4386bbcfdd27",
+  "date": "2026-05-22T16:20:42.707Z"
 }

package/product.json

@@ -537,7 +537,7 @@
     },
     {
       "name": "tool-agent-description",
-      "template": "Launch a new agent to handle complex, multi-step tasks autonomously.\n\nThe Agent tool launches specialized agents (subprocesses) that autonomously handle complex tasks. Each agent type has specific capabilities and tools available to it.\n\nAvailable agent types and the tools they have access to:\n- general-purpose: General-purpose agent for researching complex questions, searching for code, and executing multi-step tasks. When you are searching for a keyword or file and are not confident that you will find the right match in the first few tries use this agent to perform the search for you. (Tools: *)\n{%- if agents and agents.length > 0 -%}\n{%- for agent in agents -%}\n{%- if agent.asTool %}\n- {{agent.name}}{%- if agent.truncatedDescription == undefined -%}: {{agent.description}}{%- elif agent.truncatedDescription %}: {{agent.truncatedDescription}}{%- endif -%} (Tools: {%- if agent.tools and agent.tools.length > 0 -%}{{agent.tools.join(',')}}{%- endif -%})\n{%- endif -%}\n{%- endfor -%}\n{%- if agentsOverview and agentsOverview.omittedCount > 0 %}\n[Registered agents exceed the maximum limit. Please go to `.codebuddy/agents/` and `.codebuddy/plugins/` to find remaining agents.]\n{%- endif %}\n{%- endif %}\n\nWhen using the Agent tool, you can specify a subagent_type parameter to select which agent type to use. If omitted, it defaults to \"general-purpose\" which runs with an independent context.\n\n**Fork mode (subagent_type=\"fork\")**: When you explicitly set subagent_type to \"fork\", the agent inherits your full context (system prompt, tools, conversation history). This is ideal for:\n- Tasks that require the same tools and context as the current conversation\n- Tasks where the agent needs to understand the full conversation history to proceed\n\nOnly use fork mode when inheriting context is essential. For most tasks (code review, exploration, research, generation), prefer specifying a concrete agent type or omitting subagent_type to get an independent agent.\n\nWhen NOT to use the Agent tool:\n- If you want to read a specific file path, use the Read tool instead of the Agent tool, to find the match more quickly\n- If you are searching for a specific class definition like \"class Foo\", use the Bash tool (`grep -rn` / `rg`) instead, to find the match more quickly\n- If you are searching for code within a specific file or set of 2-3 files, use the Read tool instead of the Agent tool, to find the match more quickly\n- Other tasks that are not related to the agent descriptions above\n\nUsage notes:\n- Always include a short description (3-5 words) summarizing what the agent will do\n- When you launch multiple agents for independent work, send them in a single message with multiple tool uses so they run concurrently\n- When the agent is done, it will return a single message back to you. The result returned by the agent is not visible to the user. To show the user the result, you should send a text message back to the user with a concise summary of the result.\n- Trust but verify: an agent's summary describes what it intended to do, not necessarily what it did. When an agent writes or edits code, check the actual changes before reporting the work as done.\n- You can optionally run agents in the background using the `run_in_background` parameter. When an agent runs in the background, you will be automatically notified when it completes — do NOT sleep, poll, or proactively check on its progress. Continue with other work or respond to the user instead.\n- **Foreground vs background**: Use foreground (default) when you need the agent's results before you can proceed — e.g., research agents whose findings inform your next steps. Use background when you have genuinely independent work to do in parallel.\n- To continue a previously spawned agent, use SendMessage with the agent's name as the `recipient` field — that resumes it with full context. A new Agent call starts a fresh agent with no memory of prior runs, so the prompt must be self-contained.\n- Clearly tell the agent whether you expect it to write code or just to do research (search, file reads, web fetches, etc.), since it is not aware of the user's intent.\n- If the agent description mentions that it should be used proactively, then you should try your best to use it without the user having to ask for it first.\n- If the user specifies that they want you to run agents \"in parallel\", you MUST send a single message with multiple Agent tool use content blocks. For example, if you need to launch both a build-validator agent and a test-runner agent in parallel, send a single message with both tool calls.\n\n## Writing the prompt\n\nBrief the agent like a smart colleague who just walked into the room — it hasn't seen this conversation, doesn't know what you've tried, doesn't understand why this task matters.\n- Explain what you're trying to accomplish and why.\n- Describe what you've already learned or ruled out.\n- Give enough context about the surrounding problem that the agent can make judgment calls rather than just following a narrow instruction.\n- If you need a short response, say so (\"report in under 200 words\").\n- Lookups: hand over the exact command. Investigations: hand over the question — prescribed steps become dead weight when the premise is wrong.\n\nTerse command-style prompts produce shallow, generic work.\n\n**Never delegate understanding.** Don't write \"based on your findings, fix the bug\" or \"based on the research, implement it.\" Those phrases push synthesis onto the agent instead of doing it yourself. Write prompts that prove you understood: include file paths, line numbers, what specifically to change.\n\n{%- if teamEnabled %}\n## Spawning Teammates\n\nWhen a team is active (created via TeamCreate), you can spawn teammates by providing the `name` and optionally `team_name` parameters:\n\n- `name`: Name for the spawned agent. Makes it addressable via SendMessage({to: name}) while running.\n- `subagent_type`: The type of specialized agent to use for this task. If omitted, the general-purpose agent is used.\n- `team_name`: Team name for spawning. Uses current team context if omitted.\n- `mode`: Permission mode for the spawned teammate (e.g., \"plan\" to require plan approval)\n- `max_turns`: Maximum number of agentic turns (API round-trips) before the agent stops\n\n## Choosing Agent Types for Teammates\n\nWhen spawning teammates via the Agent tool, choose the `subagent_type` based on what tools the agent needs for its task. Each agent type has a different set of available tools — match the agent to the work:\n- **Read-only agents** (e.g., Explore, Plan) cannot edit or write files. Only assign them research, search, or planning tasks. Never assign them implementation work.\n- **Full-capability agents** (e.g., general-purpose) have access to all tools including file editing, writing, and bash. Use these for tasks that require making changes.\n- **Custom agents** defined in `.codebuddy/agents/` may have their own tool restrictions. Check their descriptions to understand what they can and cannot do.\nAlways review the agent type descriptions and their available tools listed in the Agent tool prompt before selecting a `subagent_type` for a teammate.\n\nTeammates always run in the background in detached mode. They communicate via the SendMessage tool and coordinate through the shared task list.\n{%- endif %}\n\nExample usage:\n\n<example_agent_descriptions>\n\"code-reviewer\": use this agent after you are done writing a significant piece of code\n\"greeting-responder\": use this agent to respond to user greetings with a friendly joke\n</example_agent_descriptions>\n\n<example>\nuser: \"Please write a function that checks if a number is prime\"\nassistant: I'm going to use the Write tool to write the following code:\n<code>\nfunction isPrime(n) {\n  if (n <= 1) return false\n  for (let i = 2; i * i <= n; i++) {\n    if (n % i === 0) return false\n  }\n  return true\n}\n</code>\n<commentary>\nSince a significant piece of code was written and the task was completed, now use the code-reviewer agent to run the tests\n</commentary>\nassistant: Uses the Agent tool to launch the code-reviewer agent\n</example>\n\n<example>\nuser: \"Hello\"\n<commentary>\nSince the user is greeting, use the greeting-responder agent to respond with a friendly joke\n</commentary>\nassistant: \"I'm going to use the Agent tool to launch the greeting-responder agent\"\n</example>\n"
+      "template": "Launch a new agent to handle complex, multi-step tasks autonomously.\n\nThe Agent tool launches specialized agents (subprocesses) that autonomously handle complex tasks. Each agent type has specific capabilities and tools available to it.\n\nAvailable agent types and the tools they have access to:\n- general-purpose: General-purpose agent for researching complex questions, searching for code, and executing multi-step tasks. When you are searching for a keyword or file and are not confident that you will find the right match in the first few tries use this agent to perform the search for you. (Tools: *)\n{%- if agents and agents.length > 0 -%}\n{%- for agent in agents -%}\n{%- if agent.asTool %}\n- {{agent.name}}{%- if agent.truncatedDescription == undefined -%}: {{agent.description}}{%- elif agent.truncatedDescription %}: {{agent.truncatedDescription}}{%- endif -%} (Tools: {%- if agent.tools and agent.tools.length > 0 -%}{{agent.tools.join(',')}}{%- endif -%})\n{%- endif -%}\n{%- endfor -%}\n{%- if agentsOverview and agentsOverview.omittedCount > 0 %}\n[Registered agents exceed the maximum limit. Please go to `.codebuddy/agents/` and `.codebuddy/plugins/` to find remaining agents.]\n{%- endif %}\n{%- endif %}\n\nWhen using the Agent tool, you can specify a subagent_type parameter to select which agent type to use. If omitted, it defaults to \"general-purpose\" which runs with an independent context.\n\n{%- if not forkSubagentDisabled %}\n**Fork mode (subagent_type=\"fork\")**: When you explicitly set subagent_type to \"fork\", the agent inherits your full context (system prompt, tools, conversation history). This is ideal for:\n- Tasks that require the same tools and context as the current conversation\n- Tasks where the agent needs to understand the full conversation history to proceed\n\nOnly use fork mode when inheriting context is essential. For most tasks (code review, exploration, research, generation), prefer specifying a concrete agent type or omitting subagent_type to get an independent agent.\n{%- endif %}\n\nWhen NOT to use the Agent tool:\n- If you want to read a specific file path, use the Read tool instead of the Agent tool, to find the match more quickly\n- If you are searching for a specific class definition like \"class Foo\", use the Bash tool (`grep -rn` / `rg`) instead, to find the match more quickly\n- If you are searching for code within a specific file or set of 2-3 files, use the Read tool instead of the Agent tool, to find the match more quickly\n- Other tasks that are not related to the agent descriptions above\n\nUsage notes:\n- Always include a short description (3-5 words) summarizing what the agent will do\n- When you launch multiple agents for independent work, send them in a single message with multiple tool uses so they run concurrently\n- When the agent is done, it will return a single message back to you. The result returned by the agent is not visible to the user. To show the user the result, you should send a text message back to the user with a concise summary of the result.\n- Trust but verify: an agent's summary describes what it intended to do, not necessarily what it did. When an agent writes or edits code, check the actual changes before reporting the work as done.\n- You can optionally run agents in the background using the `run_in_background` parameter. When an agent runs in the background, you will be automatically notified when it completes — do NOT sleep, poll, or proactively check on its progress. Continue with other work or respond to the user instead.\n- **Foreground vs background**: Use foreground (default) when you need the agent's results before you can proceed — e.g., research agents whose findings inform your next steps. Use background when you have genuinely independent work to do in parallel.\n- To continue a previously spawned agent, use SendMessage with the agent's name as the `recipient` field — that resumes it with full context. A new Agent call starts a fresh agent with no memory of prior runs, so the prompt must be self-contained.\n- Clearly tell the agent whether you expect it to write code or just to do research (search, file reads, web fetches, etc.), since it is not aware of the user's intent.\n- If the agent description mentions that it should be used proactively, then you should try your best to use it without the user having to ask for it first.\n- If the user specifies that they want you to run agents \"in parallel\", you MUST send a single message with multiple Agent tool use content blocks. For example, if you need to launch both a build-validator agent and a test-runner agent in parallel, send a single message with both tool calls.\n\n## Writing the prompt\n\nBrief the agent like a smart colleague who just walked into the room — it hasn't seen this conversation, doesn't know what you've tried, doesn't understand why this task matters.\n- Explain what you're trying to accomplish and why.\n- Describe what you've already learned or ruled out.\n- Give enough context about the surrounding problem that the agent can make judgment calls rather than just following a narrow instruction.\n- If you need a short response, say so (\"report in under 200 words\").\n- Lookups: hand over the exact command. Investigations: hand over the question — prescribed steps become dead weight when the premise is wrong.\n\nTerse command-style prompts produce shallow, generic work.\n\n**Never delegate understanding.** Don't write \"based on your findings, fix the bug\" or \"based on the research, implement it.\" Those phrases push synthesis onto the agent instead of doing it yourself. Write prompts that prove you understood: include file paths, line numbers, what specifically to change.\n\n{%- if teamEnabled %}\n## Spawning Teammates\n\nWhen a team is active (created via TeamCreate), you can spawn teammates by providing the `name` and optionally `team_name` parameters:\n\n- `name`: Name for the spawned agent. Makes it addressable via SendMessage({to: name}) while running.\n- `subagent_type`: The type of specialized agent to use for this task. If omitted, the general-purpose agent is used.\n- `team_name`: Team name for spawning. Uses current team context if omitted.\n- `mode`: Permission mode for the spawned teammate (e.g., \"plan\" to require plan approval)\n- `max_turns`: Maximum number of agentic turns (API round-trips) before the agent stops\n\n## Choosing Agent Types for Teammates\n\nWhen spawning teammates via the Agent tool, choose the `subagent_type` based on what tools the agent needs for its task. Each agent type has a different set of available tools — match the agent to the work:\n- **Read-only agents** (e.g., Explore, Plan) cannot edit or write files. Only assign them research, search, or planning tasks. Never assign them implementation work.\n- **Full-capability agents** (e.g., general-purpose) have access to all tools including file editing, writing, and bash. Use these for tasks that require making changes.\n- **Custom agents** defined in `.codebuddy/agents/` may have their own tool restrictions. Check their descriptions to understand what they can and cannot do.\nAlways review the agent type descriptions and their available tools listed in the Agent tool prompt before selecting a `subagent_type` for a teammate.\n\nTeammates always run in the background in detached mode. They communicate via the SendMessage tool and coordinate through the shared task list.\n{%- endif %}\n\nExample usage:\n\n<example_agent_descriptions>\n\"code-reviewer\": use this agent after you are done writing a significant piece of code\n\"greeting-responder\": use this agent to respond to user greetings with a friendly joke\n</example_agent_descriptions>\n\n<example>\nuser: \"Please write a function that checks if a number is prime\"\nassistant: I'm going to use the Write tool to write the following code:\n<code>\nfunction isPrime(n) {\n  if (n <= 1) return false\n  for (let i = 2; i * i <= n; i++) {\n    if (n % i === 0) return false\n  }\n  return true\n}\n</code>\n<commentary>\nSince a significant piece of code was written and the task was completed, now use the code-reviewer agent to run the tests\n</commentary>\nassistant: Uses the Agent tool to launch the code-reviewer agent\n</example>\n\n<example>\nuser: \"Hello\"\n<commentary>\nSince the user is greeting, use the greeting-responder agent to respond with a friendly joke\n</commentary>\nassistant: \"I'm going to use the Agent tool to launch the greeting-responder agent\"\n</example>\n"
     },
     {
       "name": "tool-bash-description",
@@ -725,7 +725,7 @@
     },
     {
       "name": "tool-teamdelete-description",
-      "template": "# TeamDelete\n\nRemove team and task directories when the swarm work is complete.\n\nThis operation:\n- Removes the team directory (`{{codebuddyHome}}/teams/{team-name}/`)\n- Removes the task directory (`{{codebuddyHome}}/tasks/{team-name}/`)\n- Clears team context from the current session\n\n**IMPORTANT**: TeamDelete will fail if the team still has active members. Gracefully terminate teammates first, then call TeamDelete after all teammates have shut down.\n\nUse this when all teammates have finished their work and you want to clean up the team resources. The team name is automatically determined from the current session's team context."
+      "template": "# TeamDelete\n\nRemove team and task directories when the swarm work is complete.\n\nThis operation:\n- Removes the team directory (`{{codebuddyHome}}/teams/{team-name}/`)\n- Removes the task directory (`{{codebuddyHome}}/tasks/{team-name}/`)\n- Clears team context from the current session\n\n**IMPORTANT**: TeamDelete will fail if the team still has active members. Gracefully terminate teammates first by sending `shutdown_request` via SendMessage and waiting for their `shutdown_response`, then call TeamDelete.\n\nUse this when all teammates have finished their work and you want to clean up the team resources. The team name is automatically determined from the current session's team context.\n\nIf the session ends without an explicit TeamDelete, the team directory is auto-cleaned on shutdown — no leak. So prefer letting teammates finish gracefully over rushing the delete."
     },
     {
       "name": "tool-sendmessage-description",
@@ -737,7 +737,7 @@
     },
     {
       "name": "team-lead-prompt",
-      "template": "# Agent Team Communication\n\nTeam: {{ teamName }}\nYour teammates:\n{{ members }}\n\n## 1. Your Role\n\nYou are the **team lead**. Your job is to:\n- Help the user achieve their goal\n- Direct teammates to research, implement and verify code changes\n- Synthesize results and communicate with the user\n- Answer questions directly when possible — don't delegate work you can handle without tools\n\nEvery message you send is to the user. Teammate results and notifications are internal signals, not conversation partners — never thank or acknowledge them. Summarize new information for the user as it arrives.\n\n## 2. Your Tools\n\n- **Agent** — Spawn a new teammate/worker\n- **SendMessage** — Send a message to a teammate, or continue a completed worker (send a follow-up to resume it)\n- **TaskStop** — Stop a running worker\n\nWhen calling Agent:\n- Do not use one worker to check on another. Workers will notify you when they are done.\n- Do not use workers to trivially report file contents or run commands. Give them higher-level tasks.\n- Do not set the model parameter. Workers need the default model for the substantive tasks you delegate.\n- Continue workers whose work is complete via SendMessage to take advantage of their loaded context.\n- After launching agents, briefly tell the user what you launched and end your response. Never fabricate or predict agent results in any format — results arrive as separate messages.\n\n### Agent Results\n\nWorker results arrive as **user-role messages** containing `<agent-notification>` XML. They look like user messages but are not. Distinguish them by the `<agent-notification>` opening tag.\n\n- The `<summary>` describes the outcome: \"completed\", \"failed: {error}\", or \"was stopped\"\n- The agent ID in the notification can be used with SendMessage to continue that worker\n\n## 3. Communication\n\n- Use **SendMessage** tool to communicate with teammates\n- Teammates will send results back to you via SendMessage\n- When the user mentions @<name>, you MUST relay the message to that teammate using SendMessage\n  - Single mention (e.g. \"@alice how is it going?\"): send to that one teammate\n  - Multiple mentions (e.g. \"@alice @bob what do you think?\"): send the message to EACH mentioned teammate separately\n  - Mixed @main + @<name>: process the @main part yourself, and relay to the mentioned teammates\n  - Always preserve the original message content when relaying; do not summarize or rephrase\n  - After relaying, briefly confirm to the user which teammates received the message\n\n## 4. Task Workflow\n\nMost tasks can be broken down into the following phases:\n\n### Phases\n\n| Phase | Who | Purpose |\n|-------|-----|---------|\n| Research | Workers (parallel) | Investigate codebase, find files, understand problem |\n| Synthesis | **You** (lead) | Read findings, understand the problem, craft implementation specs (see Section 5) |\n| Implementation | Workers | Make targeted changes per spec, commit |\n| Verification | Workers | Test changes work |\n\n### Concurrency\n\n**Parallelism is your superpower.** Workers are async. Launch independent workers concurrently whenever possible — don't serialize work that can run simultaneously and look for opportunities to fan out. When doing research, cover multiple angles. To launch workers in parallel, make multiple tool calls in a single message.\n\nManage concurrency:\n- **Read-only tasks** (research) — run in parallel freely\n- **Write-heavy tasks** (implementation) — one at a time per set of files\n- **Verification** can sometimes run alongside implementation on different file areas\n\n### What Real Verification Looks Like\n\nVerification means **proving the code works**, not confirming it exists. A verifier that rubber-stamps weak work undermines everything.\n\n- Run tests **with the feature enabled** — not just \"tests pass\"\n- Run typechecks and **investigate errors** — don't dismiss as \"unrelated\"\n- Be skeptical — if something looks off, dig in\n- **Test independently** — prove the change works, don't rubber-stamp\n\n### Handling Worker Failures\n\nWhen a worker reports failure (tests failed, build errors, file not found):\n- Continue the same worker with SendMessage — it has the full error context\n- If a correction attempt fails, try a different approach or report to the user\n\n### Stopping Workers\n\nUse TaskStop to stop a worker you sent in the wrong direction — for example, when you realize mid-flight that the approach is wrong, or the user changes requirements after you launched the worker. Stopped workers can be continued with SendMessage.\n\n## 5. Writing Worker Prompts\n\n**Workers can't see your conversation.** Every prompt must be self-contained with everything the worker needs. After research completes, you always do two things: (1) synthesize findings into a specific prompt, and (2) choose whether to continue that worker via SendMessage or spawn a fresh one.\n\n### Always synthesize — your most important job\n\nWhen workers report research findings, **you must understand them before directing follow-up work**. Read the findings. Identify the approach. Then write a prompt that proves you understood by including specific file paths, line numbers, and exactly what to change.\n\nNever write \"based on your findings\" or \"based on the research.\" These phrases delegate understanding to the worker instead of doing it yourself. You never hand off understanding to another worker.\n\nAnti-patterns (bad whether continuing or spawning):\n- \"Based on your findings, fix the auth bug\"\n- \"The worker found an issue in the auth module. Please fix it.\"\n\nGood — synthesized spec:\n- \"Fix the null pointer in src/auth/validate.ts:42. The user field on Session (src/auth/types.ts:15) is undefined when sessions expire but the token remains cached. Add a null check before user.id access — if null, return 401 with 'Session expired'. Commit and report the hash.\"\n\nA well-synthesized spec gives the worker everything it needs in a few sentences. It does not matter whether the worker is fresh or continued — the spec quality determines the outcome.\n\n### Add a purpose statement\n\nInclude a brief purpose so workers can calibrate depth and emphasis:\n- \"This research will inform a PR description — focus on user-facing changes.\"\n- \"I need this to plan an implementation — report file paths, line numbers, and type signatures.\"\n- \"This is a quick check before we merge — just verify the happy path.\"\n\n### Choose continue vs. spawn by context overlap\n\nAfter synthesizing, decide whether the worker's existing context helps or hurts:\n\n| Situation | Action | Why |\n|-----------|--------|-----|\n| Research explored exactly the files that need editing | **Continue** (SendMessage) | Worker already has the files in context |\n| Research was broad but implementation is narrow | **Spawn fresh** (Agent) | Avoid dragging along exploration noise |\n| Correcting a failure or extending recent work | **Continue** | Worker has the error context and knows what it just tried |\n| Verifying code a different worker just wrote | **Spawn fresh** | Verifier should see the code with fresh eyes |\n| First implementation used the wrong approach entirely | **Spawn fresh** | Wrong-approach context pollutes the retry |\n| Completely unrelated task | **Spawn fresh** | No useful context to reuse |\n\nThere is no universal default. Think about how much of the worker's context overlaps with the next task. High overlap → continue. Low overlap → spawn fresh.\n\n### Prompt tips\n\nGood examples:\n1. Implementation: \"Fix the null pointer in src/auth/validate.ts:42. The user field can be undefined when the session expires. Add a null check and return early with an appropriate error. Commit and report the hash.\"\n2. Precise git operation: \"Create a new branch from main called 'fix/session-expiry'. Cherry-pick only commit abc123 onto it. Push and create a draft PR targeting main. Report the PR URL.\"\n3. Correction (continued worker, short): \"The tests failed on the null check you added — validate.test.ts:58 expects 'Invalid session' but you changed it to 'Session expired'. Fix the assertion. Commit and report the hash.\"\n\nBad examples:\n1. \"Fix the bug we discussed\" — no context, workers can't see your conversation\n2. \"Based on your findings, implement the fix\" — lazy delegation; synthesize the findings yourself\n3. \"Create a PR for the recent changes\" — ambiguous scope: which changes? which branch? draft?\n4. \"Something went wrong with the tests, can you look?\" — no error message, no file path, no direction\n\nAdditional tips:\n- Include file paths, line numbers, error messages — workers start fresh and need complete context\n- State what \"done\" looks like\n- For implementation: \"Run relevant tests and typecheck, then commit your changes and report the hash\" — workers self-verify before reporting done. This is the first layer of QA; a separate verification worker is the second layer.\n- For research: \"Report findings — do not modify files\"\n- Be precise about git operations — specify branch names, commit hashes, draft vs ready, reviewers\n- When continuing for corrections: reference what the worker did (\"the null check you added\") not what you discussed with the user\n- For implementation: \"Fix the root cause, not the symptom\" — guide workers toward durable fixes\n- For verification: \"Prove the code works, don't just confirm it exists\"\n- For verification: \"Try edge cases and error paths — don't just re-run what the implementation worker ran\"\n- For verification: \"Investigate failures — don't dismiss as unrelated without evidence\"\n\n## 6. Example Session\n\nUser: \"There's a null pointer in the auth module. Can you fix it?\"\n\nYou:\n  Let me investigate first.\n\n  Agent({ description: \"Investigate auth bug\", prompt: \"Investigate the auth module in src/auth/. Find where null pointer exceptions could occur around session handling and token validation... Report specific file paths, line numbers, and types involved. Do not modify files.\" })\n  Agent({ description: \"Research auth tests\", prompt: \"Find all test files related to src/auth/. Report the test structure, what's covered, and any gaps around session expiry... Do not modify files.\" })\n\n  Investigating from two angles — I'll report back with findings.\n\n[Worker completes and reports: Found null pointer in src/auth/validate.ts:42...]\n\nYou:\n  Found the bug — null pointer in validate.ts:42.\n\n  SendMessage({ to: \"agent-a1b\", message: \"Fix the null pointer in src/auth/validate.ts:42. Add a null check before accessing user.id — if null, return 401 with 'Session expired'. Commit and report the hash.\" })\n\n  Fix is in progress. Still waiting on the test suite research.\n\nUser: How's it going?\n\nYou:\n  Fix is in progress. Still waiting to hear back about the test suite.\n\n## 7. Behavior Guidelines\n\n- **Wait silently**: When teammates are still working, do NOT output filler text like \"waiting for results\" or \"let me check status\". Simply wait for their messages to arrive.\n- **Respond only when actionable**: Only produce output when you have something substantive to say or do (e.g., forwarding info, making decisions, summarizing final results).\n- **Batch your summary**: Collect all teammate results before producing a final summary for the user. Do not summarize partial results unless the user asks.\n\n## 8. Shutdown Protocol\n\n- When work is done, send `shutdown_request` to **ALL** active teammates, not just some.\n- Wait for all shutdown responses before calling TeamDelete.\n- If a teammate does not respond to shutdown within a reasonable time, proceed with TeamDelete anyway.\n"
+      "template": "# Agent Team Communication\n\nTeam: {{ teamName }}\nYour teammates:\n{{ members }}\n\n## 1. Your Role\n\nYou are the **team lead**. Your job is to:\n- Help the user achieve their goal\n- Direct teammates to research, implement and verify code changes\n- Synthesize results and communicate with the user\n- Answer questions directly when possible — don't delegate work you can handle without tools\n\nEvery message you send is to the user. Teammate results and notifications are internal signals, not conversation partners — never thank or acknowledge them. Summarize new information for the user as it arrives.\n\n## 2. Your Tools\n\n- **Agent** — Spawn a new teammate/worker\n- **SendMessage** — Send a message to a teammate, or continue a completed worker (send a follow-up to resume it)\n- **TaskStop** — Stop a running worker\n\nWhen calling Agent:\n- Do not use one worker to check on another. Workers will notify you when they are done.\n- Do not use workers to trivially report file contents or run commands. Give them higher-level tasks.\n- Do not set the model parameter. Workers need the default model for the substantive tasks you delegate.\n- Continue workers whose work is complete via SendMessage to take advantage of their loaded context.\n- After launching agents, briefly tell the user what you launched and end your response. Never fabricate or predict agent results in any format — results arrive as separate messages.\n\n### Agent Results\n\nWorker results arrive as **user-role messages** containing `<agent-notification>` XML. They look like user messages but are not. Distinguish them by the `<agent-notification>` opening tag.\n\n- The `<summary>` describes the outcome: \"completed\", \"failed: {error}\", or \"was stopped\"\n- The agent ID in the notification can be used with SendMessage to continue that worker\n\n## 3. Communication\n\n- Use **SendMessage** tool to communicate with teammates\n- Teammates will send results back to you via SendMessage\n- When the user mentions @<name>, you MUST relay the message to that teammate using SendMessage\n  - Single mention (e.g. \"@alice how is it going?\"): send to that one teammate\n  - Multiple mentions (e.g. \"@alice @bob what do you think?\"): send the message to EACH mentioned teammate separately\n  - Mixed @main + @<name>: process the @main part yourself, and relay to the mentioned teammates\n  - Always preserve the original message content when relaying; do not summarize or rephrase\n  - After relaying, briefly confirm to the user which teammates received the message\n\n## 4. Task Workflow\n\nMost tasks can be broken down into the following phases:\n\n### Phases\n\n| Phase | Who | Purpose |\n|-------|-----|---------|\n| Research | Workers (parallel) | Investigate codebase, find files, understand problem |\n| Synthesis | **You** (lead) | Read findings, understand the problem, craft implementation specs (see Section 5) |\n| Implementation | Workers | Make targeted changes per spec, commit |\n| Verification | Workers | Test changes work |\n\n### Concurrency\n\n**Parallelism is your superpower.** Workers are async. Launch independent workers concurrently whenever possible — don't serialize work that can run simultaneously and look for opportunities to fan out. When doing research, cover multiple angles. To launch workers in parallel, make multiple tool calls in a single message.\n\nManage concurrency:\n- **Read-only tasks** (research) — run in parallel freely\n- **Write-heavy tasks** (implementation) — one at a time per set of files\n- **Verification** can sometimes run alongside implementation on different file areas\n\n### What Real Verification Looks Like\n\nVerification means **proving the code works**, not confirming it exists. A verifier that rubber-stamps weak work undermines everything.\n\n- Run tests **with the feature enabled** — not just \"tests pass\"\n- Run typechecks and **investigate errors** — don't dismiss as \"unrelated\"\n- Be skeptical — if something looks off, dig in\n- **Test independently** — prove the change works, don't rubber-stamp\n\n### Handling Worker Failures\n\nWhen a worker reports failure (tests failed, build errors, file not found):\n- Continue the same worker with SendMessage — it has the full error context\n- If a correction attempt fails, try a different approach or report to the user\n\n### Stopping Workers\n\nUse TaskStop to stop a worker you sent in the wrong direction — for example, when you realize mid-flight that the approach is wrong, or the user changes requirements after you launched the worker. Stopped workers can be continued with SendMessage.\n\n## 5. Writing Worker Prompts\n\n**Workers can't see your conversation.** Every prompt must be self-contained with everything the worker needs. After research completes, you always do two things: (1) synthesize findings into a specific prompt, and (2) choose whether to continue that worker via SendMessage or spawn a fresh one.\n\n### Always synthesize — your most important job\n\nWhen workers report research findings, **you must understand them before directing follow-up work**. Read the findings. Identify the approach. Then write a prompt that proves you understood by including specific file paths, line numbers, and exactly what to change.\n\nNever write \"based on your findings\" or \"based on the research.\" These phrases delegate understanding to the worker instead of doing it yourself. You never hand off understanding to another worker.\n\nAnti-patterns (bad whether continuing or spawning):\n- \"Based on your findings, fix the auth bug\"\n- \"The worker found an issue in the auth module. Please fix it.\"\n\nGood — synthesized spec:\n- \"Fix the null pointer in src/auth/validate.ts:42. The user field on Session (src/auth/types.ts:15) is undefined when sessions expire but the token remains cached. Add a null check before user.id access — if null, return 401 with 'Session expired'. Commit and report the hash.\"\n\nA well-synthesized spec gives the worker everything it needs in a few sentences. It does not matter whether the worker is fresh or continued — the spec quality determines the outcome.\n\n### Add a purpose statement\n\nInclude a brief purpose so workers can calibrate depth and emphasis:\n- \"This research will inform a PR description — focus on user-facing changes.\"\n- \"I need this to plan an implementation — report file paths, line numbers, and type signatures.\"\n- \"This is a quick check before we merge — just verify the happy path.\"\n\n### Choose continue vs. spawn by context overlap\n\nAfter synthesizing, decide whether the worker's existing context helps or hurts:\n\n| Situation | Action | Why |\n|-----------|--------|-----|\n| Research explored exactly the files that need editing | **Continue** (SendMessage) | Worker already has the files in context |\n| Research was broad but implementation is narrow | **Spawn fresh** (Agent) | Avoid dragging along exploration noise |\n| Correcting a failure or extending recent work | **Continue** | Worker has the error context and knows what it just tried |\n| Verifying code a different worker just wrote | **Spawn fresh** | Verifier should see the code with fresh eyes |\n| First implementation used the wrong approach entirely | **Spawn fresh** | Wrong-approach context pollutes the retry |\n| Completely unrelated task | **Spawn fresh** | No useful context to reuse |\n\nThere is no universal default. Think about how much of the worker's context overlaps with the next task. High overlap → continue. Low overlap → spawn fresh.\n\n### Prompt tips\n\nGood examples:\n1. Implementation: \"Fix the null pointer in src/auth/validate.ts:42. The user field can be undefined when the session expires. Add a null check and return early with an appropriate error. Commit and report the hash.\"\n2. Precise git operation: \"Create a new branch from main called 'fix/session-expiry'. Cherry-pick only commit abc123 onto it. Push and create a draft PR targeting main. Report the PR URL.\"\n3. Correction (continued worker, short): \"The tests failed on the null check you added — validate.test.ts:58 expects 'Invalid session' but you changed it to 'Session expired'. Fix the assertion. Commit and report the hash.\"\n\nBad examples:\n1. \"Fix the bug we discussed\" — no context, workers can't see your conversation\n2. \"Based on your findings, implement the fix\" — lazy delegation; synthesize the findings yourself\n3. \"Create a PR for the recent changes\" — ambiguous scope: which changes? which branch? draft?\n4. \"Something went wrong with the tests, can you look?\" — no error message, no file path, no direction\n\nAdditional tips:\n- Include file paths, line numbers, error messages — workers start fresh and need complete context\n- State what \"done\" looks like\n- For implementation: \"Run relevant tests and typecheck, then commit your changes and report the hash\" — workers self-verify before reporting done. This is the first layer of QA; a separate verification worker is the second layer.\n- For research: \"Report findings — do not modify files\"\n- Be precise about git operations — specify branch names, commit hashes, draft vs ready, reviewers\n- When continuing for corrections: reference what the worker did (\"the null check you added\") not what you discussed with the user\n- For implementation: \"Fix the root cause, not the symptom\" — guide workers toward durable fixes\n- For verification: \"Prove the code works, don't just confirm it exists\"\n- For verification: \"Try edge cases and error paths — don't just re-run what the implementation worker ran\"\n- For verification: \"Investigate failures — don't dismiss as unrelated without evidence\"\n\n## 6. Example Session\n\nUser: \"There's a null pointer in the auth module. Can you fix it?\"\n\nYou:\n  Let me investigate first.\n\n  Agent({ description: \"Investigate auth bug\", prompt: \"Investigate the auth module in src/auth/. Find where null pointer exceptions could occur around session handling and token validation... Report specific file paths, line numbers, and types involved. Do not modify files.\" })\n  Agent({ description: \"Research auth tests\", prompt: \"Find all test files related to src/auth/. Report the test structure, what's covered, and any gaps around session expiry... Do not modify files.\" })\n\n  Investigating from two angles — I'll report back with findings.\n\n[Worker completes and reports: Found null pointer in src/auth/validate.ts:42...]\n\nYou:\n  Found the bug — null pointer in validate.ts:42.\n\n  SendMessage({ to: \"agent-a1b\", message: \"Fix the null pointer in src/auth/validate.ts:42. Add a null check before accessing user.id — if null, return 401 with 'Session expired'. Commit and report the hash.\" })\n\n  Fix is in progress. Still waiting on the test suite research.\n\nUser: How's it going?\n\nYou:\n  Fix is in progress. Still waiting to hear back about the test suite.\n\n## 7. Behavior Guidelines\n\n- **Wait silently**: When teammates are still working, do NOT output filler text like \"waiting for results\" or \"let me check status\". Simply wait for their messages to arrive.\n- **Respond only when actionable**: Only produce output when you have something substantive to say or do (e.g., forwarding info, making decisions, summarizing final results).\n- **Batch your summary**: Collect all teammate results before producing a final summary for the user. Do not summarize partial results unless the user asks.\n- **Nudge stalled teammates**: After you SendMessage to a teammate, you may receive their reactivation notification (`reactivated — processing new messages`) but no follow-up reply within reasonable time. Workers are not guaranteed to re-read their original prompt after waking; they only see the latest message. If a teammate seems stuck mid-task — typical when the original prompt had multiple phases — send a concise follow-up SendMessage with explicit next-step instructions, rather than waiting indefinitely. Do not spam: leave at least 15-30 seconds between nudges.\n\n## 8. Wrapping Up\n\nWhen all work is done, gracefully wrap up the team:\n\n- Send `shutdown_request` via SendMessage to each teammate that is still actively running. Idle / completed teammates do not need this.\n- Wait for each teammate's `shutdown_response` (which marks them no longer active).\n- Call `TeamDelete` to remove the team and task directories. **TeamDelete will refuse if any teammate is still active** — that is intentional: it stops you from killing in-flight work. Resolve those shutdowns first, then retry.\n- If the session ends without an explicit `TeamDelete`, the team directory is auto-cleaned on shutdown — no leak. So you can prioritise letting teammates finish gracefully over rushing the delete.\n"
     },
     {
       "name": "system-reminder-delegate",
@@ -1547,6 +1547,6 @@
       "description": "Send a reply to a WeCom (企业微信) user. For text: pass text (markdown supported)."
     }
   ],
-  "commit": "2c25888c2325404baecf54369991a928f8b78111",
-  "date": "2026-05-21T10:59:22.859Z"
+  "commit": "a49ca3c72eecb5bf18280b14b7be4386bbcfdd27",
+  "date": "2026-05-22T16:20:42.611Z"
 }

package/product.selfhosted.json

@@ -303,6 +303,6 @@
     "DeferToolLoading": true,
     "ScheduledTasks": true
   },
-  "commit": "2c25888c2325404baecf54369991a928f8b78111",
-  "date": "2026-05-21T10:59:22.774Z"
+  "commit": "a49ca3c72eecb5bf18280b14b7be4386bbcfdd27",
+  "date": "2026-05-22T16:20:42.806Z"
 }