Menu
任务分组规划器。阅读用户提示词或指定文档，将问题、任务进行智能分组，规划并行/串行执行顺序。适用于复杂任务拆分、批量任务规划、文档分析等场景。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
垂直领域搜索和批量并行搜索。当通用搜索（tavily）无法满足时使用。 触发场景： 1. 金融数据——股票代码、汇率、行情（finance.us_stock / cn_stock / forex） 2. 学术检索——论文、DOI（academic.search / academic.biomedical） 3. 安全漏洞——CVE、文件哈希、IP/域名扫描（security.scan / security.cve） 4. 法律、专利、教育、健康等其他垂直领域 5. 批量并行搜索——同时查 2-5 个独立问题 6. 中国国内信息——A 股、国内资讯（需 zone=cn） 触发词："股票"、"行情"、"汇率"、"CVE"、"漏洞"、"论文"、"DOI"、 "学术"、"专利"、"批量搜索"、"A股"、"anysearch"。 不触发场景：通用 web 搜索、新闻浏览、代码搜索、网页内容提取、网站爬取—— 这些由 tavily skill 处理。
Use when starting a new Remotion video project, adding scenes to an existing video, or converting a script into a video. Handles creative direction, script review, scene planning, pronunciation pre-check, segment-based voiceover generation, subtitle-based timeline calculation, and produces a complete design spec. Required before remotion-video-development. Also handles voiceover generation and timeline alignment via remotion-tools scripts.
Use when implementing Remotion video scenes from an approved design spec. Executes scene-by-scene with flex-first layout, subtitle-based timing, multi-segment audio playback, and per-scene verification. Requires completed design from remotion-video-design. Also use when regenerating voiceover segments, fixing pronunciation, or re-aligning timeline.
思维框架，帮助跳出局部修补的循环。两种触发模式。 模式一（用户主动）：当用户说"rethink"、"重新思考"、 "跳出来看"、"全局视角"、"这个问题我们是不是想错了"时加载， 直接进入完整分析。 模式二（AI 提议）：当你检测到以下信号时， 在回复末尾加一句提议 "我觉得我们可能在局部修补，要不要退一步重新看？"： 你对同一个文件做了 3 次以上修改仍未解决， 或用户连续 2 次否定你的方案， 或你发现方案里 workaround 和 edge case 越来越多。 用户同意后再执行完整分析。用户说不用则继续正常工作。
本地语义代码搜索。当需要按意图定位代码、查找实现、理解代码结构时使用，优先于 grep/read 用于探索性搜索。触发词："搜代码"、"code search"、"find implementation"、"理解代码实现"、"semble"、"语义搜索"、"search code"。
通用 Web 搜索、URL 内容提取、网站爬取。这是默认的搜索工具。 当用户需要：快速查事实、搜索新闻、fact-checking、提取网页内容、 爬取网站、深度研究（advanced 模式）时使用。 触发词："搜索"、"查一下"、"搜一下"、"lookup"、"search"、"research"、 "fact-check"、"联网搜索"、"查资料"、"提取网页"、"爬取网站"、 "tavily"、"网页内容"。 不触发场景：股票/金融数据查询、学术论文检索、CVE/安全漏洞查询、 批量并行搜索——这些场景由 anysearch skill 处理。
| name | task-group-planner |
| description | 任务分组规划器。阅读用户提示词或指定文档，将问题、任务进行智能分组，规划并行/串行执行顺序。适用于复杂任务拆分、批量任务规划、文档分析等场景。 |
任务分组规划器，用于将复杂任务拆分为适合 subagent 并行/串行执行的分组。
任务分组
分组规划
拆分任务
分析任务依赖
并行任务规划
优先读取用户当前提示词，如果用户提供文档路径则读取文档：
# 如果用户提供了文档路径
cat <文档路径>
# 如果用户直接输入了内容，直接使用用户提示词
# 无需额外读取
识别以下要素：
| 要素 | 说明 | 示例 |
|---|---|---|
| 原子任务 | 不可再分的最小任务单元 | "修复 bug A"、"优化模块 B" |
| 任务组 | 多个原子任务的集合 | "重构数据层"（包含多个文件修改） |
| 依赖关系 | 任务间的先后依赖 | "B 依赖 A 的输出" |
| 上下文规模 | 任务所需的信息量 | 大型重构 ≈ 2000 tokens，小型修改 ≈ 200 tokens |
分组标准：
| 标准 | 说明 | 阈值参考 |
|---|---|---|
| 上下文大小 | 单个 subagent 能处理的 token 上限 | 建议每组 500-2000 tokens |
| 依赖关系 | 无依赖的任务可并行，有依赖的需串行 | A → B 表示 B 依赖 A |
| 语义聚合 | 相关任务放同一组 | 同模块、同功能的任务优先合并 |
分组决策示例：
输入：6 个任务 {A, B, C, D, E, F}
依赖关系：D → B，A → C
上下文估算：A,B,C 各 300 tokens，D,E,F 各 800 tokens
分析：
- D → B（串行），A → C（串行）
- D,E,F 上下文较大，单独成组
- A,B,C 上下文较小，可合并
输出：
Group 1 (串行): [D] → [B]
Group 2 (并行): [A], [C], [E], [F]
使用预设模板生成执行计划文件。
用户指定目录：如果用户提供了输出目录，使用用户指定目录
默认目录：.claude/tmp/group-plan/
# 创建默认目录（如不存在）
mkdir -p .claude/tmp/group-plan/
使用 template/group-plan-template.md 作为模板文件。
模板结构：
# Task Group Plan
## 基本信息
- 生成时间: <时间戳>
- 输入来源: <用户提示词 / 文档路径>
- 输出目录: <用户指定目录 / 默认目录>
## 执行摘要
- 总任务数: <N>
- 分组数: <M>
- 并行组数: <X>
- 串行组数: <Y>
## 分组详情
### Group 1: <组名称>
**执行模式**: <并行 / 串行>
**前置依赖**: <依赖的组 / 无>
**任务列表**:
1. <任务 1>
2. <任务 2>
### Group 2: <组名称>
...
## 执行顺序
### 第一阶段（并行）
- [ ] Group 1: <任务描述>
- [ ] Group 2: <任务描述>
### 第二阶段（串行）
- [ ] Group 3: <任务描述> → 依赖 Group 1, 2
模板文件位置：.claude/skills/task-group-planner/template/group-plan-template.md
如需自定义模板，可修改该文件内容。
用户：帮我重构后端代码，包括：
1. 优化 Repository 层
2. 改进错误处理
3. 添加缓存机制
4. 重写 API 路由
5. 更新数据库 Schema
分析结果：
用户：分析 docs/refactoring-plan.md 文件，并进行任务分组
本 skill 负责：
本 skill 不负责：
| 情况 | 示例 | 原因 |
|---|---|---|
| 相同模块 | 多个 Repository 文件修改 | 上下文相关，减少切换 |
| 相同关注点 | 多个错误处理改进 | 思维连贯性 |
| 小任务累积 | 3 个小 bug 修复 | 平衡上下文大小 |
| 情况 | 示例 | 原因 |
|---|---|---|
| 不同模块 | API 层 vs 数据层 | 专业分工 |
| 依赖差异 | 有依赖 vs 无依赖 | 执行顺序不同 |
| 上下文过大 | 大型重构 | 避免 subagent 上下文溢出 |
显式依赖（用户明确说明）：
隐式依赖（合理推断）：
无依赖（可并行）：