@devflow-tools/cli 0.14.3 → 0.15.0

package/dist/plugin-files/dist/skills/devflow:animation/SKILL.md

@@ -28,44 +28,6 @@ When the skill execution is complete, clean up:
 rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 ```
 
-## 工作流（必须按顺序执行）
-
-### Step 1: 获取精确上下文
-调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
-这一步确保你拿到的是项目真实状态，而非凭空猜测。
-
-### Step 2: 分析
-基于 Step 1 返回的上下文，分析问题根因或设计方案。
-此时可以自由使用 Read 查看具体文件。
-
-### Step 3: 执行
-根据分析结果修改代码，逐文件编辑。
-
-### Step 4: 验证
-运行类型检查和测试，确保改动正确。
-
-## 可用工具
-
-| 工具 | 何时调用 |
-|------|----------|
-| `mcp__devflow__get_project_context` | 每次任务第一步（必须） |
-| `mcp__devflow__animation_suggest` | 按需调用 |
-
-## 规则
-- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `animation_suggest` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
 # ✨ ANIMATION
 
 你是一个动画专家。精通 CSS Animation、Framer Motion、GSAP。动画必须 60fps 且支持 prefers-reduced-motion。
@@ -92,3 +54,10 @@ rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 
 - animation-docs: 2024 — https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_animations
 
+## 工作流
+
+| 场景 | 触发方式 |
+|------|----------|
+| 动画审计：性能检查 → 可访问性 → 实现质量 | 调用 MCP 工具 `animation_audit:animation` |
+| 新建动画：需求分析 → 选型建议 → 实现 → 性能验证 | 调用 MCP 工具 `animation_new:animation` |
+| 动画 GPU 迁移：扫描 → 替换为 GPU 属性 → 验证 | 调用 MCP 工具 `animation_migrate:gpu-animation` |

package/dist/plugin-files/dist/skills/devflow:css/SKILL.md

@@ -28,44 +28,6 @@ When the skill execution is complete, clean up:
 rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 ```
 
-## 工作流（必须按顺序执行）
-
-### Step 1: 获取精确上下文
-调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
-这一步确保你拿到的是项目真实状态，而非凭空猜测。
-
-### Step 2: 分析
-基于 Step 1 返回的上下文，分析问题根因或设计方案。
-此时可以自由使用 Read 查看具体文件。
-
-### Step 3: 执行
-根据分析结果修改代码，逐文件编辑。
-
-### Step 4: 验证
-运行类型检查和测试，确保改动正确。
-
-## 可用工具
-
-| 工具 | 何时调用 |
-|------|----------|
-| `mcp__devflow__get_project_context` | 每次任务第一步（必须） |
-| `mcp__devflow__css_audit_selectors` | 按需调用 |
-
-## 规则
-- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `css_audit_selectors` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
 # 🎨 CSS
 
 你是一个 CSS 专家。使用现代布局方案（Flexbox/Grid），遵循 BEM 命名，移动优先响应式设计。遇到问题先查 MDN 文档。
@@ -92,3 +54,10 @@ rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 
 - mdn-css: 2024 — https://developer.mozilla.org/en-US/docs/Web/CSS
 
+## 工作流
+
+| 场景 | 触发方式 |
+|------|----------|
+| 布局调试：检查元素定位 → 弹性/网格属性 → 修复 | 调用 MCP 工具 `css_debug:layout` |
+| 响应式审查：断点检查 → 媒体查询 → 流体方案 | 调用 MCP 工具 `css_audit:responsive` |
+| BEM 命名审查：扫描类名 → 规范检查 → 修复建议 | 调用 MCP 工具 `css_review:bem` |

package/dist/plugin-files/dist/skills/devflow:docker/SKILL.md

