[aide] impl: 子计划2&3完成：修改 run 命令集成 skill 触发和强化流程图规范

.aide/flow-status.json

@@ -1,7 +1,7 @@
 {
   "task_id": "2025-12-16T20-22-50",
   "current_phase": "impl",
-  "current_step": 5,
+  "current_step": 6,
   "started_at": "2025-12-16T20:22:50+08:00",
   "history": [
     {
@@ -43,6 +43,14 @@
       "step": 5,
       "summary": "流程设计完成，进入实现环节",
       "git_commit": "dd3aba3c6ad5b6f94596f174b5b286c526107560"
+    },
+    {
+      "timestamp": "2025-12-16T20:27:30+08:00",
+      "action": "next-step",
+      "phase": "impl",
+      "step": 6,
+      "summary": "子计划1完成：创建 task-parser skill",
+      "git_commit": "b87f19f157294399bdb0a9132afae1ea6d36268f"
     }
   ]
 }

.aide/flow-status.lock

@@ -1 +1 @@
-77892
+78814

aide-marketplace/aide-plugin/commands/run.md

@@ -52,7 +52,25 @@ aide config get task.source
 
 读取任务文档内容。如文档不存在，询问用户提供任务内容。
 
-#### 1.3 任务分析
+#### 1.3 口语化内容检测
+
+检查任务文档或用户对话是否具有以下口语化特征：
+
+- 使用非正式的口头表达方式
+- 包含大量模糊表述（"我觉得"、"好像"、"大概"、"应该"等）
+- 句子结构松散，缺乏条理性
+- 包含冗余或重复的表达
+- 思维跳跃，逻辑不连贯
+
+**如果检测到口语化特征**：
+
+1. 触发 `task-parser` skill 学习口语化内容解析方法
+2. 按照 skill 指南对内容进行深度理解和规范化转换
+3. 将转换后的结构化内容作为后续分析的基础
+
+> 即使内容部分口语化，也应进行解析，提取核心意图
+
+#### 1.4 任务分析
 
 ##### 深度理解任务
 
@@ -68,14 +86,14 @@ aide config get task.source
 
 > 复杂任务（多子目标、多方案对比）建议使用 sequential-thinking 进行结构化分析
 
-#### 1.4 复杂度评估
+#### 1.5 复杂度评估
 
 根据**任务复杂度评估指导原则**（见附录）评估任务复杂度：
 
 - **简单/中等任务**：直接生成任务细则
 - **复杂/超大任务**：拆分为多个子计划
 
-#### 1.5 任务优化
+#### 1.6 任务优化
 
 ##### 准确性优化
 
@@ -98,7 +116,7 @@ aide config get task.source
 
 对于存在多种方案、有歧义、需要用户确认的内容，准备待定项数据。
 
-#### 1.6 待定项处理（如有）
+#### 1.7 待定项处理（如有）
 
 ```bash
 aide decide submit .aide/pending-items.json
@@ -106,7 +124,7 @@ aide decide submit .aide/pending-items.json
 aide decide result
 ```
 
-#### 1.7 生成任务细则
+#### 1.8 生成任务细则
 
 产出任务细则文档，保存到配置的路径。
 
@@ -134,6 +152,67 @@ aide flow next-part flow-design "进入流程设计环节"
 aide config get flow.diagram_path
 ```
 
+##### 流程图类型
+
+根据任务类型，需要创建不同类型的流程图：
+
+| 类型 | 适用场景 | 必需性 |
+|------|----------|--------|
+| 任务执行流程图 | 所有任务 | **必需** |
+| 程序逻辑流图 | 含程序设计与代码编写的任务 | **必需** |
+
+##### 任务执行流程图规范
+
+展示任务执行的步骤顺序：
+
+- **步骤分解**：将任务分解为具体的执行步骤
+- **顺序关系**：明确步骤之间的先后顺序
+- **决策点**：标注关键决策点和分支条件
+- **依赖关系**：体现步骤之间的依赖
+
+##### 程序逻辑流图规范
+
+展示程序代码的执行逻辑（仅限程序类任务）：
+
+- **入口点**：从程序入口函数（如 main、\_\_main\_\_）开始
+- **控制结构**：体现顺序、分支（if/switch）、循环（for/while）结构
+- **语义化抽象**：将代码逻辑抽象为人类可理解的业务描述，而非代码细节
+- **模块化表示**：
+  - 函数/模块表示为"盒子"
+  - 标注预期输入和输出
+  - 复杂函数可单独绘制详图
+- **层次化组织**：
+  - 主流程图展示程序整体执行流
+  - 关键子系统/模块可单独绘制详细流程图
+  - 通过引用关联主图与详图
+
+> **为什么需要程序逻辑流图**：
+> - 用户可以通过流程图快速理解程序的执行逻辑
+> - 在流程图阶段发现业务逻辑错误，避免实现后才发现方向错误
+> - 比逐行审阅代码更高效
+
+##### 流程图示例结构
+
+```plantuml
+@startuml
+' 主程序流程图
+start
+:初始化配置;
+:解析命令行参数;
+
+if (参数有效?) then (是)
+  :调用处理模块;
+  note right: 详见 process-module.puml
+else (否)
+  :显示错误信息;
+  stop
+endif
+
+:输出结果;
+stop
+@enduml
+```
+
 **所有任务必须有流程图**，用于：
 - 规范化思考
 - 方便用户审阅