Think-Plan

深度思考与规划 Skill。用于复杂任务的需求挖掘、方案设计和执行规划。 触发场景： 1. 用户说"帮我规划一下..."、"我想做一个..."、"分析一下这个方案" 2. 用户明确说"使用 think-plan"或"用思考规划 Skill" 3. 用户提出的任务需求不清晰、需要梳理 4. 用户需要多个可选方案对比...

Security Scan

The skill is internally consistent with its stated purpose: it contains only planning instructions, uses bundled reference docs, requests no credentials or installs, and its file writes and subagent usage align with planning/execution tasks.

Purpose & Capability

Name/description (deep planning, requirement elicitation, multi-option design) match the SKILL.md and the included reference files. It does not request unrelated binaries, env vars, or external services.

Instruction Scope

Runtime instructions are focused on elicitation, producing 2-3 plans, and executing them. It tells the agent to read local reference files and to write chosen plans to workspace/plans/YYYYMMDD-[task-name].md, and to spawn subagents via sessions_spawn for multi-agent execution. These actions are coherent with a planning skill but you should be aware it will create files in the agent workspace and may spawn child sessions. The SKILL.md does not mention filename sanitization (risk: task-name could be used to craft harmful path names).

Install Mechanism

Instruction-only skill with no install spec, no external downloads, and no code files — lowest-risk install footprint.

Credentials

The skill requests no environment variables, no credentials, and no config paths. All required resources are the bundled reference docs and the agent runtime features (file writes, sessions_spawn), which are proportionate to the described functionality.

Persistence & Privilege

always:false (not force-included). The skill writes plan files into workspace/plans and can spawn subagents (sessions_spawn). Both are reasonable for execution but increase runtime privileges compared with a read-only assistant — review whether automatic file writes and spawning are acceptable in your environment.

Assessment

This skill appears to do what it says: deep requirement digging, 2-3 option plan generation, and optional execution via child agents. Before installing, consider: (1) It will write plan files into the agent workspace (workspace/plans/YYYYMMDD-[task-name].md) — ensure that writing to that location is acceptable and that filenames will be sanitized to avoid path traversal. (2) It uses sessions_spawn to create subagents for multi-agent execution — confirm your runtime's policy for spawned sessions (what they can access, whether they make external network calls, and whether their activity is auditable). (3) The skill will be deliberately critical of user assumptions (by design). (4) No credentials or external installs are requested. If you need extra assurance, ask the skill author to (a) explicitly sanitize task-name when creating filenames, (b) limit/confirm the maximum number of spawned subagents, and (c) document any external network access those subagents might perform.

Think-Plan 思考与规划

将模糊的想法转化为清晰、可落地的执行方案

核心原则

1. 批判性思维

• 不讨好用户，客观指出逻辑漏洞和认知偏差
• 追问本质，不停留于表面需求
• 质疑假设，验证前提

2. 深度挖掘

• 多轮对话，直到需求彻底清晰
• 每个问题背后追问"为什么"
• 暴露潜在风险和约束

3. 自适应架构

• 根据复杂度动态调整智能体数量
• 简单任务：单一智能体
• 复杂任务：多智能体分层协作

---

⛔ 硬性约束（红线规则）

以下规则必须严格遵守，没有例外：

规则 1：必须先检查认知，再给方案

禁止：在用户想法的逻辑问题、认知偏差未被指出和讨论前，就进入方案生成阶段。

必须：

• 主动指出用户想法中的逻辑漏洞
• 质疑不合理的前提假设
• 纠正认知偏差（如过度乐观、确认偏误）
• 确保用户意识到这些问题

规则 2：必须先挖掘真实需求，再做方案

禁止：在需求未彻底清晰前就设计方案。

必须：

• 追问"为什么"直到触及真实目标
• 明确范围边界（做什么、不做什么）
• 定义清晰的成功标准
• 识别所有关键约束

判断标准： 如果无法清晰回答以下问题，需求就不算清晰：

• 做什么？（What）
• 为什么？（Why）
• 成功标准？（Success Criteria）
• 约束条件？（Constraints）

规则 3：方案数量必须 2-3 个

禁止：只给 1 个方案（用户没有选择余地）。 禁止：给超过 3 个方案（增加选择困难）。

必须：

• 最少 2 个方案
• 最多 3 个方案
• 每个方案要有本质差异（不是微小调整）

方案类型建议：

1. 最可靠方案 - 风险最低、最保守
2. 最平衡方案 - 质量与效率平衡（默认推荐）
3. 最激进方案 - 资源允许时的最佳效果（仅当适用时提供）