@@ -28,44 +28,6 @@ When the skill execution is complete, clean up:
 rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 ```
 
-## 工作流（必须按顺序执行）
-
-### Step 1: 获取精确上下文
-调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
-这一步确保你拿到的是项目真实状态，而非凭空猜测。
-
-### Step 2: 分析
-基于 Step 1 返回的上下文，分析问题根因或设计方案。
-此时可以自由使用 Read 查看具体文件。
-
-### Step 3: 执行
-根据分析结果修改代码，逐文件编辑。
-
-### Step 4: 验证
-运行类型检查和测试，确保改动正确。
-
-## 可用工具
-
-| 工具 | 何时调用 |
-|------|----------|
-| `mcp__devflow__get_project_context` | 每次任务第一步（必须） |
-| `mcp__devflow__docker_dockerize_project` | 按需调用 |
-
-## 规则
-- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `docker_dockerize_project` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
 # 🐳 DOCKER
 
 你是一个 Docker 专家。使用多阶段构建优化镜像，遵循安全和性能最佳实践。遇到问题先查官方文档。
@@ -95,3 +57,11 @@ rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 
 - docker-docs: 26.0.0 — https://docs.docker.com/reference/
 
+## 工作流
+
+| 场景 | 触发方式 |
+|------|----------|
+| 项目 Docker 化：分析项目 → 多阶段 Dockerfile → Compose → 构建验证 | 调用 MCP 工具 `docker_dockerize_project` |
+| 镜像优化：体积分析 → 层优化 → 多阶段重构 | 调用 MCP 工具 `docker_optimize:image` |
+| 安全扫描：漏洞检测 → 配置审查 → 修复建议 | 调用 MCP 工具 `docker_scan:security` |
+| 多服务 Compose 编排：依赖分析 → 网络设计 → 环境管理 | 调用 MCP 工具 `docker_setup:compose` |

package/dist/plugin-files/dist/skills/devflow:electron/SKILL.md

@@ -28,44 +28,6 @@ When the skill execution is complete, clean up:
 rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 ```
 
-## 工作流（必须按顺序执行）
-
-### Step 1: 获取精确上下文
-调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
-这一步确保你拿到的是项目真实状态，而非凭空猜测。
-
-### Step 2: 分析
-基于 Step 1 返回的上下文，分析问题根因或设计方案。
-此时可以自由使用 Read 查看具体文件。
-
-### Step 3: 执行
-根据分析结果修改代码，逐文件编辑。
-
-### Step 4: 验证
-运行类型检查和测试，确保改动正确。
-
-## 可用工具
-
-| 工具 | 何时调用 |
-|------|----------|
-| `mcp__devflow__get_project_context` | 每次任务第一步（必须） |
-| `mcp__devflow__electron_diagnose_bug` | 按需调用 |
-
-## 规则
-- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `electron_diagnose_bug` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
 # ⚛️ ELECTRON
 
 你是一个 Electron 专家。使用 contextBridge + IPC 安全通信模式。严格遵循 Electron 安全最佳实践。
@@ -95,3 +57,11 @@ rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 
 - electron-docs: 30.0.0 — https://www.electronjs.org/docs/latest/
 
+## 工作流
+
+| 场景 | 触发方式 |
+|------|----------|
+| 新建 IPC 通道：定义 API → Preload 暴露 → 主进程处理 | 调用 MCP 工具 `electron_new:ipc` |
+| 安全审计：配置检查 → IPC 暴露面 → CSP → 第三方依赖 | 调用 MCP 工具 `electron_audit:security` |
+| 自动更新配置：electron-updater → 发布渠道 → 更新 UI | 调用 MCP 工具 `electron_setup:auto-update` |
+| Electron Bug 诊断：进程分类 → IPC 追踪 → 原生调试 | 调用 MCP 工具 `electron_diagnose_bug` |

package/dist/plugin-files/dist/skills/devflow:git/SKILL.md

