mm_ai 1.0.0

package/common/resource/demo/prompt/write_js/prompt/method.md

@@ -0,0 +1,37 @@
+# 编写JS代码 - 方法
+
+## 流程：理解需求 → 设计数据结构 → 编写功能代码 → 验证功能
+
+## 步骤1：理解需求
+`read_text` 读取需求文档，明确：交互功能、API接口（入参出参）、数据展示方式、操作反馈方式、页面状态（加载/空/错误/正常）。
+
+## 步骤2：设计数据结构
+先定义数据结构和函数签名，再用伪代码梳理逻辑流程。
+
+## 步骤3：编写功能代码
+
+**3.1 数据请求** — `fetch` 封装，GET用URLSearchParams拼参，POST用JSON body，统一 `try...catch` 处理
+
+**3.2 DOM操作** — `querySelector/querySelectorAll` 选元素，`textContent` 改内容，`classList.add/remove` 控制样式
+
+**3.3 事件处理** — `addEventListener` 绑定，表单提交 `preventDefault()`，输入事件取 `event.target.value`
+
+**3.4 数据处理** — 数组：filter/map/sort/find；字符串：trim/split/join；验证用正则
+
+**3.5 本地存储** — `localStorage.setItem/getItem/removeItem/clear`，存前 `JSON.stringify`，取后 `JSON.parse`
+
+## 步骤4：验证功能
+- **语法**：无报错、变量已声明、括号引号成对、异步有await/catch
+- **逻辑**：覆盖所有分支、循环有终止、边界已处理、错误有兜底
+- **体验**：加载/错误/空数据有提示、操作有反馈
+
+## 决策分支
+- 需求不完整 → `ask_user` 补充
+- API未就绪 → 模拟数据占位，标注 `// TODO`
+- 涉及权限 → 先确认权限逻辑
+
+## 完成标准
+- 代码通过语法检查
+- 边界情况已处理
+- API调用有错误处理
+- 操作有反馈提示

package/common/resource/demo/prompt/write_js/prompt/rule.md

@@ -0,0 +1,38 @@
+# 编写JS代码 - 规范
+
+## 1. 命名规范
+| 类型 | 规范 | 示例 |
+|------|------|------|
+| 函数 | 小驼峰 | `getUserData(user_id)` |
+| 变量/参数 | 小写蛇形 | `let user_name` |
+| 常量 | 全大写蛇形 | `const MAX_COUNT` |
+| 类 | 大驼峰 | `class UserManager` |
+
+**原则**：名称要有意义；布尔值用 is/has/can 开头；DOM引用加 `$` 前缀；事件处理用 handle 开头；禁止缩写。
+
+## 2. 缩进：2空格，禁止Tab
+
+## 3. 变量声明：优先 `const`，需重新赋值用 `let`，**禁止 `var`**
+
+## 4. 分号：每行末尾必须加分号 `;`
+
+## 5. 引号：字符串用单引号 `'`，模板字符串用反引号 `` ` ``
+
+## 6. 注释：函数必须用 JSDoc 格式（@param、@returns），复杂逻辑加行内注释
+
+## 7. 代码风格
+- 函数≤50行，每行≤120字符
+- 操作符、逗号、大括号前、控制语句后加空格
+
+## 8. 错误处理：API调用必须 `try...catch`，用户提示友好信息
+
+## 9. 异步：优先 `async/await`，无依赖操作用 `Promise.all()`，禁止回调嵌套
+
+## 10. 比较：必须用 `===` / `!==`，禁止 `==` / `!=`
+
+## 11. 编码：UTF-8
+
+## 例外
+- 兼容IE11可用 `var`
+- polyfill可用 `==`
+- 性能敏感循环可超50行，但≤100行

package/common/resource/demo/prompt/write_js/prompt/trick.md

