jarvis-agent-factory 3.46.3 → 3.47.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/README.md
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
# Jarvis Agent Factory · 贾维斯智能体工厂
|
|
2
2
|
|
|
3
3
|
[](./LICENSE)
|
|
4
|
-
[](https://github.com/Wjl1224734792/Jarvis-Agent-Factory/releases)
|
|
5
5
|
[](https://www.npmjs.com/package/jarvis-agent-factory)
|
|
6
6
|
[](https://github.com/Wjl1224734792/visual-primitives-mcp)
|
|
7
7
|
<br>💡 **纯文本模型（如 DeepSeek）主力用户** → 搭配 [Visual Primitives MCP](https://github.com/Wjl1224734792/visual-primitives-mcp) 获得视觉理解能力
|
package/dist/package.json
CHANGED
|
@@ -0,0 +1,240 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: 一键发布——质量门检查→测试→版本bump→commit→push→tag→PR→merge→release
|
|
3
|
+
argument-hint: [版本类型：patch|minor|major，默认patch]
|
|
4
|
+
version: "3.46.3"
|
|
5
|
+
updated: "2026-05-14"
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# 一键发布
|
|
9
|
+
|
|
10
|
+
立即执行以下初始化步骤：
|
|
11
|
+
|
|
12
|
+
## 步骤 0：加载技能 + 前置检查
|
|
13
|
+
|
|
14
|
+
```
|
|
15
|
+
Skill("code-quality-gate")
|
|
16
|
+
Skill("git-workflow-and-versioning")
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
**前置检查（不可绕过）**：
|
|
20
|
+
|
|
21
|
+
1. 检查当前分支：
|
|
22
|
+
- 必须在 `dev` 分支上。若不在 `dev`，报告当前分支并提示用户先切换到 `dev`。
|
|
23
|
+
- ```bash
|
|
24
|
+
git branch --show-current
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
2. 检查工作区状态：
|
|
28
|
+
- 工作区必须干净（无未提交变更）。
|
|
29
|
+
- ```bash
|
|
30
|
+
git status --porcelain
|
|
31
|
+
```
|
|
32
|
+
- 若有未提交变更，列出变更文件并提示用户先处理（提交或暂存）。
|
|
33
|
+
|
|
34
|
+
**前置条件不满足 → 立即停止，向用户报告具体问题和处理建议。**
|
|
35
|
+
|
|
36
|
+
---
|
|
37
|
+
|
|
38
|
+
## 步骤 1：质量门（不可绕过）
|
|
39
|
+
|
|
40
|
+
加载 `Skill("code-quality-gate")` 后执行四项检查：
|
|
41
|
+
|
|
42
|
+
```
|
|
43
|
+
┌─────────────────────────────────────────────┐
|
|
44
|
+
│ 质量门检查（全部通过才继续） │
|
|
45
|
+
│ │
|
|
46
|
+
│ 1. Lint（eslint / ruff / golangci-lint） │
|
|
47
|
+
│ 2. Type-check（tsc --noEmit） │
|
|
48
|
+
│ 3. Build（npm run build） │
|
|
49
|
+
│ 4. Deps Audit（npm audit） │
|
|
50
|
+
└─────────────────────────────────────────────┘
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
**全部通过 → 进入步骤 2**
|
|
54
|
+
|
|
55
|
+
**任意项失败**：
|
|
56
|
+
1. 输出失败项的详细错误信息
|
|
57
|
+
2. **立即停止**，不继续后续步骤
|
|
58
|
+
3. 向用户报告：哪个检查失败、具体错误、修复建议
|
|
59
|
+
4. 用户修复后重新执行 `/publish` 从步骤 1 开始
|
|
60
|
+
|
|
61
|
+
---
|
|
62
|
+
|
|
63
|
+
## 步骤 2：测试（不可绕过）
|
|
64
|
+
|
|
65
|
+
运行测试套件：
|
|
66
|
+
|
|
67
|
+
```bash
|
|
68
|
+
npm test
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
**全部通过 → 进入步骤 3**
|
|
72
|
+
|
|
73
|
+
**测试失败**：
|
|
74
|
+
1. 输出失败的测试名称和错误详情
|
|
75
|
+
2. **立即停止**，不继续后续步骤
|
|
76
|
+
3. 向用户报告：失败测试数量、失败原因摘要
|
|
77
|
+
4. 用户修复后重新执行 `/publish` 从步骤 1 开始
|
|
78
|
+
|
|
79
|
+
---
|
|
80
|
+
|
|
81
|
+
## 步骤 3：版本递增
|
|
82
|
+
|
|
83
|
+
加载 `Skill("git-workflow-and-versioning")` 执行版本管理。
|
|
84
|
+
|
|
85
|
+
参数说明：
|
|
86
|
+
- 用户可指定版本类型：`patch`（默认）、`minor`、`major`
|
|
87
|
+
- 未指定则默认 `patch` 递增
|
|
88
|
+
|
|
89
|
+
1. 读取当前 `package.json` 中的 `version` 字段
|
|
90
|
+
2. 按指定类型递增版本号：
|
|
91
|
+
- `patch`：X.Y.Z → X.Y.(Z+1)
|
|
92
|
+
- `minor`：X.Y.Z → X.(Y+1).0
|
|
93
|
+
- `major`：X.Y.Z → (X+1).0.0
|
|
94
|
+
3. 更新 `package.json` 中的 `version` 字段为新版本号
|
|
95
|
+
4. 输出：`版本递增：v<旧版本> → v<新版本>（类型：<patch|minor|major>）`
|
|
96
|
+
|
|
97
|
+
---
|
|
98
|
+
|
|
99
|
+
## 步骤 4：提交并推送
|
|
100
|
+
|
|
101
|
+
```bash
|
|
102
|
+
git add package.json
|
|
103
|
+
git commit -m "chore: bump version to v<新版本>"
|
|
104
|
+
git push origin dev
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
推送失败时报告错误并停止。
|
|
108
|
+
|
|
109
|
+
---
|
|
110
|
+
|
|
111
|
+
## 步骤 5：创建并推送 tag
|
|
112
|
+
|
|
113
|
+
```bash
|
|
114
|
+
git tag -a v<新版本> -m "Release v<新版本>"
|
|
115
|
+
git push origin v<新版本>
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
> 推送 tag 会触发 CI/CD release workflow。
|
|
119
|
+
|
|
120
|
+
推送失败时报告错误并停止。
|
|
121
|
+
|
|
122
|
+
---
|
|
123
|
+
|
|
124
|
+
## 步骤 6：创建 PR（dev → main）
|
|
125
|
+
|
|
126
|
+
```bash
|
|
127
|
+
gh pr create \
|
|
128
|
+
--base main \
|
|
129
|
+
--head dev \
|
|
130
|
+
--title "Release v<新版本>" \
|
|
131
|
+
--body "## 发布内容
|
|
132
|
+
|
|
133
|
+
- 版本：v<新版本>
|
|
134
|
+
- 类型：<patch|minor|major>
|
|
135
|
+
|
|
136
|
+
## 检查清单
|
|
137
|
+
- [x] 质量门通过
|
|
138
|
+
- [x] 测试通过
|
|
139
|
+
- [x] 版本已递增
|
|
140
|
+
- [x] Tag 已创建并推送
|
|
141
|
+
|
|
142
|
+
Auto-generated by /publish command."
|
|
143
|
+
```
|
|
144
|
+
|
|
145
|
+
PR 创建失败时报告错误并停止。
|
|
146
|
+
|
|
147
|
+
---
|
|
148
|
+
|
|
149
|
+
## 步骤 7：合并 PR
|
|
150
|
+
|
|
151
|
+
```bash
|
|
152
|
+
gh pr merge --merge
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
使用 `--merge`（非 squash）保留完整提交历史。
|
|
156
|
+
|
|
157
|
+
合并失败（如存在冲突）时报告错误并停止，提示用户手动解决冲突后重试。
|
|
158
|
+
|
|
159
|
+
---
|
|
160
|
+
|
|
161
|
+
## 步骤 8：迁移 tag 到 main
|
|
162
|
+
|
|
163
|
+
版本 tag 应指向 `main` 分支的合并提交：
|
|
164
|
+
|
|
165
|
+
```bash
|
|
166
|
+
# 1. 获取最新 main
|
|
167
|
+
git fetch origin main
|
|
168
|
+
|
|
169
|
+
# 2. 删除 dev 上的本地 tag
|
|
170
|
+
git tag -d v<新版本>
|
|
171
|
+
|
|
172
|
+
# 3. 在 main 上重建同名 tag（指向 main 的最新提交）
|
|
173
|
+
git tag -a v<新版本> origin/main -m "Release v<新版本>"
|
|
174
|
+
|
|
175
|
+
# 4. 强制推送 tag 到远程（覆盖 dev 上的旧 tag 指向）
|
|
176
|
+
git push origin v<新版本> --force
|
|
177
|
+
```
|
|
178
|
+
|
|
179
|
+
> 此步骤确保 tag 指向 `main` 分支而非 `dev` 分支，便于后续追溯和历史记录准确性。
|
|
180
|
+
|
|
181
|
+
失败时报告错误并停止。
|
|
182
|
+
|
|
183
|
+
---
|
|
184
|
+
|
|
185
|
+
## 步骤 9：切回 dev 并报告结果
|
|
186
|
+
|
|
187
|
+
```bash
|
|
188
|
+
git checkout dev
|
|
189
|
+
```
|
|
190
|
+
|
|
191
|
+
输出发布完成报告：
|
|
192
|
+
|
|
193
|
+
```
|
|
194
|
+
## 发布完成报告
|
|
195
|
+
|
|
196
|
+
- 版本：v<旧版本> → v<新版本>
|
|
197
|
+
- 类型：<patch|minor|major>
|
|
198
|
+
- 质量门：✅ 通过
|
|
199
|
+
- 测试：✅ 通过
|
|
200
|
+
- Commit：<commit hash>
|
|
201
|
+
- Tag：v<新版本>（指向 main）
|
|
202
|
+
- PR：#<PR number>（已合并）
|
|
203
|
+
- 当前分支：dev
|
|
204
|
+
```
|
|
205
|
+
|
|
206
|
+
---
|
|
207
|
+
|
|
208
|
+
## 流程总览
|
|
209
|
+
|
|
210
|
+
```
|
|
211
|
+
步骤 0: 前置检查（dev 分支 + 工作区干净）
|
|
212
|
+
↓
|
|
213
|
+
步骤 1: 质量门（Lint + Type-check + Build + Audit）
|
|
214
|
+
↓ 全部通过
|
|
215
|
+
步骤 2: 测试（npm test）
|
|
216
|
+
↓ 全部通过
|
|
217
|
+
步骤 3: 版本递增（patch/minor/major）
|
|
218
|
+
↓
|
|
219
|
+
步骤 4: 提交并推送（commit package.json + push dev）
|
|
220
|
+
↓
|
|
221
|
+
步骤 5: 创建并推送 tag（触发 release workflow）
|
|
222
|
+
↓
|
|
223
|
+
步骤 6: 创建 PR（dev → main）
|
|
224
|
+
↓
|
|
225
|
+
步骤 7: 合并 PR
|
|
226
|
+
↓
|
|
227
|
+
步骤 8: 迁移 tag 到 main
|
|
228
|
+
↓
|
|
229
|
+
步骤 9: 切回 dev + 报告完成
|
|
230
|
+
```
|
|
231
|
+
|
|
232
|
+
## 红线
|
|
233
|
+
|
|
234
|
+
- 不在 `dev` 分支上发布（直接从其他分支发布会导致版本混乱）
|
|
235
|
+
- 工作区不干净时发布（未提交变更混入发布）
|
|
236
|
+
- 质量门失败仍继续（带问题的代码不能发布）
|
|
237
|
+
- 测试失败仍继续（回归未发现的发布是事故）
|
|
238
|
+
- 手动修改版本号而不使用版本递增流程（破坏版本号一致性）
|
|
239
|
+
- tag 留在 `dev` 分支上不移到 `main`（tag 应指向正式发布分支）
|
|
240
|
+
- 使用 `--squash` 合并 PR（丢失 dev 分支的提交历史细节）
|
|
@@ -0,0 +1,86 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: 同步项目文件——更新指令/技能/文档到最新版，清理过时缓存
|
|
3
|
+
argument-hint: [--dry-run 预览模式]
|
|
4
|
+
version: "3.46.3"
|
|
5
|
+
updated: "2026-05-14"
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# 同步项目文件
|
|
9
|
+
|
|
10
|
+
立即执行以下同步流程：
|
|
11
|
+
|
|
12
|
+
## 1. 同步指令
|
|
13
|
+
|
|
14
|
+
从模板 `src/templates/platforms/claude/commands/` 同步最新命令到 `.claude/commands/`：
|
|
15
|
+
|
|
16
|
+
- 扫描模板目录下所有 `.md` 文件
|
|
17
|
+
- 按文件名匹配目标目录，若模板比目标新则覆盖
|
|
18
|
+
- 目标目录不存在的文件直接创建
|
|
19
|
+
- 跳过 `jarvis-lite.md`、`jarvis.md` 等由引擎动态控制的命令文件（以引擎内置版本为准）
|
|
20
|
+
|
|
21
|
+
## 2. 同步技能
|
|
22
|
+
|
|
23
|
+
从模板 `src/templates/platforms/claude/skills/` 同步最新技能到 `.claude/skills/`：
|
|
24
|
+
|
|
25
|
+
- 扫描模板 `skills/` 下的子目录，每个子目录是一个技能
|
|
26
|
+
- 目标 `.claude/skills/` 不存在则创建
|
|
27
|
+
- 按目录比对，模板中的新增/更新技能同步到目标
|
|
28
|
+
|
|
29
|
+
## 3. 同步核心文档
|
|
30
|
+
|
|
31
|
+
更新以下核心文档，确保与代码变更一致：
|
|
32
|
+
|
|
33
|
+
- `CLAUDE.md` — 检查命令列表、路径引用、版本号是否与当前代码匹配
|
|
34
|
+
- `AGENTS.md` — 检查约束项、流程描述、技术栈是否反映最新架构
|
|
35
|
+
- `README.md` — 检查安装命令、使用方式、配置说明是否有效
|
|
36
|
+
- `CHANGELOG.md` — 检查最新版本条目是否包含所有近期变更
|
|
37
|
+
|
|
38
|
+
比较策略：读取文件内容，对比关键字段（命令名、路径、版本号、模块列表），发现不一致则报告并修复。
|
|
39
|
+
|
|
40
|
+
## 4. 清理过时文件
|
|
41
|
+
|
|
42
|
+
扫描 `.claude/` 目录下不再需要的缓存和临时文件：
|
|
43
|
+
|
|
44
|
+
- 检查 `.claude/commands/` 中存在但模板目录已删除的文件，标记为过时
|
|
45
|
+
- 检查 `.claude/skills/` 中存在但模板目录已删除的技能目录，标记为过时
|
|
46
|
+
- 扫描 `.claude/` 下的 `.cache`、`.tmp`、`*.log` 等临时文件并清理
|
|
47
|
+
|
|
48
|
+
### 跳过目录
|
|
49
|
+
|
|
50
|
+
以下目录不做任何同步或清理操作：
|
|
51
|
+
|
|
52
|
+
- `dist/` — 构建产物
|
|
53
|
+
- `docs/YYYY-MM-DD/` — 日期驱动文档
|
|
54
|
+
- `node_modules/` — 依赖
|
|
55
|
+
- `.git/` — 版本控制
|
|
56
|
+
|
|
57
|
+
## 同步策略
|
|
58
|
+
|
|
59
|
+
- **默认行为**：执行全部同步步骤（指令 + 技能 + 文档 + 清理）
|
|
60
|
+
- **--dry-run 模式**：仅预览变更，列出将新增/更新/删除的文件，不实际修改任何文件
|
|
61
|
+
- **增量同步**：仅更新有变化的文件，时间戳或内容比对后决定是否覆盖
|
|
62
|
+
- **保守删除**：清理步骤仅删除明确标记为过时的模板文件，不对未知文件做自动删除
|
|
63
|
+
|
|
64
|
+
## 同步报告
|
|
65
|
+
|
|
66
|
+
完成后输出结构化报告：
|
|
67
|
+
|
|
68
|
+
```
|
|
69
|
+
=== 同步报告 ===
|
|
70
|
+
|
|
71
|
+
【指令】新增: N 更新: N 删除: N 跳过: N
|
|
72
|
+
【技能】新增: N 更新: N 删除: N 跳过: N
|
|
73
|
+
【文档】已检查: CLAUDE.md AGENTS.md README.md CHANGELOG.md
|
|
74
|
+
- 更新项: xxx（描述不一致处及修复内容）
|
|
75
|
+
- 一致项: xxx（确认无需修改）
|
|
76
|
+
【清理】已清理: N 个文件/目录（列出路径）
|
|
77
|
+
|
|
78
|
+
总计变更: N 预览模式: 是/否
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
## 运行约束
|
|
82
|
+
|
|
83
|
+
- 所有文件操作使用绝对路径
|
|
84
|
+
- 文档对比需实际读取文件内容，禁止仅凭猜测判断
|
|
85
|
+
- 模板过时但目标文件存在新内容时不强制覆盖（以目标为准）
|
|
86
|
+
- `--dry-run` 模式下不执行任何写操作
|
package/package.json
CHANGED