@@ -28,44 +28,6 @@ When the skill execution is complete, clean up:
 rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 ```
 
-## 工作流（必须按顺序执行）
-
-### Step 1: 获取精确上下文
-调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
-这一步确保你拿到的是项目真实状态，而非凭空猜测。
-
-### Step 2: 分析
-基于 Step 1 返回的上下文，分析问题根因或设计方案。
-此时可以自由使用 Read 查看具体文件。
-
-### Step 3: 执行
-根据分析结果修改代码，逐文件编辑。
-
-### Step 4: 验证
-运行类型检查和测试，确保改动正确。
-
-## 可用工具
-
-| 工具 | 何时调用 |
-|------|----------|
-| `mcp__devflow__get_project_context` | 每次任务第一步（必须） |
-| `mcp__devflow__git_analyze_repo` | 按需调用 |
-
-## 规则
-- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `git_analyze_repo` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
 # 🔀 GIT
 
 你是一个 Git 工作流专家。遵循 Conventional Commits 规范和 GitFlow 分支策略。
@@ -95,3 +57,11 @@ rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 - conventional-commits: 1.0.0 — https://www.conventionalcommits.org/en/v1.0.0/
 - git-scm-docs: 2.45.0 — https://git-scm.com/docs
 
+## 工作流
+
+| 场景 | 触发方式 |
+|------|----------|
+| 规范化提交： | 调用 MCP 工具 `git_commit` |
+| 发布流程： | 调用 MCP 工具 `git_release` |
+| 分支清理： | 调用 MCP 工具 `git_audit:branches` |
+| 冲突解决： | 调用 MCP 工具 `git_resolve:conflicts` |

package/dist/plugin-files/dist/skills/devflow:graphql/SKILL.md

@@ -30,45 +30,6 @@ When the skill execution is complete, clean up:
 rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 ```
 
-## 工作流（必须按顺序执行）
-
-### Step 1: 获取精确上下文
-调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
-这一步确保你拿到的是项目真实状态，而非凭空猜测。
-
-### Step 2: 分析
-基于 Step 1 返回的上下文，分析问题根因或设计方案。
-此时可以自由使用 Read 查看具体文件。
-
-### Step 3: 执行
-根据分析结果修改代码，逐文件编辑。
-
-### Step 4: 验证
-运行类型检查和测试，确保改动正确。
-
-## 可用工具
-
-| 工具 | 何时调用 |
-|------|----------|
-| `mcp__devflow__get_project_context` | 每次任务第一步（必须） |
-| `mcp__devflow__graphql_new_graphql_type` | 按需调用 |
-| `mcp__devflow__graphql_diagnose_bug` | 按需调用 |
-
-## 规则
-- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `graphql_new_graphql_type` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
 # ◈ GRAPHQL
 
 你是一个 GraphQL 专家。使用 Schema-First 设计，Apollo Server 实现。遇到问题先查文档，不凭空猜测。
@@ -97,3 +58,11 @@ rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 
 - graphql-docs: 2024 — https://graphql.org/learn/
 
+## 工作流
+
+| 场景 | 触发方式 |
+|------|----------|
+| 新建 GraphQL Type + Resolver + DataLoader | 调用 MCP 工具 `graphql_new_graphql_type` |
+| N+1 检测与修复：扫描 Resolver → 识别批量模式 → 加 DataLoader | 调用 MCP 工具 `graphql_fix:n+1` |
+| Schema 设计审查：类型设计 → 分页模式 → 安全风险评估 | 调用 MCP 工具 `graphql_review:schema` |
+| GraphQL Bug 诊断：查询分析 → Resolver 链追踪 → 修复 | 调用 MCP 工具 `graphql_diagnose_bug` |

package/dist/plugin-files/dist/skills/devflow:nest/SKILL.md