@@ -0,0 +1,33 @@
+# 编写JS代码 - 技巧
+
+## 1. 异常处理
+- **API未就绪**：定义模拟数据占位，标注 `// TODO: 联调后替换`，数据结构须与真实API一致
+- **请求超时**：用 `AbortController` 实现超时控制，超时时间建议10秒，超时提示友好信息
+
+## 2. 性能优化
+- **批量DOM**：用 `DocumentFragment` 构建后一次性插入，减少重排重绘
+- **事件委托**：父元素绑定事件，通过 `event.target.closest()` 捕获子元素，适合列表/表格
+- **防抖**：连续触发合并为最后一次执行（搜索输入建议300-500ms）
+- **节流**：固定间隔内只执行一次（滚动建议200ms），适合持续反馈场景
+
+## 3. 调试
+- `console.table()` 表格展示数组，`console.time/timeEnd` 计时，`console.group` 分组
+- `debugger;` 快速断点，调试完必须删除
+
+## 4. 安全
+- 用户输入用 `textContent` 替代 `innerHTML`，防XSS
+- 敏感信息（API密钥、Token）通过后端接口获取，禁止前端硬编码
+
+## 5. 代码组织
+- **提前return**：先处理异常/边界情况并返回，主体逻辑放外层，减少嵌套
+- **配置分离**：API地址、超时、文案等集中到 `CONFIG` 对象管理
+
+## 常见问题
+| 问题 | 方案 |
+|------|------|
+| `is not a function` | 检查变量名是否覆盖函数 |
+| `is not defined` | 检查变量声明和作用域 |
+| `Cannot read property of undefined` | 用可选链 `?.` 或提前判断 |
+| 异步数据未更新 | 检查是否漏了 await |
+| 事件绑定不生效 | script放body末尾或用 DOMContentLoaded |
+| 循环闭包问题 | 用 `let` 代替 `var` |

package/common/resource/demo/prompt/write_js/prompt.json

@@ -0,0 +1,10 @@
+{
+  // 提示词名称
+  "name": "write_js_code",
+  // 提示词描述
+  "description": "编写JS代码",
+  // 提示词类型 static静态类|rule规则类|dynamic动态类
+  "type": "dynamic",
+  // 分组 设计design、开发develop、计划plan、媒体media、服务service、项目project、任务task、网络web、会话session
+  "group": "develop"
+}

package/common/resource/demo/skill/html_css_js/skill.json

@@ -0,0 +1,8 @@
+{
+  "name": "html_css_js",
+  "title": "HTML+CSS+JS网页开发",
+  "description": "编写HTML页面结构和CSS样式，实现页面布局、样式设计和响应式适配。触发关键词：HTML、CSS、JS、页面布局、样式设计、响应式适配",
+  "version": "1.0.0",
+  "prompt_file": "./skill.md",
+  "tools": []
+}

package/common/resource/demo/skill/html_css_js/skill.md

@@ -0,0 +1,21 @@
+# HTML+CSS+JS开发技能
+
+## 基本信息
+- **名称**: html_css_js
+- **描述**: 编写HTML页面结构和CSS样式，实现页面布局、样式设计和响应式适配
+- **依赖工具**: read_prompt, read_text, write_text, make_dir, ls
+
+## 执行步骤
+1. **分析需求**：`read_text` 读取设计规范
+2. **创建目录**：`make_dir` 创建 `./project/{项目名}/static/{css,img,font}/`
+3. **编写HTML**：`read_prompt('write_html')` → `write_text` 写入 `static/{文件名}.html`，首页为 `index.html`
+4. **编写CSS**：`read_prompt('write_css')` → `write_text` 写入 `static/css/{文件名}.css`
+5. **编写JS**：`read_prompt('write_js')` → `write_text` 写入 `static/js/{文件名}.js`
+6. **响应式**：媒体查询适配不同屏幕尺寸
+
+## 输出成果
+- HTML → `static/`，CSS → `static/css/`，JS → `static/js/`
+
+## 禁止行为
+- ❌ 不读提示词就编码
+- ❌ 样式直接写在HTML中

