@devflow-tools/claude-code-plugin 0.12.5 → 0.13.0

package/skills/devflow:git/SKILL.md

@@ -3,6 +3,44 @@ name: devflow:git
 description: Git 专家 — 提交规范、分支审查、Changelog 生成、冲突解决
 ---
 
+## 工作流（必须按顺序执行）
+
+### 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 分支策略。
@@ -32,11 +70,3 @@ description: Git 专家 — 提交规范、分支审查、Changelog 生成、冲
 - 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/skills/devflow:graph/SKILL.md

@@ -1,33 +1,51 @@
 ---
 name: devflow:graph
 description: 查看项目模块图谱 — 架构分层、文件分组、依赖可视化
-required_mcp_tools:
-  - get_dependency_graph
 ---
-## MANDATORY FIRST STEP - Skill Registration
 
-> **IMPORTANT: Before ANY other action, execute the registration command below. This is NON-NEGOTIABLE.**
+## 工作流（必须按顺序执行）
 
-```bash
-mkdir -p ~/.devflow && echo '{"name":"devflow:graph","required_mcp_tools":["get_dependency_graph"],"description":"devflow:graph skill","registeredAt":'"$(date +%s)000"'}' > ~/.devflow/current-skill.json
-```
+### Step 1: 获取精确上下文
+调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
+这一步确保你拿到的是项目真实状态，而非凭空猜测。
 
-After registration, you **MUST** use ONLY these MCP tools for all work in this skill:
-- `mcp__devflow__get_dependency_graph`
+### Step 2: 分析
+基于 Step 1 返回的上下文，分析问题根因或设计方案。
+此时可以自由使用 Read 查看具体文件。
 
-**Never use direct tools** (Read, Write, Edit, Bash, Grep, etc.) for tasks that can be handled by the MCP tools above.
+### Step 3: 执行
+根据分析结果修改代码，逐文件编辑。
 
-When the skill execution is complete, clean up:
-```bash
-rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
-```
+### Step 4: 验证
+运行类型检查和测试，确保改动正确。
+
+## 可用工具
+
+| 工具 | 何时调用 |
+|------|----------|
+| `mcp__devflow__get_project_context` | 每次任务第一步（必须） |
+| `mcp__devflow__get_dependency_graph` | 按需调用 |
+
+## 规则
+- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
+- 上下文返回后，用 Read 确认关键文件
+- 改完代码后跑类型检查
+
+## 规则
+- 永远从 `get_project_context` 开始——你不知道项目里有什么
+- 上下文返回后，用 Read 确认关键文件
+- 改完代码后跑类型检查
 
+## 规则
+- 永远从 `get_dependency_graph` 开始——你不知道项目里有什么
+- 上下文返回后，用 Read 确认关键文件
+- 改完代码后跑类型检查
 
 # /devflow:graph
 
 ## 执行
 