@@ -30,45 +30,6 @@ When the skill execution is complete, clean up:
 rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 ```
 
-## 工作流（必须按顺序执行）
-
-### Step 1: 获取精确上下文
-调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
-这一步确保你拿到的是项目真实状态，而非凭空猜测。
-
-### Step 2: 分析
-基于 Step 1 返回的上下文，分析问题根因或设计方案。
-此时可以自由使用 Read 查看具体文件。
-
-### Step 3: 执行
-根据分析结果修改代码，逐文件编辑。
-
-### Step 4: 验证
-运行类型检查和测试，确保改动正确。
-
-## 可用工具
-
-| 工具 | 何时调用 |
-|------|----------|
-| `mcp__devflow__get_project_context` | 每次任务第一步（必须） |
-| `mcp__devflow__nest_new_module` | 按需调用 |
-| `mcp__devflow__nest_diagnose_bug` | 按需调用 |
-
-## 规则
-- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `nest_new_module` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
 # 🐱 NEST
 
 你是一个 NestJS 专家。使用装饰器模式、依赖注入和模块化架构。遵循 SOLID 原则。
@@ -97,3 +58,11 @@ rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 
 - nestjs-docs: 10.3.0 — https://docs.nestjs.com/
 
+## 工作流
+
+| 场景 | 触发方式 |
+|------|----------|
+| 新建 NestJS 模块（Controller + Service + Module + DTO + 测试） | 调用 MCP 工具 `nest_new_module` |
+| Bug 排查： | 调用 MCP 工具 `nest_diagnose_bug` |
+| Swagger 文档生成：扫描 API → 补充装饰器 → 验证 | 调用 MCP 工具 `nest_generate:swagger` |
+| 微服务端点配置：消息模式 → 传输层 → 客户端代理 | 调用 MCP 工具 `nest_setup:microservice` |

package/dist/plugin-files/dist/skills/devflow:nextjs/SKILL.md

@@ -30,45 +30,6 @@ When the skill execution is complete, clean up:
 rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 ```
 
-## 工作流（必须按顺序执行）
-
-### Step 1: 获取精确上下文
-调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
-这一步确保你拿到的是项目真实状态，而非凭空猜测。
-
-### Step 2: 分析
-基于 Step 1 返回的上下文，分析问题根因或设计方案。
-此时可以自由使用 Read 查看具体文件。
-
-### Step 3: 执行
-根据分析结果修改代码，逐文件编辑。
-
-### Step 4: 验证
-运行类型检查和测试，确保改动正确。
-
-## 可用工具
-
-| 工具 | 何时调用 |
-|------|----------|
-| `mcp__devflow__get_project_context` | 每次任务第一步（必须） |
-| `mcp__devflow__nextjs_new_page` | 按需调用 |
-| `mcp__devflow__nextjs_diagnose_bug` | 按需调用 |
-
-## 规则
-- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `nextjs_new_page` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
 # ▲ NEXTJS
 
 你是一个 Next.js 14 专家。使用 App Router、React Server Components。默认服务端渲染，按需客户端交互。
@@ -95,3 +56,10 @@ rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 
 - nextjs-docs: 14.2.0 — https://nextjs.org/docs
 
+## 工作流
+
+| 场景 | 触发方式 |
+|------|----------|
+| 新建 Next.js 页面（路由 + 数据获取 + 渲染策略） | 调用 MCP 工具 `nextjs_new_page` |
+| Pages Router → App Router 迁移：路由映射 → 数据获取 → 渐进迁移 | 调用 MCP 工具 `nextjs_migrate:app-router` |
+| Bug 排查： | 调用 MCP 工具 `nextjs_diagnose_bug` |

package/dist/plugin-files/dist/skills/devflow:performance/SKILL.md

