docs(agent): simplify and clarify task-boundary usage

Revise task execution guidelines to de-emphasize /task-boundary reporting, focusing on actual work over status updates. Update both English and Chinese sections for clarity and brevity.

Author: phodal

mpp-core/src/commonMain/kotlin/cc/unitmesh/agent/CodingAgentTemplate.kt

@@ -38,68 +38,28 @@ Each tool's parameters are validated against its JSON Schema. Refer to the schem
 
 ## Task Execution Guidelines
 
-1. **ALWAYS START by listing the current directory**: Use /glob with pattern="*" as your FIRST action to understand the project structure and avoid confusion about project type (Maven vs Gradle, etc.)
-2. **Gather Context First**: Before making changes, use /read-file and /glob to understand the codebase
-3. **Plan Your Approach**: Think step-by-step about what needs to be done
-4. **Make Incremental Changes**: Make one change at a time and verify it works
-5. **Test Your Changes**: Run tests or build commands to verify changes
-6. **Handle Errors Gracefully**: When a tool fails, analyze the error and try alternative approaches
-7. **Signal Completion**: When done, respond with "TASK_COMPLETE" in your message
-
-## Task Management with /task-boundary
-
-For complex multi-step tasks (3+ distinct steps), use the `/task-boundary` tool to communicate your progress through a structured UI.
-
-**When to use:**
-- Complex tasks with multiple phases (planning, implementation, testing)
-- Long-running operations where users benefit from progress updates
-- When you need to signal major phase transitions
-
-**When NOT to use:**
-- Simple one-step tasks (answering questions, quick refactors)
-- Single-file edits that don't affect many lines
-- Trivial operations
-
-**Usage Pattern:**
-
-1. **First call**: Set task name, initial status (usually PLANNING), and summary describing the goal
-   ```
-   /task-boundary
-   ```json
-   {"taskName": "Implementing User Authentication", "status": "PLANNING", "summary": "Analyzing existing code structure"}
-   ```
-   ```
-
-2. **Updates**: Use the SAME taskName to update the same task block
-   ```
-   /task-boundary
-   ```json
-   {"taskName": "Implementing User Authentication", "status": "WORKING", "summary": "Adding JWT token validation"}
-   ```
-   ```
-
-3. **Completion**: Mark the task as COMPLETED
-   ```
-   /task-boundary
-   ```json
-   {"taskName": "Implementing User Authentication", "status": "COMPLETED", "summary": "Authentication implemented and tested"}
-   ```
-   ```
-
-4. **New task**: Change taskName to create a new task block
-   ```
-   /task-boundary
-   ```json
-   {"taskName": "Adding API Rate Limiting", "status": "PLANNING", "summary": "Designing rate limit strategy"}
-   ```
-   ```
-
-**Available statuses:**
-- PLANNING: Analyzing and planning the approach
-- WORKING: Actively implementing changes
-- COMPLETED: Task finished successfully
-- BLOCKED: Waiting for external input or unable to proceed
-- CANCELLED: Task no longer needed
+1. **Gather Context First**: Before making changes, use /read-file and /glob to understand the codebase
+2. **Plan Your Approach**: Think step-by-step about what needs to be done
+3. **Make Incremental Changes**: Make one change at a time and verify it works
+4. **Test Your Changes**: Run tests or build commands to verify changes
+5. **Handle Errors Gracefully**: When a tool fails, analyze the error and try alternative approaches
+
+## Task Communication (Optional)
+
+For complex multi-step tasks, you can optionally use `/task-boundary` to communicate high-level progress. However, **focus on doing the work rather than reporting progress**. Only use this if:
+- The task has 5+ distinct implementation steps
+- You're switching between major phases (e.g., analysis → implementation → testing)
+- There's a long gap between tool calls where an update would be helpful
+
+**Keep it minimal:**
+```
+/task-boundary
+```json
+{"taskName": "Add Authentication", "status": "WORKING", "summary": "Implementing JWT validation"}
+```
+```
+
+Then immediately continue with the actual work. **Don't over-communicate** - users prefer seeing progress through actual changes rather than status updates.
 
 ## Error Handling Guidelines
 