-调用 `get_dependency_graph` MCP 工具：
+调用 `mcp__devflow__get_dependency_graph` MCP 工具：
 
 ```
 target = "all"   (默认，拉取完整图谱)

package/skills/devflow:graphql/SKILL.md

@@ -3,6 +3,45 @@ name: devflow:graphql
 description: GraphQL 专家 — Schema 设计、N+1 检测、Resolver 优化、安全审计
 ---
 
+## 工作流（必须按顺序执行）
+
+### 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 实现。遇到问题先查文档，不凭空猜测。
@@ -31,11 +70,3 @@ description: GraphQL 专家 — Schema 设计、N+1 检测、Resolver 优化、
 
 - 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/skills/devflow:knowledge/SKILL.md

@@ -1,33 +1,51 @@
 ---
 name: devflow:knowledge
 description: 搜索技术文档知识库 — React、Vue、Nest、TypeScript 等官方文档
-required_mcp_tools:
-  - get_knowledge
 ---
-## MANDATORY FIRST STEP - Skill Registration
 
-> **IMPORTANT: Before ANY other action, execute the registration command below. This is NON-NEGOTIABLE.**
+## 工作流（必须按顺序执行）
 
-```bash
-mkdir -p ~/.devflow && echo '{"name":"devflow:knowledge","required_mcp_tools":["get_knowledge"],"description":"devflow:knowledge skill","registeredAt":'"$(date +%s)000"'}' > ~/.devflow/current-skill.json
-```
+### Step 1: 获取精确上下文
+调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
+这一步确保你拿到的是项目真实状态，而非凭空猜测。
 
-After registration, you **MUST** use ONLY these MCP tools for all work in this skill:
-- `mcp__devflow__get_knowledge`
+### Step 2: 分析
+基于 Step 1 返回的上下文，分析问题根因或设计方案。
+此时可以自由使用 Read 查看具体文件。
 
-**Never use direct tools** (Read, Write, Edit, Bash, Grep, etc.) for tasks that can be handled by the MCP tools above.
+### Step 3: 执行
+根据分析结果修改代码，逐文件编辑。
 
-When the skill execution is complete, clean up:
-```bash
-rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
-```
+### Step 4: 验证
+运行类型检查和测试，确保改动正确。
+
+## 可用工具
+
+| 工具 | 何时调用 |
+|------|----------|
+| `mcp__devflow__get_project_context` | 每次任务第一步（必须） |
+| `mcp__devflow__get_knowledge` | 按需调用 |
+
+## 规则
+- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
+- 上下文返回后，用 Read 确认关键文件
+- 改完代码后跑类型检查
+
+## 规则
+- 永远从 `get_project_context` 开始——你不知道项目里有什么
+- 上下文返回后，用 Read 确认关键文件
+- 改完代码后跑类型检查
 
+## 规则
+- 永远从 `get_knowledge` 开始——你不知道项目里有什么
+- 上下文返回后，用 Read 确认关键文件
+- 改完代码后跑类型检查
 
 # /devflow:knowledge
 
 ## 执行
 
-调用 `get_knowledge` MCP 工具：
+调用 `mcp__devflow__get_knowledge` MCP 工具：
 
 ```
 query = 用户的查询内容

package/skills/devflow:memory/SKILL.md

@@ -1,36 +1,54 @@
 ---
 name: devflow:memory
 description: 项目记忆 — 技术栈、编码约定、历史决策、用户偏好
-required_mcp_tools:
-  - get_memory
 ---
-## MANDATORY FIRST STEP - Skill Registration
 
-> **IMPORTANT: Before ANY other action, execute the registration command below. This is NON-NEGOTIABLE.**
+## 工作流（必须按顺序执行）
 
-```bash
-mkdir -p ~/.devflow && echo '{"name":"devflow:memory","required_mcp_tools":["get_memory"],"description":"devflow:memory skill","registeredAt":'"$(date +%s)000"'}' > ~/.devflow/current-skill.json
-```
+### Step 1: 获取精确上下文
+调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
+这一步确保你拿到的是项目真实状态，而非凭空猜测。
 
-After registration, you **MUST** use ONLY these MCP tools for all work in this skill:
-- `mcp__devflow__get_memory`
+### Step 2: 分析
+基于 Step 1 返回的上下文，分析问题根因或设计方案。
+此时可以自由使用 Read 查看具体文件。
 
-**Never use direct tools** (Read, Write, Edit, Bash, Grep, etc.) for tasks that can be handled by the MCP tools above.
+### Step 3: 执行
+根据分析结果修改代码，逐文件编辑。
 
-When the skill execution is complete, clean up:
-```bash
-rm -f ~/.devflow/current-skill.json ~/.devflow/current-execution-id
-```
+### Step 4: 验证
+运行类型检查和测试，确保改动正确。
+
+## 可用工具
+
+| 工具 | 何时调用 |
+|------|----------|
+| `mcp__devflow__get_project_context` | 每次任务第一步（必须） |
+| `mcp__devflow__get_memory` | 按需调用 |
+
+## 规则
+- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
+- 上下文返回后，用 Read 确认关键文件
+- 改完代码后跑类型检查
+
+## 规则
+- 永远从 `get_project_context` 开始——你不知道项目里有什么
+- 上下文返回后，用 Read 确认关键文件
+- 改完代码后跑类型检查
 