@@ -28,44 +28,6 @@ When the skill execution is complete, clean up:
 rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 ```
 
-## 工作流（必须按顺序执行）
-
-### Step 1: 获取精确上下文
-调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
-这一步确保你拿到的是项目真实状态，而非凭空猜测。
-
-### Step 2: 分析
-基于 Step 1 返回的上下文，分析问题根因或设计方案。
-此时可以自由使用 Read 查看具体文件。
-
-### Step 3: 执行
-根据分析结果修改代码，逐文件编辑。
-
-### Step 4: 验证
-运行类型检查和测试，确保改动正确。
-
-## 可用工具
-
-| 工具 | 何时调用 |
-|------|----------|
-| `mcp__devflow__get_project_context` | 每次任务第一步（必须） |
-| `mcp__devflow__performance_audit_performance` | 按需调用 |
-
-## 规则
-- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `performance_audit_performance` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
 # ⚡ PERFORMANCE
 
 你是一个 Web 性能专家。精通 Core Web Vitals、Bundle 优化和运行时性能。所有优化建议必须有数据依据。
@@ -95,3 +57,11 @@ rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 
 - web-vitals-docs: 2024 — https://web.dev/vitals/
 
+## 工作流
+
+| 场景 | 触发方式 |
+|------|----------|
+| 性能审计：Lighthouse → Web Vitals → Bundle → 优化方案 | 调用 MCP 工具 `performance_audit_performance` |
+| Bundle 优化：分析 → 代码分割 → Tree Shaking → 验证 | 调用 MCP 工具 `performance_optimize:bundle` |
+| 加载速度优化：资源加载策略 → 预加载 → 缓存 | 调用 MCP 工具 `performance_optimize:load-speed` |
+| 运行时性能优化：长任务 → 渲染卡顿 → 内存泄漏 | 调用 MCP 工具 `performance_optimize:runtime` |

package/dist/plugin-files/dist/skills/devflow:react/SKILL.md

@@ -38,21 +38,6 @@ When the skill execution is complete, clean up:
 rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 ```
 
-# DevFlow React
-
-## 快速流程
-
-1. 先调用 `mcp__devflow__get_project_context` 缩小到目标文件、组件和约定。
-2. 再按任务选择，并优先传精确参数：
-   - `mcp__devflow__react_diagnose_bug`
-   - `mcp__devflow__react_audit_performance`
-   - `mcp__devflow__react_review_hooks`
-   - `mcp__devflow__react_refactor_component`
-   - `mcp__devflow__react_new_component`
-3. 目标已知时，明确传 `projectRoot`、精确 `filePath`、正确 `componentName` 和 `scope=target`，不要把目录路径当成文件路径。
-4. MCP 结果过大时，优先继续使用返回里的 `reportId`、`get_report_details` 和 `resourceUri`，不要回退成全项目人工缩范围。
-5. 只有在需要确认实现细节时再用 Read，修改后跑类型检查和测试。
-
 # ⚛️ REACT
 
 你是一个 React 18 专家。使用函数组件、Hooks 和 TypeScript。遇到问题先查文档再给方案，不凭空猜测 API 行为。
@@ -86,4 +71,15 @@ rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 
 ## 当前版本
 
-- react-docs: 18.3.1 — <https://react.dev/reference/react>
+- react-docs: 18.3.1 — https://react.dev/reference/react
+
+## 工作流
+
+| 场景 | 触发方式 |
+|------|----------|
+| Bug 排查： | 调用 MCP 工具 `react_diagnose_bug` |
+| 新功能开发： | 调用 MCP 工具 `react_new_feature` |
+| 性能卡顿： | 调用 MCP 工具 `react_audit_performance` |
+| Hooks 审查： | 调用 MCP 工具 `react_review_hooks` |
+| 组件拆分： | 调用 MCP 工具 `react_refactor_component` |
+| 新建组件： | 调用 MCP 工具 `react_new_component` |

package/dist/plugin-files/dist/skills/devflow:tailwind/SKILL.md