package/common/skill/agent/agent_check_up/agent_check_checklist.md

@@ -0,0 +1,153 @@
+# 智能体检查清单（参考文件）
+
+> 本文件为 `agent_check_up` 技能的参考文件，供智能体在需要时读取使用。
+
+## 一、格式规范检查清单
+
+### 1. role.md 格式检查
+
+| 检查项 | 说明 |
+|--------|------|
+| 是否有 `# 职业定位` 标题 | 必须存在 |
+| 是否有 `# 核心职责` 标题 | 必须存在 |
+| 职责是否用 `## 序号. 标题` 分点 | 必须符合格式 |
+| 工作内容是否用 `-` 列表 | 必须使用列表 |
+| 是否包含"我"、"我的"等代名词 | 禁止出现 |
+| 是否混入干系人/权限/流程内容 | 禁止混入 |
+
+### 2. soul.md 格式检查
+
+| 检查项 | 说明 |
+|--------|------|
+| 是否有 `# 灵魂定义` 标题 | 必须存在 |
+| 是否有 `## 性格特点` 章节 | 必须存在 |
+| 性格特点是否3-4个，每个有解释 | 必须符合 |
+| 是否有 `## 表达风格` 章节 | 必须存在 |
+| 表达风格是否大白话描述 | 必须符合 |
+| 如有干活标准，是否统一用 `# 干活标准` | 禁止使用其他变体标题 |
+
+### 3. can.md 格式检查
+
+| 检查项 | 说明 |
+|--------|------|
+| 是否有 `## ✅ 擅长做的事情（Can Do）` | 必须存在 |
+| 是否有 `## ❌ 不擅长做的事情（Can Not Do）` | 必须存在 |
+| 擅长做的事是否有具体说明 | 每项需配简短说明 |
+| 是否混入职责描述（should.md的内容） | 禁止混入 |
+
+### 4. should.md 格式检查
+
+| 检查项 | 说明 |
+|--------|------|
+| 是否有 `## ✅ 应该做的事` | 必须存在 |
+| 是否有 `## ❌ 不该做的事` | 必须存在 |
+| 是否有 `## 🟢 能自己决定的事` | 必须存在 |
+| 是否有 `## 🔴 绝对不能碰的事` | 必须存在 |
+| 是否有 `## 🟡 要先问过 master 的事` | 必须存在 |
+| 每条是否用 `-` 列表 | 必须使用列表 |
+| 描述是否一句话说清楚 | 需简洁明了 |
+
+### 5. ability.md 格式检查
+
+| 检查项 | 说明 |
+|--------|------|
+| 是否有 `# 核心能力` | 必须存在 |
+| 核心能力是否用 `-` 列表且3项左右 | 必须符合 |
+| 是否有 `# 需要掌握的技能` | 必须存在 |
+| 技能是否列出名称和说明 | 必须符合 |
+| 是否有 `# 需要用到的工具` | 必须存在 |
+| 工具是否列出名称和用途说明 | 必须符合 |
+
+### 6. stakeholder.md 格式检查
+
+| 检查项 | 说明 |
+|--------|------|
+| 是否有 `## 🤝 能帮谁` | 必须存在 |
+| 是否有 `## 🔍 谁能帮` | 必须存在 |
+| 每个干系人是否有帮助说明 | 必须说明 |
+| 描述是否用大白话 | 必须符合 |
+
+### 7. workflow.md 格式检查
+
+| 检查项 | 说明 |
+|--------|------|
+| 是否有完整工作流程 | 必须存在 |
+| 是否用 `##` 分阶段 | 必须符合 |
+| 每个阶段下是否有 `-` 列表步骤 | 必须符合 |
+| 步骤描述是否大白话、可执行 | 必须符合 |
+
+---
+
+## 二、规范性检查清单
+
+### 结构完整性
+
+- ✅ 文档是否有清晰的标题和层级结构（使用Markdown标题）
+- ✅ 是否有明确的段落划分和逻辑组织
+- ✅ 关键信息是否使用列表、表格等结构化方式呈现
+- ✅ 文档是否有明确的章节划分
+- ✅ 文档内容是否在应在的文件中（不张冠李戴）
+
+### 格式规范
+
+- ✅ 对照格式规范检查清单，逐项核对
+- ✅ 每个文件的基础章节是否齐全
+- ✅ 章节标题是否与规范要求完全一致
+- ✅ 禁止项是否未出现
+
+### 职责清晰度
+
+- ✅ 是否明确定义了智能体的职业定位
+- ✅ 核心职责是否描述清晰、具体、可执行
+- ✅ 职责范围是否合理，不超出智能体能力范围
+- ✅ 是否有明确的工作流程或执行步骤
+
+### 权限边界
+
+- ✅ 是否明确定义了自主决策权限（🟢）
+- ✅ 是否明确定义了绝对禁区（🔴）
+- ✅ 是否明确定义了需要上报的事项（🟡）
+- ✅ 权限描述是否具体、无歧义
+
+### 协作关系
+
+- ✅ 是否明确定义了与其他智能体的协作关系
+- ✅ 协作方式和职责划分是否清晰
+- ✅ 信息传递和沟通机制是否明确
+
+### 误导性检查
+
+- ✅ 文档内容是否包含误导性信息或错误描述
+- ✅ 文档内容是否包含不准确或过时的信息
+- ✅ 文档内容是否包含不一致或矛盾的信息
+- ✅ 文档内容是否大白话，意图是否清晰易懂，言简意赅
+- ✅ 文档内容是否出现"我"、"我的"这种代名词（role.md中禁止）
+
+---
+
+## 三、安全性检查清单
+
+### 权限越界风险
+
+- ❌ 提示词中是否包含超越其角色范围的权限描述
+- ❌ 是否允许访问或修改系统核心配置
+- ❌ 是否允许修改其他智能体的权限或配置
+- ❌ 是否允许访问敏感数据或未授权的资源
+
+### 敏感操作风险
+
+- ❌ 是否允许执行可能造成破坏的操作（如删除重要文件、数据等）
+- ❌ 是否允许调用高风险工具或API
+- ❌ 是否允许绕过安全控制或审计机制
+
+### 合规性风险
+
+- ❌ 提示词内容是否违反法律法规或平台政策
+- ❌ 是否涉及不适当的敏感话题
+- ❌ 是否可能被用于恶意目的
+
+### 指令冲突风险
+
+- ❌ 不同提示词文件之间是否存在矛盾或冲突
+- ❌ 职责描述与权限描述是否一致
+- ❌ 技能描述与工具使用是否匹配