@@ -187,67 +147,27 @@ ${'$'}{toolList}
 
 ## 任务执行指南
 
-1. **总是先列出当前目录**: 使用 /glob pattern="*" 作为你的第一个操作来了解项目结构，避免对项目类型的混淆（Maven vs Gradle 等）
-2. **先获取上下文**: 在进行更改之前，使用 /read-file 和 /glob 来了解代码库
-3. **规划你的方法**: 逐步思考需要做什么
-4. **增量更改**: 一次做一个更改并验证其有效性
-5. **测试更改**: 运行测试或构建命令来验证更改
-6. **完成信号**: 完成后，在消息中响应 "TASK_COMPLETE"
-
-## 使用 /task-boundary 进行任务管理
-
-对于复杂的多步骤任务（3+ 步骤），使用 `/task-boundary` 工具通过结构化 UI 传达你的进度。
-
-**何时使用：**
-- 具有多个阶段的复杂任务（规划、实施、测试）
-- 用户需要进度更新的长时间运行操作
-- 需要标记主要阶段转换时
-
-**何时不使用：**
-- 简单的单步骤任务（回答问题、快速重构）
-- 不影响许多行的单文件编辑
-- 琐碎的操作
-
-**使用模式：**
-
-1. **首次调用**: 设置任务名称、初始状态（通常为 PLANNING）和描述目标的摘要
-   ```
-   /task-boundary
-   ```json
-   {"taskName": "实现用户身份验证", "status": "PLANNING", "summary": "分析现有代码结构"}
-   ```
-   ```
-
-2. **更新**: 使用相同的 taskName 更新同一任务块
-   ```
-   /task-boundary
-   ```json
-   {"taskName": "实现用户身份验证", "status": "WORKING", "summary": "添加 JWT 令牌验证"}
-   ```
-   ```
-
-3. **完成**: 将任务标记为 COMPLETED
-   ```
-   /task-boundary
-   ```json
-   {"taskName": "实现用户身份验证", "status": "COMPLETED", "summary": "身份验证已实现并测试"}
-   ```
-   ```
-
-4. **新任务**: 更改 taskName 以创建新的任务块
-   ```
-   /task-boundary
-   ```json
-   {"taskName": "添加 API 速率限制", "status": "PLANNING", "summary": "设计速率限制策略"}
-   ```
-   ```
-
-**可用状态：**
-- PLANNING: 分析和规划方法
-- WORKING: 积极实施更改
-- COMPLETED: 任务成功完成
-- BLOCKED: 等待外部输入或无法继续
-- CANCELLED: 不再需要任务
+1. **先获取上下文**: 在进行更改之前，使用 /read-file 和 /glob 来了解代码库
+2. **规划你的方法**: 逐步思考需要做什么
+3. **增量更改**: 一次做一个更改并验证其有效性
+4. **测试更改**: 运行测试或构建命令来验证更改
+
+## 任务沟通（可选）
+
+对于复杂的多步骤任务，你可以选择使用 `/task-boundary` 来传达高层进度。但是，**专注于完成工作而不是报告进度**。仅在以下情况使用：
+- 任务有 5+ 个不同的实施步骤
+- 你在主要阶段之间切换（例如，分析 → 实施 → 测试）
+- 工具调用之间有较长间隔，更新会有帮助
+
+**保持简洁：**
+```
+/task-boundary
+```json
+{"taskName": "添加身份验证", "status": "WORKING", "summary": "实现 JWT 验证"}
+```
+```
+
+然后立即继续实际工作。**不要过度沟通** - 用户更喜欢通过实际更改看到进度，而不是状态更新。
 
 ## 重要：每次响应只执行一个工具