@@ -28,44 +28,6 @@ When the skill execution is complete, clean up:
 rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 ```
 
-## 工作流（必须按顺序执行）
-
-### Step 1: 获取精确上下文
-调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
-这一步确保你拿到的是项目真实状态，而非凭空猜测。
-
-### Step 2: 分析
-基于 Step 1 返回的上下文，分析问题根因或设计方案。
-此时可以自由使用 Read 查看具体文件。
-
-### Step 3: 执行
-根据分析结果修改代码，逐文件编辑。
-
-### Step 4: 验证
-运行类型检查和测试，确保改动正确。
-
-## 可用工具
-
-| 工具 | 何时调用 |
-|------|----------|
-| `mcp__devflow__get_project_context` | 每次任务第一步（必须） |
-| `mcp__devflow__tailwind_new_component` | 按需调用 |
-
-## 规则
-- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `tailwind_new_component` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
 # 🌊 TAILWIND
 
 你是一个 Tailwind CSS 专家。使用 utility-first 方法构建界面。遇到问题先查 Tailwind 官方文档。
@@ -92,3 +54,10 @@ rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 
 - tailwind-docs: 3.4.0 — https://tailwindcss.com/docs
 
+## 工作流
+
+| 场景 | 触发方式 |
+|------|----------|
+| 新建 Tailwind 组件：语义结构 → 样式 → 响应式 → 暗色模式 | 调用 MCP 工具 `tailwind_new_component` |
+| Utility 审查：清除自定义 CSS → 统一为 Tailwind utility | 调用 MCP 工具 `tailwind_audit:utility` |
+| 主题迁移：分析现有设计 → 提取 Design Token → 生成配置 | 调用 MCP 工具 `tailwind_migrate:theme` |

package/dist/plugin-files/dist/skills/devflow:taro/SKILL.md

@@ -28,44 +28,6 @@ When the skill execution is complete, clean up:
 rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 ```
 
-## 工作流（必须按顺序执行）
-
-### Step 1: 获取精确上下文
-调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
-这一步确保你拿到的是项目真实状态，而非凭空猜测。
-
-### Step 2: 分析
-基于 Step 1 返回的上下文，分析问题根因或设计方案。
-此时可以自由使用 Read 查看具体文件。
-
-### Step 3: 执行
-根据分析结果修改代码，逐文件编辑。
-
-### Step 4: 验证
-运行类型检查和测试，确保改动正确。
-
-## 可用工具
-
-| 工具 | 何时调用 |
-|------|----------|
-| `mcp__devflow__get_project_context` | 每次任务第一步（必须） |
-| `mcp__devflow__taro_new_page` | 按需调用 |
-
-## 规则
-- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `taro_new_page` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
 # 🛠️ TARO
 
 你是一个 Taro 跨端开发专家。使用 Taro 内置组件和 API，确保多端兼容。遇到小程序问题先查文档，不凭经验猜测。
@@ -94,3 +56,11 @@ rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 
 - taro-docs: 3.6.0 — https://docs.taro.zone/docs/
 
+## 工作流
+
+| 场景 | 触发方式 |
+|------|----------|
+| 新建页面： | 调用 MCP 工具 `taro_new_page` |
+| 跨端兼容检查：扫描平台 API → 识别风险点 → 建议兼容方案 | 调用 MCP 工具 `taro_check:cross-platform` |
+| 小程序调试：错误排查 → 包体积分析 → 性能检测 | 调用 MCP 工具 `taro_debug:miniapp` |
+| 小程序性能优化：包体积 → 渲染优化 → 加载速度 | 调用 MCP 工具 `taro_optimize:performance` |

package/dist/plugin-files/dist/skills/devflow:ui-layout/SKILL.md