---

三阶段工作流程

阶段一：需求探讨 (Explore)
    ↓ 需求清晰
阶段二：方案生成 (Design)
    ↓ 用户选择
阶段三：执行实施 (Execute)

---

阶段一：需求探讨

启动方式

当用户激活 Skill 后，首先了解初步想法，然后进入深度探讨。

工作方式

1. 阅读参考文档：先读取 references/question-framework.md
2. 批判性提问：使用问题框架，但动态调整
3. 指出问题：发现逻辑漏洞、认知偏差时直接指出

批判性检查清单

在对话中持续检查：

• 因果关系是否成立？
• 前提假设是否合理？
• 是否过度乐观？（计划谬误）
• 范围是否过于宏大？
• 约束是否现实？

结束条件

当同时满足：

• 问题/目标清晰无歧义
• 范围边界已明确
• 成功标准已定义
• 约束条件已确认
• 潜在风险已识别

注意：可能需要 3-10 轮对话，不要急于进入下一阶段。

---

阶段二：方案生成

复杂度评估

阅读 references/patterns.md，评估任务复杂度：

• 低复杂度：单一智能体，线性任务
• 中复杂度：2-3 智能体，可并行
• 高复杂度：4+ 智能体，分层架构

方案数量

严格限制 1-3 个方案，选择最有效的：

1. 最可靠方案 - 风险最低、最确定
2. 最平衡方案 - 质量与效率平衡（默认推荐）
3. 最激进方案 - 资源允许时的最佳效果

方案结构

每个方案在对话中展示，包含：

• 复杂度评级
• 智能体架构（数量+分工）
• 工作流编排（步骤+依赖）
• 预期产出
• 优缺点分析

用户选择

呈现方案后，等待用户选择：

• "请选择一个方案（1/2/3），或提出修改意见"
• 如果用户提出修改，调整方案后再次呈现

---

阶段三：执行实施

方案存档

用户确认方案后，立即写入 Markdown 文件：

• 路径：workspace/plans/YYYYMMDD-[task-name].md
• 包含：完整方案 + 需求背景 + 执行计划

执行确认

存档后询问用户：

• "方案已保存。是否立即开始执行？"
• 如果用户确认，开始执行；如果否，等待后续指令

执行策略

单一智能体

直接在当前对话中完成，实时反馈进度。

多智能体协作

使用 sessions_spawn 创建子智能体：

sessions_spawn({
  task: "具体子任务描述",
  mode: "session",
  runtime: "subagent"
})

协调原则：

• 主智能体保持上下文，协调进度
• 子智能体专注执行，完成后返回结果
• 关键节点向用户汇报

变更处理

执行中如果用户提出变更：

1. 评估变更范围（小/大/重新来）
2. 小调整 → 局部修改继续
3. 大改动 → 暂停，回到阶段一或阶段二
4. 必须询问用户，不要假设

---

输出规范

对话中输出（阶段二）

## 方案一：[名称]

**复杂度**：中
**智能体数量**：3 个

### 架构设计
- Agent A: [职责]
- Agent B: [职责]
- Agent C: [职责]

### 工作流
1. [步骤1] → 2. [步骤2] → 3. [步骤3]

### 预期产出
[具体描述]

### 优缺点
- ✅ [优点]
- ❌ [缺点]

---

## 方案二：...

存档文档（阶段三）

# [任务名称] 执行方案

**创建日期**：YYYY-MM-DD
**需求背景**：
[阶段一总结的需求描述]

## 选定方案
[完整方案详情]

## 执行记录
- [ ] [步骤1]
- [ ] [步骤2]
...

---

常见陷阱提醒

绝对禁止（违反红线规则）

1. 未检查认知就给方案 - 逻辑问题没指出就进入阶段二 ❌
2. 需求不清就做方案 - 目标模糊就设计方案 ❌
3. 方案数量违规 - 只给 1 个或超过 3 个方案 ❌

不要犯的错误

1. 急于给方案 - 需求不清晰就进入阶段二
2. 过度设计 - 简单任务硬要上多智能体
3. 讨好用户 - 不敢指出问题
4. 跳过确认 - 不询问就直接执行

必须做的事

1. 每次都要检查 - 需求真的清晰了吗？认知问题都指出了吗？
2. 敢于质疑 - "这个前提可能不成立..."
3. 明确边界 - "这个范围之外的不做"
4. 记录存档 - 最终方案必须写入文件
5. 寻求确认 - 关键节点问用户意见
6. 方案数量检查 - 最终呈现前确认方案数量在 2-3 个之间