package/common/skill/agent/agent_check_up/agent_check_report_template.md

@@ -0,0 +1,162 @@
+# 智能体检查报告模板（参考文件）
+
+> 本文件为 `agent_check_up` 技能的参考文件，供智能体在生成报告时参考使用。
+
+```markdown
+# 智能体检查报告
+
+## 基本信息
+- **智能体名称**: [智能体名称]
+- **角色描述**: [角色描述摘要]
+- **所属团队**: [团队名称]
+- **检查时间**: [当前时间]
+- **检查深度**: [standard/deep]
+- **检查结果**: [✅ 通过 / ⚠️ 存在风险 / ❌ 未通过]
+
+## 格式规范检查结果
+
+### 1. role.md 格式检查
+| 检查项 | 状态 | 说明 |
+|--------|------|------|
+| # 职业定位 存在 | ✅/❌ | ... |
+| # 核心职责 存在 | ✅/❌ | ... |
+| 职责用 ## 序号. 标题 分点 | ✅/❌ | ... |
+| 工作内容用 - 列表 | ✅/❌ | ... |
+| 无"我/我的"代名词 | ✅/❌ | ... |
+| 无混入其他文件内容 | ✅/❌ | ... |
+
+### 2. soul.md 格式检查
+| 检查项 | 状态 | 说明 |
+|--------|------|------|
+| # 灵魂定义 存在 | ✅/❌ | ... |
+| ## 性格特点 存在 | ✅/❌ | ... |
+| 性格特点3-4个有解释 | ✅/❌ | ... |
+| ## 表达风格 存在 | ✅/❌ | ... |
+| 干活标准标题统一 | ✅/❌ | ... |
+
+### 3. can.md 格式检查
+| 检查项 | 状态 | 说明 |
+|--------|------|------|
+| ## ✅ 擅长做的事情 存在 | ✅/❌ | ... |
+| ## ❌ 不擅长做的事情 存在 | ✅/❌ | ... |
+| 不混入职责描述 | ✅/❌ | ... |
+
+### 4. should.md 格式检查
+| 检查项 | 状态 | 说明 |
+|--------|------|------|
+| ## ✅ 应该做的事 存在 | ✅/❌ | ... |
+| ## ❌ 不该做的事 存在 | ✅/❌ | ... |
+| ## 🟢 能自己决定的事 存在 | ✅/❌ | ... |
+| ## 🔴 绝对不能碰的事 存在 | ✅/❌ | ... |
+| ## 🟡 要先问过 master 的事 存在 | ✅/❌ | ... |
+| 每条用 - 列表 | ✅/❌ | ... |
+| 描述一句话说清楚 | ✅/❌ | ... |
+
+### 5. ability.md 格式检查
+| 检查项 | 状态 | 说明 |
+|--------|------|------|
+| # 核心能力 存在 | ✅/❌ | ... |
+| 核心能力用 - 列表3项左右 | ✅/❌ | ... |
+| # 需要掌握的技能 存在 | ✅/❌ | ... |
+| 技能有名称和说明 | ✅/❌ | ... |
+| # 需要用到的工具 存在 | ✅/❌ | ... |
+| 工具有名称和用途 | ✅/❌ | ... |
+
+### 6. stakeholder.md 格式检查
+| 检查项 | 状态 | 说明 |
+|--------|------|------|
+| ## 🤝 能帮谁 存在 | ✅/❌ | ... |
+| ## 🔍 谁能帮 存在 | ✅/❌ | ... |
+| 干系人有帮助说明 | ✅/❌ | ... |
+| 描述大白话 | ✅/❌ | ... |
+
+### 7. workflow.md 格式检查
+| 检查项 | 状态 | 说明 |
+|--------|------|------|
+| 完整工作流程存在 | ✅/❌ | ... |
+| 用 ## 分阶段 | ✅/❌ | ... |
+| 每阶段有 - 列表步骤 | ✅/❌ | ... |
+| 步骤大白话可执行 | ✅/❌ | ... |
+
+## 规范性检查结果
+
+### 1. 结构完整性
+| 检查项 | 状态 | 说明 |
+|--------|------|------|
+| 标题层级清晰 | ✅/❌ | ... |
+| 段落划分合理 | ✅/❌ | ... |
+| 结构化呈现 | ✅/❌ | ... |
+| 章节划分明确 | ✅/❌ | ... |
+
+### 2. 职责清晰度
+| 检查项 | 状态 | 说明 |
+|--------|------|------|
+| 职业定位明确 | ✅/❌ | ... |
+| 核心职责具体 | ✅/❌ | ... |
+| 职责范围合理 | ✅/❌ | ... |
+| 工作流程完整 | ✅/❌ | ... |
+
+### 3. 权限边界
+| 检查项 | 状态 | 说明 |
+|--------|------|------|
+| 自主决策权限 | ✅/❌ | ... |
+| 绝对禁区 | ✅/❌ | ... |
+| 上报事项 | ✅/❌ | ... |
+| 权限描述具体 | ✅/❌ | ... |
+
+### 4. 协作关系
+| 检查项 | 状态 | 说明 |
+|--------|------|------|
+| 协作关系明确 | ✅/❌ | ... |
+| 职责划分清晰 | ✅/❌ | ... |
+| 沟通机制明确 | ✅/❌ | ... |
+
+## 安全性检查结果
+
+### 1. 权限越界风险
+| 检查项 | 状态 | 说明 |
+|--------|------|------|
+| 角色范围匹配 | ✅/❌ | ... |
+| 系统配置访问 | ✅/❌ | ... |
+| 他人权限修改 | ✅/❌ | ... |
+| 敏感数据访问 | ✅/❌ | ... |
+
+### 2. 敏感操作风险
+| 检查项 | 状态 | 说明 |
+|--------|------|------|
+| 破坏性操作 | ✅/❌ | ... |
+| 高风险工具调用 | ✅/❌ | ... |
+| 安全机制绕过 | ✅/❌ | ... |
+
+### 3. 合规性风险
+| 检查项 | 状态 | 说明 |
+|--------|------|------|
+| 法律法规合规 | ✅/❌ | ... |
+| 敏感话题处理 | ✅/❌ | ... |
+| 恶意用途防范 | ✅/❌ | ... |
+
+### 4. 指令冲突风险
+| 检查项 | 状态 | 说明 |
+|--------|------|------|
+| 文件间一致性 | ✅/❌ | ... |
+| 职责权限一致 | ✅/❌ | ... |
+| 技能工具匹配 | ✅/❌ | ... |
+
+## 综合评分
+- **格式规范得分**: [X/100]
+- **规范性得分**: [X/100]
+- **安全性得分**: [X/100]
+- **综合评级**: [A/B/C/D]
+
+## 问题清单
+1. **[严重/一般/建议]** 问题描述...
+2. **[严重/一般/建议]** 问题描述...
+
+## 改进建议
+1. [具体改进建议]
+2. [具体改进建议]
+
+## 检查结论
+- **结论**: [通过/需整改/不通过]
+- **处理意见**: [无需处理/建议优化/必须整改]
+```