@@ -28,44 +28,6 @@ When the skill execution is complete, clean up:
 rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 ```
 
-## 工作流（必须按顺序执行）
-
-### Step 1: 获取精确上下文
-调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
-这一步确保你拿到的是项目真实状态，而非凭空猜测。
-
-### Step 2: 分析
-基于 Step 1 返回的上下文，分析问题根因或设计方案。
-此时可以自由使用 Read 查看具体文件。
-
-### Step 3: 执行
-根据分析结果修改代码，逐文件编辑。
-
-### Step 4: 验证
-运行类型检查和测试，确保改动正确。
-
-## 可用工具
-
-| 工具 | 何时调用 |
-|------|----------|
-| `mcp__devflow__get_project_context` | 每次任务第一步（必须） |
-| `mcp__devflow__ui_layout_generate` | 按需调用 |
-
-## 规则
-- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `ui_layout_generate` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
 # 📐 UI-LAYOUT
 
 你是一个 UI Layout 专家。精通 CSS Grid、Flexbox 和响应式设计。使用 Design Token 体系管理样式变量。
@@ -92,3 +54,10 @@ rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 
 - web-dev-layout: 2024 — https://web.dev/learn/design/
 
+## 工作流
+
+| 场景 | 触发方式 |
+|------|----------|
+| 布局审计：一致性检查 → 响应式问题 → 可访问性评估 | 调用 MCP 工具 `ui-layout_audit:layout` |
+| 响应式改造：断点分析 → 移动适配 → Container Queries | 调用 MCP 工具 `ui-layout_design:responsive` |
+| Design Token 体系建设：提取 → 分层 → 代码化 | 调用 MCP 工具 `ui-layout_setup:design-tokens` |

package/dist/plugin-files/dist/skills/devflow:vue/SKILL.md

@@ -32,46 +32,6 @@ When the skill execution is complete, clean up:
 rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 ```
 
-## 工作流（必须按顺序执行）
-
-### Step 1: 获取精确上下文
-调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
-这一步确保你拿到的是项目真实状态，而非凭空猜测。
-
-### Step 2: 分析
-基于 Step 1 返回的上下文，分析问题根因或设计方案。
-此时可以自由使用 Read 查看具体文件。
-
-### Step 3: 执行
-根据分析结果修改代码，逐文件编辑。
-
-### Step 4: 验证
-运行类型检查和测试，确保改动正确。
-
-## 可用工具
-
-| 工具 | 何时调用 |
-|------|----------|
-| `mcp__devflow__get_project_context` | 每次任务第一步（必须） |
-| `mcp__devflow__vue_diagnose_bug` | 按需调用 |
-| `mcp__devflow__vue_new_component` | 按需调用 |
-| `mcp__devflow__vue_debug_reactivity` | 按需调用 |
-
-## 规则
-- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `get_project_context` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
-## 规则
-- 永远从 `vue_diagnose_bug` 开始——你不知道项目里有什么
-- 上下文返回后，用 Read 确认关键文件
-- 改完代码后跑类型检查
-
 # 💚 VUE
 
 你是一个 Vue 3 专家。使用 Composition API、<script setup> 和 TypeScript。遇到问题先查文档再给方案，不凭空猜测。
@@ -103,3 +63,12 @@ rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
 
 - vue-docs: 3.4.0 — https://vuejs.org/guide/introduction.html
 
+## 工作流
+
+| 场景 | 触发方式 |
+|------|----------|
+| Bug 排查： | 调用 MCP 工具 `vue_diagnose_bug` |
+| 新建组件： | 调用 MCP 工具 `vue_new_component` |
+| 响应式调试：追踪数据流 → 定位问题 → 修复 | 调用 MCP 工具 `vue_debug_reactivity` |
+| 提取 Composable：识别重复逻辑 → 抽取 → 替换引用 | 调用 MCP 工具 `vue_extract:composable` |
+| Pinia Store 重构：结构审查 → 拆分/合并 → 类型安全 | 调用 MCP 工具 `vue_refactor:pinia` |

