@devflow-tools/claude-code-plugin 0.12.6 → 0.13.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/command-registry.json +235 -0
- package/dist/hooks/hook-client.js +6 -6
- package/dist/hooks/hook-daemon.js +7 -7
- package/dist/hooks/post-tool-use.js +2 -2
- package/dist/hooks/pre-tool-use.js +2 -2
- package/dist/skills/devflow:animation/SKILL.md +63 -0
- package/dist/skills/devflow:css/SKILL.md +63 -0
- package/dist/skills/devflow:docker/SKILL.md +67 -0
- package/dist/skills/devflow:electron/SKILL.md +67 -0
- package/dist/skills/devflow:git/SKILL.md +67 -0
- package/dist/skills/devflow:graphql/SKILL.md +68 -0
- package/dist/skills/devflow:nest/SKILL.md +68 -0
- package/dist/skills/devflow:nextjs/SKILL.md +65 -0
- package/dist/skills/devflow:performance/SKILL.md +67 -0
- package/dist/skills/devflow:react/SKILL.md +85 -0
- package/dist/skills/devflow:tailwind/SKILL.md +65 -0
- package/dist/skills/devflow:taro/SKILL.md +66 -0
- package/dist/skills/devflow:ui-layout/SKILL.md +63 -0
- package/dist/skills/devflow:vue/SKILL.md +74 -0
- package/hooks/post-tool-use +6 -2
- package/hooks/session-start +33 -22
- package/package.json +3 -3
- package/skills/devflow:animation/SKILL.md +38 -7
- package/skills/devflow:context/SKILL.md +36 -17
- package/skills/devflow:css/SKILL.md +38 -7
- package/skills/devflow:docker/SKILL.md +38 -8
- package/skills/devflow:electron/SKILL.md +38 -8
- package/skills/devflow:git/SKILL.md +38 -8
- package/skills/devflow:graph/SKILL.md +33 -15
- package/skills/devflow:graphql/SKILL.md +39 -8
- package/skills/devflow:knowledge/SKILL.md +33 -15
- package/skills/devflow:memory/SKILL.md +34 -16
- package/skills/devflow:nest/SKILL.md +39 -8
- package/skills/devflow:nextjs/SKILL.md +39 -7
- package/skills/devflow:performance/SKILL.md +38 -8
- package/skills/devflow:react/SKILL.md +16 -12
- package/skills/devflow:start/SKILL.md +24 -17
- package/skills/devflow:tailwind/SKILL.md +38 -7
- package/skills/devflow:taro/SKILL.md +38 -8
- package/skills/devflow:ui-layout/SKILL.md +38 -7
- package/skills/devflow:vue/SKILL.md +40 -9
- package/skills/devflow:workflow/SKILL.md +33 -15
|
@@ -3,6 +3,44 @@ name: devflow:git
|
|
|
3
3
|
description: Git 专家 — 提交规范、分支审查、Changelog 生成、冲突解决
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
+
## 工作流(必须按顺序执行)
|
|
7
|
+
|
|
8
|
+
### Step 1: 获取精确上下文
|
|
9
|
+
调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
|
|
10
|
+
这一步确保你拿到的是项目真实状态,而非凭空猜测。
|
|
11
|
+
|
|
12
|
+
### Step 2: 分析
|
|
13
|
+
基于 Step 1 返回的上下文,分析问题根因或设计方案。
|
|
14
|
+
此时可以自由使用 Read 查看具体文件。
|
|
15
|
+
|
|
16
|
+
### Step 3: 执行
|
|
17
|
+
根据分析结果修改代码,逐文件编辑。
|
|
18
|
+
|
|
19
|
+
### Step 4: 验证
|
|
20
|
+
运行类型检查和测试,确保改动正确。
|
|
21
|
+
|
|
22
|
+
## 可用工具
|
|
23
|
+
|
|
24
|
+
| 工具 | 何时调用 |
|
|
25
|
+
|------|----------|
|
|
26
|
+
| `mcp__devflow__get_project_context` | 每次任务第一步(必须) |
|
|
27
|
+
| `mcp__devflow__git_analyze_repo` | 按需调用 |
|
|
28
|
+
|
|
29
|
+
## 规则
|
|
30
|
+
- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
|
|
31
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
32
|
+
- 改完代码后跑类型检查
|
|
33
|
+
|
|
34
|
+
## 规则
|
|
35
|
+
- 永远从 `get_project_context` 开始——你不知道项目里有什么
|
|
36
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
37
|
+
- 改完代码后跑类型检查
|
|
38
|
+
|
|
39
|
+
## 规则
|
|
40
|
+
- 永远从 `git_analyze_repo` 开始——你不知道项目里有什么
|
|
41
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
42
|
+
- 改完代码后跑类型检查
|
|
43
|
+
|
|
6
44
|
# 🔀 GIT
|
|
7
45
|
|
|
8
46
|
你是一个 Git 工作流专家。遵循 Conventional Commits 规范和 GitFlow 分支策略。
|
|
@@ -32,11 +70,3 @@ description: Git 专家 — 提交规范、分支审查、Changelog 生成、冲
|
|
|
32
70
|
- conventional-commits: 1.0.0 — https://www.conventionalcommits.org/en/v1.0.0/
|
|
33
71
|
- git-scm-docs: 2.45.0 — https://git-scm.com/docs
|
|
34
72
|
|
|
35
|
-
## 工作流
|
|
36
|
-
|
|
37
|
-
| 场景 | 触发方式 |
|
|
38
|
-
|------|----------|
|
|
39
|
-
| 规范化提交: | 调用 MCP 工具 `git_commit` |
|
|
40
|
-
| 发布流程: | 调用 MCP 工具 `git_release` |
|
|
41
|
-
| 分支清理: | 调用 MCP 工具 `git_audit:branches` |
|
|
42
|
-
| 冲突解决: | 调用 MCP 工具 `git_resolve:conflicts` |
|
|
@@ -1,33 +1,51 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: devflow:graph
|
|
3
3
|
description: 查看项目模块图谱 — 架构分层、文件分组、依赖可视化
|
|
4
|
-
required_mcp_tools:
|
|
5
|
-
- get_dependency_graph
|
|
6
4
|
---
|
|
7
|
-
## MANDATORY FIRST STEP - Skill Registration
|
|
8
5
|
|
|
9
|
-
|
|
6
|
+
## 工作流(必须按顺序执行)
|
|
10
7
|
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
8
|
+
### Step 1: 获取精确上下文
|
|
9
|
+
调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
|
|
10
|
+
这一步确保你拿到的是项目真实状态,而非凭空猜测。
|
|
14
11
|
|
|
15
|
-
|
|
16
|
-
|
|
12
|
+
### Step 2: 分析
|
|
13
|
+
基于 Step 1 返回的上下文,分析问题根因或设计方案。
|
|
14
|
+
此时可以自由使用 Read 查看具体文件。
|
|
17
15
|
|
|
18
|
-
|
|
16
|
+
### Step 3: 执行
|
|
17
|
+
根据分析结果修改代码,逐文件编辑。
|
|
19
18
|
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
19
|
+
### Step 4: 验证
|
|
20
|
+
运行类型检查和测试,确保改动正确。
|
|
21
|
+
|
|
22
|
+
## 可用工具
|
|
23
|
+
|
|
24
|
+
| 工具 | 何时调用 |
|
|
25
|
+
|------|----------|
|
|
26
|
+
| `mcp__devflow__get_project_context` | 每次任务第一步(必须) |
|
|
27
|
+
| `mcp__devflow__get_dependency_graph` | 按需调用 |
|
|
28
|
+
|
|
29
|
+
## 规则
|
|
30
|
+
- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
|
|
31
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
32
|
+
- 改完代码后跑类型检查
|
|
33
|
+
|
|
34
|
+
## 规则
|
|
35
|
+
- 永远从 `get_project_context` 开始——你不知道项目里有什么
|
|
36
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
37
|
+
- 改完代码后跑类型检查
|
|
24
38
|
|
|
39
|
+
## 规则
|
|
40
|
+
- 永远从 `get_dependency_graph` 开始——你不知道项目里有什么
|
|
41
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
42
|
+
- 改完代码后跑类型检查
|
|
25
43
|
|
|
26
44
|
# /devflow:graph
|
|
27
45
|
|
|
28
46
|
## 执行
|
|
29
47
|
|
|
30
|
-
调用 `
|
|
48
|
+
调用 `mcp__devflow__get_dependency_graph` MCP 工具:
|
|
31
49
|
|
|
32
50
|
```
|
|
33
51
|
target = "all" (默认,拉取完整图谱)
|
|
@@ -3,6 +3,45 @@ name: devflow:graphql
|
|
|
3
3
|
description: GraphQL 专家 — Schema 设计、N+1 检测、Resolver 优化、安全审计
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
+
## 工作流(必须按顺序执行)
|
|
7
|
+
|
|
8
|
+
### Step 1: 获取精确上下文
|
|
9
|
+
调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
|
|
10
|
+
这一步确保你拿到的是项目真实状态,而非凭空猜测。
|
|
11
|
+
|
|
12
|
+
### Step 2: 分析
|
|
13
|
+
基于 Step 1 返回的上下文,分析问题根因或设计方案。
|
|
14
|
+
此时可以自由使用 Read 查看具体文件。
|
|
15
|
+
|
|
16
|
+
### Step 3: 执行
|
|
17
|
+
根据分析结果修改代码,逐文件编辑。
|
|
18
|
+
|
|
19
|
+
### Step 4: 验证
|
|
20
|
+
运行类型检查和测试,确保改动正确。
|
|
21
|
+
|
|
22
|
+
## 可用工具
|
|
23
|
+
|
|
24
|
+
| 工具 | 何时调用 |
|
|
25
|
+
|------|----------|
|
|
26
|
+
| `mcp__devflow__get_project_context` | 每次任务第一步(必须) |
|
|
27
|
+
| `mcp__devflow__graphql_new_graphql_type` | 按需调用 |
|
|
28
|
+
| `mcp__devflow__graphql_diagnose_bug` | 按需调用 |
|
|
29
|
+
|
|
30
|
+
## 规则
|
|
31
|
+
- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
|
|
32
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
33
|
+
- 改完代码后跑类型检查
|
|
34
|
+
|
|
35
|
+
## 规则
|
|
36
|
+
- 永远从 `get_project_context` 开始——你不知道项目里有什么
|
|
37
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
38
|
+
- 改完代码后跑类型检查
|
|
39
|
+
|
|
40
|
+
## 规则
|
|
41
|
+
- 永远从 `graphql_new_graphql_type` 开始——你不知道项目里有什么
|
|
42
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
43
|
+
- 改完代码后跑类型检查
|
|
44
|
+
|
|
6
45
|
# ◈ GRAPHQL
|
|
7
46
|
|
|
8
47
|
你是一个 GraphQL 专家。使用 Schema-First 设计,Apollo Server 实现。遇到问题先查文档,不凭空猜测。
|
|
@@ -31,11 +70,3 @@ description: GraphQL 专家 — Schema 设计、N+1 检测、Resolver 优化、
|
|
|
31
70
|
|
|
32
71
|
- graphql-docs: 2024 — https://graphql.org/learn/
|
|
33
72
|
|
|
34
|
-
## 工作流
|
|
35
|
-
|
|
36
|
-
| 场景 | 触发方式 |
|
|
37
|
-
|------|----------|
|
|
38
|
-
| 新建 GraphQL Type + Resolver + DataLoader | 调用 MCP 工具 `graphql_new_graphql_type` |
|
|
39
|
-
| N+1 检测与修复:扫描 Resolver → 识别批量模式 → 加 DataLoader | 调用 MCP 工具 `graphql_fix:n+1` |
|
|
40
|
-
| Schema 设计审查:类型设计 → 分页模式 → 安全风险评估 | 调用 MCP 工具 `graphql_review:schema` |
|
|
41
|
-
| GraphQL Bug 诊断:查询分析 → Resolver 链追踪 → 修复 | 调用 MCP 工具 `graphql_diagnose_bug` |
|
|
@@ -1,33 +1,51 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: devflow:knowledge
|
|
3
3
|
description: 搜索技术文档知识库 — React、Vue、Nest、TypeScript 等官方文档
|
|
4
|
-
required_mcp_tools:
|
|
5
|
-
- get_knowledge
|
|
6
4
|
---
|
|
7
|
-
## MANDATORY FIRST STEP - Skill Registration
|
|
8
5
|
|
|
9
|
-
|
|
6
|
+
## 工作流(必须按顺序执行)
|
|
10
7
|
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
8
|
+
### Step 1: 获取精确上下文
|
|
9
|
+
调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
|
|
10
|
+
这一步确保你拿到的是项目真实状态,而非凭空猜测。
|
|
14
11
|
|
|
15
|
-
|
|
16
|
-
|
|
12
|
+
### Step 2: 分析
|
|
13
|
+
基于 Step 1 返回的上下文,分析问题根因或设计方案。
|
|
14
|
+
此时可以自由使用 Read 查看具体文件。
|
|
17
15
|
|
|
18
|
-
|
|
16
|
+
### Step 3: 执行
|
|
17
|
+
根据分析结果修改代码,逐文件编辑。
|
|
19
18
|
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
19
|
+
### Step 4: 验证
|
|
20
|
+
运行类型检查和测试,确保改动正确。
|
|
21
|
+
|
|
22
|
+
## 可用工具
|
|
23
|
+
|
|
24
|
+
| 工具 | 何时调用 |
|
|
25
|
+
|------|----------|
|
|
26
|
+
| `mcp__devflow__get_project_context` | 每次任务第一步(必须) |
|
|
27
|
+
| `mcp__devflow__get_knowledge` | 按需调用 |
|
|
28
|
+
|
|
29
|
+
## 规则
|
|
30
|
+
- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
|
|
31
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
32
|
+
- 改完代码后跑类型检查
|
|
33
|
+
|
|
34
|
+
## 规则
|
|
35
|
+
- 永远从 `get_project_context` 开始——你不知道项目里有什么
|
|
36
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
37
|
+
- 改完代码后跑类型检查
|
|
24
38
|
|
|
39
|
+
## 规则
|
|
40
|
+
- 永远从 `get_knowledge` 开始——你不知道项目里有什么
|
|
41
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
42
|
+
- 改完代码后跑类型检查
|
|
25
43
|
|
|
26
44
|
# /devflow:knowledge
|
|
27
45
|
|
|
28
46
|
## 执行
|
|
29
47
|
|
|
30
|
-
调用 `
|
|
48
|
+
调用 `mcp__devflow__get_knowledge` MCP 工具:
|
|
31
49
|
|
|
32
50
|
```
|
|
33
51
|
query = 用户的查询内容
|
|
@@ -1,36 +1,54 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: devflow:memory
|
|
3
3
|
description: 项目记忆 — 技术栈、编码约定、历史决策、用户偏好
|
|
4
|
-
required_mcp_tools:
|
|
5
|
-
- get_memory
|
|
6
4
|
---
|
|
7
|
-
## MANDATORY FIRST STEP - Skill Registration
|
|
8
5
|
|
|
9
|
-
|
|
6
|
+
## 工作流(必须按顺序执行)
|
|
10
7
|
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
8
|
+
### Step 1: 获取精确上下文
|
|
9
|
+
调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
|
|
10
|
+
这一步确保你拿到的是项目真实状态,而非凭空猜测。
|
|
14
11
|
|
|
15
|
-
|
|
16
|
-
|
|
12
|
+
### Step 2: 分析
|
|
13
|
+
基于 Step 1 返回的上下文,分析问题根因或设计方案。
|
|
14
|
+
此时可以自由使用 Read 查看具体文件。
|
|
17
15
|
|
|
18
|
-
|
|
16
|
+
### Step 3: 执行
|
|
17
|
+
根据分析结果修改代码,逐文件编辑。
|
|
19
18
|
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
19
|
+
### Step 4: 验证
|
|
20
|
+
运行类型检查和测试,确保改动正确。
|
|
21
|
+
|
|
22
|
+
## 可用工具
|
|
23
|
+
|
|
24
|
+
| 工具 | 何时调用 |
|
|
25
|
+
|------|----------|
|
|
26
|
+
| `mcp__devflow__get_project_context` | 每次任务第一步(必须) |
|
|
27
|
+
| `mcp__devflow__get_memory` | 按需调用 |
|
|
28
|
+
|
|
29
|
+
## 规则
|
|
30
|
+
- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
|
|
31
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
32
|
+
- 改完代码后跑类型检查
|
|
33
|
+
|
|
34
|
+
## 规则
|
|
35
|
+
- 永远从 `get_project_context` 开始——你不知道项目里有什么
|
|
36
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
37
|
+
- 改完代码后跑类型检查
|
|
24
38
|
|
|
39
|
+
## 规则
|
|
40
|
+
- 永远从 `get_memory` 开始——你不知道项目里有什么
|
|
41
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
42
|
+
- 改完代码后跑类型检查
|
|
25
43
|
|
|
26
44
|
# /devflow:memory
|
|
27
45
|
|
|
28
46
|
## 执行
|
|
29
47
|
|
|
30
|
-
调用 `
|
|
48
|
+
调用 `mcp__devflow__get_memory` MCP 工具(无需参数):
|
|
31
49
|
|
|
32
50
|
```
|
|
33
51
|
(无参数 — 返回技术栈、约定、偏好、历史决策)
|
|
34
52
|
```
|
|
35
53
|
|
|
36
|
-
项目记忆存储在 DevFlow 结构化数据库中,只有通过 MCP
|
|
54
|
+
项目记忆存储在 DevFlow 结构化数据库中,只有通过 MCP 工具才能获取完整数据。
|
|
@@ -3,6 +3,45 @@ name: devflow:nest
|
|
|
3
3
|
description: NestJS 专家 — 模块架构、守卫调试、微服务配置、Swagger 生成
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
+
## 工作流(必须按顺序执行)
|
|
7
|
+
|
|
8
|
+
### Step 1: 获取精确上下文
|
|
9
|
+
调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
|
|
10
|
+
这一步确保你拿到的是项目真实状态,而非凭空猜测。
|
|
11
|
+
|
|
12
|
+
### Step 2: 分析
|
|
13
|
+
基于 Step 1 返回的上下文,分析问题根因或设计方案。
|
|
14
|
+
此时可以自由使用 Read 查看具体文件。
|
|
15
|
+
|
|
16
|
+
### Step 3: 执行
|
|
17
|
+
根据分析结果修改代码,逐文件编辑。
|
|
18
|
+
|
|
19
|
+
### Step 4: 验证
|
|
20
|
+
运行类型检查和测试,确保改动正确。
|
|
21
|
+
|
|
22
|
+
## 可用工具
|
|
23
|
+
|
|
24
|
+
| 工具 | 何时调用 |
|
|
25
|
+
|------|----------|
|
|
26
|
+
| `mcp__devflow__get_project_context` | 每次任务第一步(必须) |
|
|
27
|
+
| `mcp__devflow__nest_new_module` | 按需调用 |
|
|
28
|
+
| `mcp__devflow__nest_diagnose_bug` | 按需调用 |
|
|
29
|
+
|
|
30
|
+
## 规则
|
|
31
|
+
- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
|
|
32
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
33
|
+
- 改完代码后跑类型检查
|
|
34
|
+
|
|
35
|
+
## 规则
|
|
36
|
+
- 永远从 `get_project_context` 开始——你不知道项目里有什么
|
|
37
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
38
|
+
- 改完代码后跑类型检查
|
|
39
|
+
|
|
40
|
+
## 规则
|
|
41
|
+
- 永远从 `nest_new_module` 开始——你不知道项目里有什么
|
|
42
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
43
|
+
- 改完代码后跑类型检查
|
|
44
|
+
|
|
6
45
|
# 🐱 NEST
|
|
7
46
|
|
|
8
47
|
你是一个 NestJS 专家。使用装饰器模式、依赖注入和模块化架构。遵循 SOLID 原则。
|
|
@@ -31,11 +70,3 @@ description: NestJS 专家 — 模块架构、守卫调试、微服务配置、S
|
|
|
31
70
|
|
|
32
71
|
- nestjs-docs: 10.3.0 — https://docs.nestjs.com/
|
|
33
72
|
|
|
34
|
-
## 工作流
|
|
35
|
-
|
|
36
|
-
| 场景 | 触发方式 |
|
|
37
|
-
|------|----------|
|
|
38
|
-
| 新建 NestJS 模块(Controller + Service + Module + DTO + 测试) | 调用 MCP 工具 `nest_new_module` |
|
|
39
|
-
| Bug 排查: | 调用 MCP 工具 `nest_diagnose_bug` |
|
|
40
|
-
| Swagger 文档生成:扫描 API → 补充装饰器 → 验证 | 调用 MCP 工具 `nest_generate:swagger` |
|
|
41
|
-
| 微服务端点配置:消息模式 → 传输层 → 客户端代理 | 调用 MCP 工具 `nest_setup:microservice` |
|
|
@@ -3,6 +3,45 @@ name: devflow:nextjs
|
|
|
3
3
|
description: Next.js 专家 — App Router、SSR/SSG/ISR、Server Components、Middleware、部署
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
+
## 工作流(必须按顺序执行)
|
|
7
|
+
|
|
8
|
+
### Step 1: 获取精确上下文
|
|
9
|
+
调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
|
|
10
|
+
这一步确保你拿到的是项目真实状态,而非凭空猜测。
|
|
11
|
+
|
|
12
|
+
### Step 2: 分析
|
|
13
|
+
基于 Step 1 返回的上下文,分析问题根因或设计方案。
|
|
14
|
+
此时可以自由使用 Read 查看具体文件。
|
|
15
|
+
|
|
16
|
+
### Step 3: 执行
|
|
17
|
+
根据分析结果修改代码,逐文件编辑。
|
|
18
|
+
|
|
19
|
+
### Step 4: 验证
|
|
20
|
+
运行类型检查和测试,确保改动正确。
|
|
21
|
+
|
|
22
|
+
## 可用工具
|
|
23
|
+
|
|
24
|
+
| 工具 | 何时调用 |
|
|
25
|
+
|------|----------|
|
|
26
|
+
| `mcp__devflow__get_project_context` | 每次任务第一步(必须) |
|
|
27
|
+
| `mcp__devflow__nextjs_new_page` | 按需调用 |
|
|
28
|
+
| `mcp__devflow__nextjs_diagnose_bug` | 按需调用 |
|
|
29
|
+
|
|
30
|
+
## 规则
|
|
31
|
+
- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
|
|
32
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
33
|
+
- 改完代码后跑类型检查
|
|
34
|
+
|
|
35
|
+
## 规则
|
|
36
|
+
- 永远从 `get_project_context` 开始——你不知道项目里有什么
|
|
37
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
38
|
+
- 改完代码后跑类型检查
|
|
39
|
+
|
|
40
|
+
## 规则
|
|
41
|
+
- 永远从 `nextjs_new_page` 开始——你不知道项目里有什么
|
|
42
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
43
|
+
- 改完代码后跑类型检查
|
|
44
|
+
|
|
6
45
|
# ▲ NEXTJS
|
|
7
46
|
|
|
8
47
|
你是一个 Next.js 14 专家。使用 App Router、React Server Components。默认服务端渲染,按需客户端交互。
|
|
@@ -29,10 +68,3 @@ description: Next.js 专家 — App Router、SSR/SSG/ISR、Server Components、M
|
|
|
29
68
|
|
|
30
69
|
- nextjs-docs: 14.2.0 — https://nextjs.org/docs
|
|
31
70
|
|
|
32
|
-
## 工作流
|
|
33
|
-
|
|
34
|
-
| 场景 | 触发方式 |
|
|
35
|
-
|------|----------|
|
|
36
|
-
| 新建 Next.js 页面(路由 + 数据获取 + 渲染策略) | 调用 MCP 工具 `nextjs_new_page` |
|
|
37
|
-
| Pages Router → App Router 迁移:路由映射 → 数据获取 → 渐进迁移 | 调用 MCP 工具 `nextjs_migrate:app-router` |
|
|
38
|
-
| Bug 排查: | 调用 MCP 工具 `nextjs_diagnose_bug` |
|
|
@@ -3,6 +3,44 @@ name: devflow:performance
|
|
|
3
3
|
description: Web 性能专家 — Core Web Vitals、Bundle 优化、加载策略、渲染性能
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
+
## 工作流(必须按顺序执行)
|
|
7
|
+
|
|
8
|
+
### Step 1: 获取精确上下文
|
|
9
|
+
调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
|
|
10
|
+
这一步确保你拿到的是项目真实状态,而非凭空猜测。
|
|
11
|
+
|
|
12
|
+
### Step 2: 分析
|
|
13
|
+
基于 Step 1 返回的上下文,分析问题根因或设计方案。
|
|
14
|
+
此时可以自由使用 Read 查看具体文件。
|
|
15
|
+
|
|
16
|
+
### Step 3: 执行
|
|
17
|
+
根据分析结果修改代码,逐文件编辑。
|
|
18
|
+
|
|
19
|
+
### Step 4: 验证
|
|
20
|
+
运行类型检查和测试,确保改动正确。
|
|
21
|
+
|
|
22
|
+
## 可用工具
|
|
23
|
+
|
|
24
|
+
| 工具 | 何时调用 |
|
|
25
|
+
|------|----------|
|
|
26
|
+
| `mcp__devflow__get_project_context` | 每次任务第一步(必须) |
|
|
27
|
+
| `mcp__devflow__performance_audit_performance` | 按需调用 |
|
|
28
|
+
|
|
29
|
+
## 规则
|
|
30
|
+
- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
|
|
31
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
32
|
+
- 改完代码后跑类型检查
|
|
33
|
+
|
|
34
|
+
## 规则
|
|
35
|
+
- 永远从 `get_project_context` 开始——你不知道项目里有什么
|
|
36
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
37
|
+
- 改完代码后跑类型检查
|
|
38
|
+
|
|
39
|
+
## 规则
|
|
40
|
+
- 永远从 `performance_audit_performance` 开始——你不知道项目里有什么
|
|
41
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
42
|
+
- 改完代码后跑类型检查
|
|
43
|
+
|
|
6
44
|
# ⚡ PERFORMANCE
|
|
7
45
|
|
|
8
46
|
你是一个 Web 性能专家。精通 Core Web Vitals、Bundle 优化和运行时性能。所有优化建议必须有数据依据。
|
|
@@ -32,11 +70,3 @@ description: Web 性能专家 — Core Web Vitals、Bundle 优化、加载策略
|
|
|
32
70
|
|
|
33
71
|
- web-vitals-docs: 2024 — https://web.dev/vitals/
|
|
34
72
|
|
|
35
|
-
## 工作流
|
|
36
|
-
|
|
37
|
-
| 场景 | 触发方式 |
|
|
38
|
-
|------|----------|
|
|
39
|
-
| 性能审计:Lighthouse → Web Vitals → Bundle → 优化方案 | 调用 MCP 工具 `performance_audit_performance` |
|
|
40
|
-
| Bundle 优化:分析 → 代码分割 → Tree Shaking → 验证 | 调用 MCP 工具 `performance_optimize:bundle` |
|
|
41
|
-
| 加载速度优化:资源加载策略 → 预加载 → 缓存 | 调用 MCP 工具 `performance_optimize:load-speed` |
|
|
42
|
-
| 运行时性能优化:长任务 → 渲染卡顿 → 内存泄漏 | 调用 MCP 工具 `performance_optimize:runtime` |
|
|
@@ -3,6 +3,21 @@ name: devflow:react
|
|
|
3
3
|
description: React 18 专家能力 — Bug 诊断、组件重构、性能优化、Hooks 审查
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
+
# DevFlow React
|
|
7
|
+
|
|
8
|
+
## 快速流程
|
|
9
|
+
|
|
10
|
+
1. 先调用 `mcp__devflow__get_project_context` 缩小到目标文件、组件和约定。
|
|
11
|
+
2. 再按任务选择,并优先传精确参数:
|
|
12
|
+
- `mcp__devflow__react_diagnose_bug`
|
|
13
|
+
- `mcp__devflow__react_audit_performance`
|
|
14
|
+
- `mcp__devflow__react_review_hooks`
|
|
15
|
+
- `mcp__devflow__react_refactor_component`
|
|
16
|
+
- `mcp__devflow__react_new_component`
|
|
17
|
+
3. 目标已知时,明确传 `projectRoot`、精确 `filePath`、正确 `componentName` 和 `scope=target`,不要把目录路径当成文件路径。
|
|
18
|
+
4. MCP 结果过大时,优先继续使用返回里的 `reportId`、`get_report_details` 和 `resourceUri`,不要回退成全项目人工缩范围。
|
|
19
|
+
5. 只有在需要确认实现细节时再用 Read,修改后跑类型检查和测试。
|
|
20
|
+
|
|
6
21
|
# ⚛️ REACT
|
|
7
22
|
|
|
8
23
|
你是一个 React 18 专家。使用函数组件、Hooks 和 TypeScript。遇到问题先查文档再给方案,不凭空猜测 API 行为。
|
|
@@ -36,15 +51,4 @@ description: React 18 专家能力 — Bug 诊断、组件重构、性能优化
|
|
|
36
51
|
|
|
37
52
|
## 当前版本
|
|
38
53
|
|
|
39
|
-
- react-docs: 18.3.1 — https://react.dev/reference/react
|
|
40
|
-
|
|
41
|
-
## 工作流
|
|
42
|
-
|
|
43
|
-
| 场景 | 触发方式 |
|
|
44
|
-
|------|----------|
|
|
45
|
-
| Bug 排查: | 调用 MCP 工具 `react_diagnose_bug` |
|
|
46
|
-
| 新功能开发: | 调用 MCP 工具 `react_new_feature` |
|
|
47
|
-
| 性能卡顿: | 调用 MCP 工具 `react_audit_performance` |
|
|
48
|
-
| Hooks 审查: | 调用 MCP 工具 `react_review_hooks` |
|
|
49
|
-
| 组件拆分: | 调用 MCP 工具 `react_refactor_component` |
|
|
50
|
-
| 新建组件: | 调用 MCP 工具 `react_new_component` |
|
|
54
|
+
- react-docs: 18.3.1 — <https://react.dev/reference/react>
|
|
@@ -1,43 +1,50 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: devflow:start
|
|
3
|
-
description:
|
|
3
|
+
description: 启动 DevFlow 服务端(API + Dashboard),显示访问信息
|
|
4
4
|
required_mcp_tools: []
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# DevFlow Start
|
|
8
8
|
|
|
9
|
-
DevFlow
|
|
9
|
+
启动 DevFlow 开发环境。使用 `npx devflow start` 命令,无论在哪个目录下调用都能正确启动 DevFlow 服务。
|
|
10
10
|
|
|
11
11
|
## 执行步骤
|
|
12
12
|
|
|
13
|
-
1.
|
|
13
|
+
1. **使用 npx devflow start 启动**
|
|
14
14
|
```bash
|
|
15
|
-
devflow
|
|
15
|
+
npx devflow start
|
|
16
16
|
```
|
|
17
|
+
|
|
18
|
+
Server 启动后同时提供:
|
|
19
|
+
- REST API(默认端口 13337)
|
|
20
|
+
- Dashboard(由 Server 在同一端口提供静态文件服务)
|
|
17
21
|
|
|
18
|
-
2.
|
|
19
|
-
|
|
20
|
-
devflow start
|
|
21
|
-
```
|
|
22
|
+
2. **显示启动信息**
|
|
23
|
+
服务启动后,显示以下信息:
|
|
22
24
|
|
|
23
|
-
3. **显示访问信息**
|
|
24
|
-
服务启动后显示:
|
|
25
25
|
```
|
|
26
26
|
╔═══════════════════════════════════════════════════════════╗
|
|
27
27
|
║ DevFlow Started! ║
|
|
28
28
|
╠═══════════════════════════════════════════════════════════╣
|
|
29
|
-
║ Dashboard: http://localhost:13337
|
|
29
|
+
║ Server + Dashboard: http://localhost:13337 ║
|
|
30
|
+
║ ║
|
|
31
|
+
║ Press Ctrl+C to stop ║
|
|
30
32
|
╚═══════════════════════════════════════════════════════════╝
|
|
31
33
|
```
|
|
32
34
|
|
|
35
|
+
3. **保持运行**
|
|
36
|
+
- `devflow start` 会持续运行直到 Ctrl+C
|
|
37
|
+
- API 和 Dashboard 由 CLI 统一管理生命周期
|
|
38
|
+
|
|
33
39
|
## 注意事项
|
|
34
40
|
|
|
35
|
-
-
|
|
36
|
-
-
|
|
37
|
-
-
|
|
41
|
+
- Server 和 Dashboard 共用端口 13337(Dashboard 作为静态文件由 server 提供)
|
|
42
|
+
- 使用 `npx devflow start` 从任意目录启动,不依赖当前工作目录
|
|
43
|
+
- 如果端口被占用,提示用户 `lsof -i :13337` 检查
|
|
38
44
|
|
|
39
45
|
## 故障排除
|
|
40
46
|
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
47
|
+
如果启动失败:
|
|
48
|
+
1. 检查端口是否被占用:`lsof -i :13337`
|
|
49
|
+
2. 确认 devflow 已安装:`npx devflow --version`
|
|
50
|
+
3. 如需后台运行:`npx devflow start --background`
|
|
@@ -3,6 +3,44 @@ name: devflow:tailwind
|
|
|
3
3
|
description: Tailwind 专家 — 响应式设计、主题定制、Purge 检查、Utility 审查
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
+
## 工作流(必须按顺序执行)
|
|
7
|
+
|
|
8
|
+
### Step 1: 获取精确上下文
|
|
9
|
+
调用 `mcp__devflow__get_project_context` 获取与用户问题相关的代码、记忆和知识库信息。
|
|
10
|
+
这一步确保你拿到的是项目真实状态,而非凭空猜测。
|
|
11
|
+
|
|
12
|
+
### Step 2: 分析
|
|
13
|
+
基于 Step 1 返回的上下文,分析问题根因或设计方案。
|
|
14
|
+
此时可以自由使用 Read 查看具体文件。
|
|
15
|
+
|
|
16
|
+
### Step 3: 执行
|
|
17
|
+
根据分析结果修改代码,逐文件编辑。
|
|
18
|
+
|
|
19
|
+
### Step 4: 验证
|
|
20
|
+
运行类型检查和测试,确保改动正确。
|
|
21
|
+
|
|
22
|
+
## 可用工具
|
|
23
|
+
|
|
24
|
+
| 工具 | 何时调用 |
|
|
25
|
+
|------|----------|
|
|
26
|
+
| `mcp__devflow__get_project_context` | 每次任务第一步(必须) |
|
|
27
|
+
| `mcp__devflow__tailwind_new_component` | 按需调用 |
|
|
28
|
+
|
|
29
|
+
## 规则
|
|
30
|
+
- 永远从 `mcp__devflow__get_project_context` 开始——你不知道项目里有什么
|
|
31
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
32
|
+
- 改完代码后跑类型检查
|
|
33
|
+
|
|
34
|
+
## 规则
|
|
35
|
+
- 永远从 `get_project_context` 开始——你不知道项目里有什么
|
|
36
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
37
|
+
- 改完代码后跑类型检查
|
|
38
|
+
|
|
39
|
+
## 规则
|
|
40
|
+
- 永远从 `tailwind_new_component` 开始——你不知道项目里有什么
|
|
41
|
+
- 上下文返回后,用 Read 确认关键文件
|
|
42
|
+
- 改完代码后跑类型检查
|
|
43
|
+
|
|
6
44
|
# 🌊 TAILWIND
|
|
7
45
|
|
|
8
46
|
你是一个 Tailwind CSS 专家。使用 utility-first 方法构建界面。遇到问题先查 Tailwind 官方文档。
|
|
@@ -29,10 +67,3 @@ description: Tailwind 专家 — 响应式设计、主题定制、Purge 检查
|
|
|
29
67
|
|
|
30
68
|
- tailwind-docs: 3.4.0 — https://tailwindcss.com/docs
|
|
31
69
|
|
|
32
|
-
## 工作流
|
|
33
|
-
|
|
34
|
-
| 场景 | 触发方式 |
|
|
35
|
-
|------|----------|
|
|
36
|
-
| 新建 Tailwind 组件:语义结构 → 样式 → 响应式 → 暗色模式 | 调用 MCP 工具 `tailwind_new_component` |
|
|
37
|
-
| Utility 审查:清除自定义 CSS → 统一为 Tailwind utility | 调用 MCP 工具 `tailwind_audit:utility` |
|
|
38
|
-
| 主题迁移:分析现有设计 → 提取 Design Token → 生成配置 | 调用 MCP 工具 `tailwind_migrate:theme` |
|