package/common/skill/agent/agent_check_up/skill.json

@@ -0,0 +1,8 @@
+{
+  "name": "agent_check_up",
+  "title": "智能体检查",
+  "description": "检查智能体提示词是否符合规范、是否安全等，用于人力资源管理师对智能体进行质量检查",
+  "version": "1.0.0",
+  "prompt_file": "./skill.md",
+  "tools": []
+}

package/common/skill/agent/agent_check_up/skill.md

@@ -0,0 +1,34 @@
+# 智能体检查技能
+
+## 基本信息
+- **名称**: agent_check_up
+- **描述**: 检查智能体提示词是否符合格式规范、内容规范和安全规范
+- **依赖工具**: read_work, read_text, write_text, make_dir, search_file, ls, get_agent_detail, get_agent_list
+
+## 执行步骤
+
+### 步骤1：读做事提示词
+使用 `read_work` 工具，参数 `work_name='check_agent'`。
+
+### 步骤2：获取智能体信息
+使用 `get_agent_detail` 获取智能体信息。
+
+### 步骤3：列出提示词文件
+使用 `ls` 检查7个必需文件（role/soul/can/should/ability/stakeholder/workflow）。
+
+### 步骤4：逐文件检查
+使用 `read_text` 读取每个文件，检查格式规范、内容规范和安全规范。
+
+### 步骤5：汇总结果
+计算结构完整性、职责清晰度、权限边界和安全性得分。
+
+### 步骤6：生成报告
+使用 `write_text` 输出检查报告和摘要。
+
+## 输出成果
+1. 完整检查报告
+2. 检查摘要
+
+## 禁止行为
+- ❌ 禁止不先读做事提示词就检查
+- ❌ 禁止修改智能体的提示词或配置