package/dist/plugin-files/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@devflow-tools/claude-code-plugin",
-  "version": "0.14.0",
+  "version": "0.15.0",
   "description": "DevFlow — Developer Intelligence Platform for Claude Code",
   "type": "module",
   "scripts": {
@@ -8,7 +8,7 @@
     "deploy": "npx tsx scripts/inject-gates.ts --deploy"
   },
   "devDependencies": {
-    "@devflow-tools/mcp-server": "^0.14.0"
+    "@devflow-tools/mcp-server": "0.15.0"
   },
   "keywords": [
     "pi-package",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@devflow-tools/cli",
-  "version": "0.14.3",
+  "version": "0.15.0",
   "type": "module",
   "main": "./dist/index.js",
   "scripts": {
@@ -12,31 +12,31 @@
   },
   "dependencies": {
     "@colbymchenry/codegraph": "^1.1.1",
-    "@devflow-tools/adapters": "^0.14.0",
-    "@devflow-tools/benchmark": "^0.14.3",
-    "@devflow-tools/context-engine": "^0.14.3",
-    "@devflow-tools/database": "^0.14.0",
-    "@devflow-tools/knowledge-engine": "^0.14.3",
-    "@devflow-tools/mcp-server": "^0.14.3",
-    "@devflow-tools/memory-engine": "^0.14.3",
-    "@devflow-tools/plugin-animation": "^0.14.0",
-    "@devflow-tools/plugin-css": "^0.14.0",
-    "@devflow-tools/plugin-docker": "^0.14.0",
-    "@devflow-tools/plugin-electron": "^0.14.0",
-    "@devflow-tools/plugin-git": "^0.14.0",
-    "@devflow-tools/plugin-graphql": "^0.14.0",
-    "@devflow-tools/plugin-nest": "^0.14.0",
-    "@devflow-tools/plugin-nextjs": "^0.14.0",
-    "@devflow-tools/plugin-performance": "^0.14.0",
-    "@devflow-tools/plugin-react": "^0.14.0",
-    "@devflow-tools/plugin-tailwind": "^0.14.0",
-    "@devflow-tools/plugin-taro": "^0.14.0",
-    "@devflow-tools/plugin-ui-layout": "^0.14.0",
-    "@devflow-tools/plugin-vue": "^0.14.0",
-    "@devflow-tools/sdk": "^0.14.0",
-    "@devflow-tools/server": "^0.14.3",
-    "@devflow-tools/telemetry": "^0.14.0",
-    "@devflow-tools/workflow-engine": "^0.14.0",
+    "@devflow-tools/adapters": "0.15.0",
+    "@devflow-tools/benchmark": "0.15.0",
+    "@devflow-tools/context-engine": "0.15.0",
+    "@devflow-tools/database": "0.15.0",
+    "@devflow-tools/knowledge-engine": "0.15.0",
+    "@devflow-tools/mcp-server": "0.15.0",
+    "@devflow-tools/memory-engine": "0.15.0",
+    "@devflow-tools/plugin-animation": "0.15.0",
+    "@devflow-tools/plugin-css": "0.15.0",
+    "@devflow-tools/plugin-docker": "0.15.0",
+    "@devflow-tools/plugin-electron": "0.15.0",
+    "@devflow-tools/plugin-git": "0.15.0",
+    "@devflow-tools/plugin-graphql": "0.15.0",
+    "@devflow-tools/plugin-nest": "0.15.0",
+    "@devflow-tools/plugin-nextjs": "0.15.0",
+    "@devflow-tools/plugin-performance": "0.15.0",
+    "@devflow-tools/plugin-react": "0.15.0",
+    "@devflow-tools/plugin-tailwind": "0.15.0",
+    "@devflow-tools/plugin-taro": "0.15.0",
+    "@devflow-tools/plugin-ui-layout": "0.15.0",
+    "@devflow-tools/plugin-vue": "0.15.0",
+    "@devflow-tools/sdk": "0.15.0",
+    "@devflow-tools/server": "0.15.0",
+    "@devflow-tools/telemetry": "0.15.0",
+    "@devflow-tools/workflow-engine": "0.15.0",
     "@inquirer/prompts": "^7.10.1",
     "chalk": "^5.3.0",
     "commander": "^12.0.0"
@@ -49,5 +49,5 @@
     "dist",
     "bin"
   ],
-  "gitHead": "eb0ccfbe8146f51c56976f051ea1dcd10c5edd18"
+  "gitHead": "716b2355d8bea1138f4b7551758044c3663fad0e"
 }