+## 规则
+- 永远从 `get_memory` 开始——你不知道项目里有什么
+- 上下文返回后，用 Read 确认关键文件
+- 改完代码后跑类型检查
 
 # /devflow:memory
 
 ## 执行
 
-调用 `get_memory` MCP 工具（无需参数）：
+调用 `mcp__devflow__get_memory` MCP 工具（无需参数）：
 
 ```
 （无参数 — 返回技术栈、约定、偏好、历史决策）
 ```
 
-项目记忆存储在 DevFlow 结构化数据库中，只有通过 MCP 工具才能获取完整数据。不要用 grep / Read 读取 .codegraph/ 目录下的缓存文件。
+项目记忆存储在 DevFlow 结构化数据库中，只有通过 MCP 工具才能获取完整数据。

package/skills/devflow:nest/SKILL.md

@@ -3,6 +3,45 @@ name: devflow:nest
 description: NestJS 专家 — 模块架构、守卫调试、微服务配置、Swagger 生成
 ---
 
+## 工作流（必须按顺序执行）
+
+### 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 原则。
@@ -31,11 +70,3 @@ description: NestJS 专家 — 模块架构、守卫调试、微服务配置、S
 
 - 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/skills/devflow:nextjs/SKILL.md

@@ -3,6 +3,45 @@ name: devflow:nextjs
 description: Next.js 专家 — App Router、SSR/SSG/ISR、Server Components、Middleware、部署
 ---
 
+## 工作流（必须按顺序执行）
+
+### 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。默认服务端渲染，按需客户端交互。
@@ -29,10 +68,3 @@ description: Next.js 专家 — App Router、SSR/SSG/ISR、Server Components、M
 
 - 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/skills/devflow:performance/SKILL.md

@@ -3,6 +3,44 @@ name: devflow:performance
 description: Web 性能专家 — Core Web Vitals、Bundle 优化、加载策略、渲染性能
 ---
 
+## 工作流（必须按顺序执行）
+
+### 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 优化和运行时性能。所有优化建议必须有数据依据。
@@ -32,11 +70,3 @@ description: Web 性能专家 — Core Web Vitals、Bundle 优化、加载策略
 
 - 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/skills/devflow:react/SKILL.md

@@ -3,6 +3,21 @@ name: devflow:react
 description: React 18 专家能力 — Bug 诊断、组件重构、性能优化、Hooks 审查
 ---
 
+# 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 行为。
@@ -36,15 +51,4 @@ description: React 18 专家能力 — Bug 诊断、组件重构、性能优化
 
 ## 当前版本
 
-- 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` |
+- react-docs: 18.3.1 — <https://react.dev/reference/react>

package/skills/devflow:tailwind/SKILL.md

@@ -3,6 +3,44 @@ name: devflow:tailwind
 description: Tailwind 专家 — 响应式设计、主题定制、Purge 检查、Utility 审查
 ---
 
+## 工作流（必须按顺序执行）
+
+### 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 官方文档。
@@ -29,10 +67,3 @@ description: Tailwind 专家 — 响应式设计、主题定制、Purge 检查
 
 - 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/skills/devflow:taro/SKILL.md

@@ -3,6 +3,44 @@ name: devflow:taro
 description: Taro 跨端专家 — 多端适配、小程序调试、性能优化、兼容方案
 ---
 
+## 工作流（必须按顺序执行）
+
+### 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，确保多端兼容。遇到小程序问题先查文档，不凭经验猜测。
@@ -31,11 +69,3 @@ description: Taro 跨端专家 — 多端适配、小程序调试、性能优化
 
 - 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` |