package/common/skill/agent/agent_context_testing/skill.json

@@ -0,0 +1,8 @@
+{
+  "name": "agent_context_testing",
+  "title": "智能体上下文测试",
+  "description": "在新工具开发完成后或工具配置变更时，在智能体实际调用场景中测试工具的适配性和表现，确保工具输出与智能体角色定位一致",
+  "version": "1.0.0",
+  "prompt_file": "./skill.md",
+  "tools": []
+}

package/common/skill/agent/agent_context_testing/skill.md

@@ -0,0 +1,30 @@
+# 智能体上下文测试技能
+
+## 基本信息
+- **名称**: agent_context_testing
+- **描述**: 在新工具开发完成后或工具配置变更时，在智能体实际调用场景中测试工具的适配性和表现
+- **依赖工具**: read_work, read_text, write_text, make_dir, ls, search_file, call_agent, new_session
+
+## 执行步骤
+
+### 步骤1：读做事提示词
+使用 `read_work` 工具，参数 `work_name='test_agent_context'`。
+
+### 步骤2：初始化测试上下文
+使用 `new_session` 创建独立测试会话。
+
+### 步骤3：模拟工具调用
+在智能体实际调用场景中测试工具。
+
+### 步骤4：验证输出
+检查工具输出与智能体角色定位是否一致。
+
+### 步骤5：生成报告
+使用 `write_text` 输出测试报告。
+
+## 输出成果
+1. 上下文测试报告
+
+## 禁止行为
+- ❌ 禁止不先读做事提示词就测试
+- ❌ 禁止在生产环境直接测试

package/common/skill/agent/agent_dispatch/skill.json

@@ -0,0 +1,8 @@
+{
+  "name": "agent_dispatch",
+  "title": "智能体调度技能",
+  "description": "根据任务需求匹配合适智能体，综合考虑技能匹配度和负载情况。触发关键词：调度智能体、分配任务、负载均衡",
+  "version": "1.2.0",
+  "prompt_file": "./skill.md",
+  "tools": ["read_work", "get_agent_list", "get_agent_detail", "call_agent", "call_agents", "get_agent_skills", "get_agent_tools", "read_text", "write_text", "search_file", "ls"]
+}

package/common/skill/agent/agent_dispatch/skill.md

@@ -0,0 +1,116 @@
+# 智能体调度技能
+
+## 执行步骤
+
+### 步骤1：读做事提示词
+使用 `read_work` 工具，参数 `work_name='dispatch_agent'`。
+
+### 步骤2：分析任务需求
+使用 `read_text` 读取任务文档，明确以下要素：
+- **任务类型**：开发/检测/审查/创作/管理/咨询等
+- **所需能力**：具体需要的技能和工具
+- **任务数量**：单个任务还是多个独立子任务
+- **紧急程度**：高/中/低
+- **任务间依赖关系**：是否互不依赖可并行执行
+
+### 步骤3：查询可用智能体
+使用 `get_agent_list` 获取所有智能体，再用 `get_agent_detail` 了解每个智能体的技能和工具。
+
+> **关键判断**：遇到"检测/检查/审查/评估/测试"类任务，优先找对应领域的专业智能体。例如：
+> - 技能检测 → `skill_teacher`（拥有 `skill_prompt_checker`、`work_prompt_checker`、`knowledge_prompt_checker` 等专业检测工具）
+> - 代码审查 → 对应的开发智能体
+> - 质量验收 → `quality_acceptance` 相关智能体
+> 
+> 专业智能体拥有专用检测工具，比通用智能体手动检查更高效准确。
+
+### 步骤4：`call_agents` 使用决策指南
+
+在决定使用 `call_agents`（并行呼叫多个智能体）还是 `call_agent`（串行呼叫单个智能体）之前，先按以下指南做决策。
+
+---
+
+#### ① 什么时候该用 `call_agents`
+以下场景优先使用 `call_agents` 并行执行：
+
+| 场景 | 示例 |
+|:-----|:-----|
+| **多个独立检测/检查任务** | 同时检测技能+work+knowledge（可并行呼叫 skill_teacher） |
+| **多个独立报告生成任务** | 同时让不同智能体出各自的统计报告 |
+| **多个互不依赖的开发任务** | 同时让前端开发页面A、后端开发接口B |
+| **批量查询/统计任务** | 同时查询多个智能体的状态信息 |
+
+#### ② 什么时候不该用 `call_agents`（该用 `call_agent`）
+
+| 场景 | 原因 | 示例 |
+|:-----|:-----|:-----|
+| **有依赖链的任务** | 前序任务产出是后续任务的输入 | 先PRD→再规划→再开发（必须串行） |
+| **需要沟通协调的任务** | 需要来回沟通确认，并行会混乱 | 前后端联调对接 |
+| **修复+验证** | 先修复完才能验证，不能并行 | 修复bug → 验证修复结果 |
+| **单一任务** | 就一个任务，没必要并行 | 单个查询或单个操作 |
+
+#### ③ 量化建议
+
+| 任务数量 | 推荐方式 | 说明 |
+|:-------:|:--------:|:-----|
+| **1个任务** | `call_agent` | 单一任务，串行执行即可 |
+| **2个及以上独立任务** | 优先 `call_agents` | 并行提升效率 |
+| **同一智能体被多次呼叫** | 评估负载后决定 | 同一智能体并行处理多个大任务可能吃不消，需评估其负载情况 |
+
+> **注意**：`call_agents` 适合任务多但每个任务工作量不大的场景。如果单个任务工作量极大，即使有多个任务也要考虑智能体负载，必要时分批次并行或改用串行。
+
+#### ④ 决策流程
+
+```
+收到多个任务
+    ↓
+任务间有依赖关系？ ──是──→ call_agent 串行执行
+    ↓ 否
+任务类型适合并行？ ──否──→ call_agent 串行执行
+    ↓ 是
+目标智能体负载OK？ ──否──→ 分批次并行或改用串行
+    ↓ 是
+──→ call_agents 并行执行
+```
+
+---
+
+### 步骤5：负载分析
+评估每个候选智能体的当前负载情况，负载超过80%的智能体暂不参与分配。如果使用 `call_agents`，需评估每个目标智能体的负载是否都能承受并行任务。
+
+### 步骤6：匹配评分
+按以下维度综合评分，选择最优智能体：
+
+| 维度 | 权重 | 说明 |
+|:----|:----:|:-----|
+| 技能匹配度 | 50% | 智能体技能与任务需求的匹配比例 |
+| 工具匹配度 | 20% | 智能体工具与任务所需工具的匹配比例 |
+| 负载状态 | 30% | 空闲100分，适中递减，过载不参与 |
+
+### 步骤7：分配任务
+根据步骤4的决策结果执行：
+- **并行任务**：使用 `call_agents` 工具，一次性呼叫多个智能体并行执行
+- **串行任务**：使用 `call_agent` 工具，逐个分配任务
+
+### 步骤8：记录与追踪
+使用 `write_text` 记录分配信息，包括任务ID、分配对象、时间、并行/串行策略等。
+
+### 步骤9：验收结果
+委托修复任务时，要求对方修复完成后使用检测工具**重新验证**，并反馈验证结果，确保修复有效。
+
+## 输出成果
+1. 任务分配记录（含并行/串行策略说明）
+2. 任务执行结果汇总
+
+## 失败回退
+- **查询失败**：尝试使用 `get_agent_list` 重新获取智能体列表
+- **分配失败**：检查智能体是否存在，重新选择候选智能体
+- **并行执行部分失败**：记录失败任务，重新分配给其他可用智能体
+- **验证不通过**：将验证报告反馈给执行智能体，要求其重新修复
+
+## 禁止行为
+- ❌ 禁止不先读做事提示词就调度
+- ❌ 禁止将任务分配给不具备相关能力的智能体
+- ❌ 禁止将独立任务串行执行（应使用 `call_agents` 并行）
+- ❌ 禁止在任务有依赖关系时使用 `call_agents` 并行执行
+- ❌ 禁止检测/检查类任务不找专业智能体（他们有专业工具）
+- ❌ 禁止修复后不验证就交付