name	f8x-version-update
description	批量检查和更新 f8x 中工具的版本号。当需要检查哪些工具有新版本、更新某个工具的版本、或批量更新版本时使用。即使用户只是说 "检查一下版本"、"xxx 更新了没"、"升级一下工具" 也应触发。

f8x 版本更新

f8x 中所有工具版本都硬编码在脚本顶部（行 93-435），每次上游发布新版本都需要手动更新。这个 skill 指导如何安全地完成版本更新。

检查流程

Step 1: 运行 check_releases.py

cd /Users/f0x/pte-project/infra-plat/f8x
python3 check_releases.py --file f8x --output diff.txt

脚本会扫描 f8x 中所有 # https://github.com/owner/repo 注释后面的 _Ver/_Version 变量，与 GitHub Releases API 对比，输出需要更新的工具列表。

输出格式：

owner/repo: v1.0.0 -> v2.0.0 (xxx_Ver) https://github.com/owner/repo/releases/tag/v2.0.0

环境变量：

GITHUB_TOKEN — 提高 API 速率限制（建议设置，否则 60 次/小时会很快用完）
HTTP_PROXY / HTTPS_PROXY — 代理（脚本默认使用 --proxy http://127.0.0.1:7890，可用 --proxy "" 禁用）

Step 2: 人工筛选

不要盲目更新所有有新版本的工具。 逐个检查 diff.txt 中的工具，确认：

新 release 是否包含预编译二进制？ 有些项目发布 release 但只打了 tag 没有 assets，或者只有源码包。如果没有二进制，跳过
文件名格式是否变了？ 对比新旧 release 的 asset 文件名，如果命名规则变了（比如 _amd64 → -amd64），安装函数也要同步改
是否有 breaking changes？ 看 release notes，如果 CLI 用法变了可能需要调整安装函数

用 GitHub API 快速拿到 release assets 列表（比打开网页更快更准）：

curl -s https://api.github.com/repos/OWNER/REPO/releases/latest | python3 -c "
import json,sys
d=json.load(sys.stdin)
print(f'Tag: {d[\"tag_name\"]}')
for a in d.get('assets',[]): print(f'  {a[\"name\"]}')"

如果 diff.txt 里有大量工具需要更新，逐个处理——每个工具走完 Step 2→3→4 的完整循环再开始下一个，不要一口气改完所有再验证，否则出错时很难定位是哪个工具改坏的。

Step 3: 逐个更新版本变量

确认要更新后，修改 f8x 脚本（行 93-435 区域）。

首先，用变量前缀搜索找出该工具的所有关联变量，确认要改几个：

grep "^httpx_" f8x       # 找出 httpx 的所有版本相关变量
grep "^frp_" f8x         # 找出 frp 的所有版本相关变量

这一步能避免"只改了 _Ver 忘了改 _bin_*"的常见错误。

简单情况：只有 `_Ver`

# 改前
xxx_Ver="v1.0.0"
# 改后
xxx_Ver="v2.0.0"

常见情况：`_Ver` + 关联文件名变量

这是最容易出错的地方。文件名变量里嵌入了版本号，必须全部同步修改：

# 改前
httpx_Ver="v1.8.1"
httpx_bin_amd64="httpx_1.8.1_linux_amd64.zip"
httpx_bin_arm64="httpx_1.8.1_linux_arm64.zip"

# 改后（注意 _Ver 带 v 前缀，文件名里不带 v）
httpx_Ver="v1.9.0"
httpx_bin_amd64="httpx_1.9.0_linux_amd64.zip"
httpx_bin_arm64="httpx_1.9.0_linux_arm64.zip"

复杂情况：`_Ver` + `_File_` + `_Dir_`

某些工具（如 frp）解压后目录名也包含版本号：

# 改前
frp_Ver="v0.67.0"
frp_File_amd64="frp_0.67.0_linux_amd64.tar.gz"
frp_File_arm64="frp_0.67.0_linux_arm64.tar.gz"
frp_Dir_amd64="frp_0.67.0_linux_amd64"
frp_Dir_arm64="frp_0.67.0_linux_arm64"

# 改后 — 4 个变量都要改
frp_Ver="v0.68.0"
frp_File_amd64="frp_0.68.0_linux_amd64.tar.gz"
frp_File_arm64="frp_0.68.0_linux_arm64.tar.gz"
frp_Dir_amd64="frp_0.68.0_linux_amd64"
frp_Dir_arm64="frp_0.68.0_linux_arm64"

Step 4: 验证

更新后做两件事：

语法检查：bash -n f8x
搜索残留旧版本号：用旧版本号 grep 一下，确认没有遗漏
```
grep "1.8.1" f8x  # 用旧版本号搜索，应该没有匹配
```

关联文件名变量的命名模式

f8x 中关联变量的后缀没有统一标准，以下是实际存在的几种：

后缀模式	示例	含义
`_bin_amd64` / `_bin_arm64`	`httpx_bin_amd64`	完整文件名（最常见）
`_File_amd64` / `_File_arm64`	`frp_File_amd64`, `chisel_File_amd64`	同上，另一种命名
`_Install_amd64`	`Nuclei_Install_amd64`	同上，早期命名
`_Dir_amd64` / `_Dir_arm64`	`frp_Dir_amd64`	解压后的目录名

更新某个工具时，先搜索该工具的变量前缀找出所有关联变量：

grep "^httpx_" f8x       # 找出 httpx 的所有版本相关变量
grep "^frp_" f8x         # 找出 frp 的所有版本相关变量

版本号格式注意事项

_Ver 变量通常带 v 前缀（v1.0.0），但文件名中一般不带（httpx_1.0.0_linux_amd64.zip）
少数工具的 _Ver 不带 v（如 Adinfo_Ver="v0.3" 但 release tag 是 v0.3）
通过 GitHub Releases 页面的 asset 文件名来确认准确格式，不要猜

常见陷阱

只改了 _Ver 忘了改 _bin_*：下载时 404，因为文件名里还是旧版本号
release 没有预编译文件：有些项目只打 tag 不发布 assets，或只有源码 tarball
pre-release 版本：check_releases.py 用的是 releases/latest API，不会返回 pre-release，但如果 fallback 到 tags 就可能拿到非稳定版
文件名格式变更：上游改了命名规则但没改功能，需要同步修改安装函数中的解压/移动逻辑
Arsenal 也用了版本变量：如果工具在 Arsenal 里有 case 块，检查是否也需要更新

关键文件

文件	作用
`/Users/f0x/pte-project/infra-plat/f8x/f8x`	主脚本，版本变量在行 93-435
`/Users/f0x/pte-project/infra-plat/f8x/check_releases.py`	版本检查脚本
`/Users/f0x/pte-project/infra-plat/f8x/f8x_version.sh`	版本覆盖（可选，用于测试）

name	f8x-version-update
description	批量检查和更新 f8x 中工具的版本号。当需要检查哪些工具有新版本、更新某个工具的版本、或批量更新版本时使用。即使用户只是说 "检查一下版本"、"xxx 更新了没"、"升级一下工具" 也应触发。

f8x 版本更新

f8x 中所有工具版本都硬编码在脚本顶部（行 93-435），每次上游发布新版本都需要手动更新。这个 skill 指导如何安全地完成版本更新。

检查流程

Step 1: 运行 check_releases.py

cd /Users/f0x/pte-project/infra-plat/f8x
python3 check_releases.py --file f8x --output diff.txt

脚本会扫描 f8x 中所有 # https://github.com/owner/repo 注释后面的 _Ver/_Version 变量，与 GitHub Releases API 对比，输出需要更新的工具列表。

输出格式：

owner/repo: v1.0.0 -> v2.0.0 (xxx_Ver) https://github.com/owner/repo/releases/tag/v2.0.0

环境变量：

GITHUB_TOKEN — 提高 API 速率限制（建议设置，否则 60 次/小时会很快用完）
HTTP_PROXY / HTTPS_PROXY — 代理（脚本默认使用 --proxy http://127.0.0.1:7890，可用 --proxy "" 禁用）

Step 2: 人工筛选

不要盲目更新所有有新版本的工具。 逐个检查 diff.txt 中的工具，确认：

新 release 是否包含预编译二进制？ 有些项目发布 release 但只打了 tag 没有 assets，或者只有源码包。如果没有二进制，跳过
文件名格式是否变了？ 对比新旧 release 的 asset 文件名，如果命名规则变了（比如 _amd64 → -amd64），安装函数也要同步改
是否有 breaking changes？ 看 release notes，如果 CLI 用法变了可能需要调整安装函数

用 GitHub API 快速拿到 release assets 列表（比打开网页更快更准）：

curl -s https://api.github.com/repos/OWNER/REPO/releases/latest | python3 -c "
import json,sys
d=json.load(sys.stdin)
print(f'Tag: {d[\"tag_name\"]}')
for a in d.get('assets',[]): print(f'  {a[\"name\"]}')"

Step 3: 逐个更新版本变量

确认要更新后，修改 f8x 脚本（行 93-435 区域）。

首先，用变量前缀搜索找出该工具的所有关联变量，确认要改几个：

grep "^httpx_" f8x       # 找出 httpx 的所有版本相关变量
grep "^frp_" f8x         # 找出 frp 的所有版本相关变量

这一步能避免"只改了 _Ver 忘了改 _bin_*"的常见错误。

简单情况：只有 `_Ver`

# 改前
xxx_Ver="v1.0.0"
# 改后
xxx_Ver="v2.0.0"

常见情况：`_Ver` + 关联文件名变量

这是最容易出错的地方。文件名变量里嵌入了版本号，必须全部同步修改：

# 改前
httpx_Ver="v1.8.1"
httpx_bin_amd64="httpx_1.8.1_linux_amd64.zip"
httpx_bin_arm64="httpx_1.8.1_linux_arm64.zip"

# 改后（注意 _Ver 带 v 前缀，文件名里不带 v）
httpx_Ver="v1.9.0"
httpx_bin_amd64="httpx_1.9.0_linux_amd64.zip"
httpx_bin_arm64="httpx_1.9.0_linux_arm64.zip"

复杂情况：`_Ver` + `_File_` + `_Dir_`

某些工具（如 frp）解压后目录名也包含版本号：

# 改前
frp_Ver="v0.67.0"
frp_File_amd64="frp_0.67.0_linux_amd64.tar.gz"
frp_File_arm64="frp_0.67.0_linux_arm64.tar.gz"
frp_Dir_amd64="frp_0.67.0_linux_amd64"
frp_Dir_arm64="frp_0.67.0_linux_arm64"

# 改后 — 4 个变量都要改
frp_Ver="v0.68.0"
frp_File_amd64="frp_0.68.0_linux_amd64.tar.gz"
frp_File_arm64="frp_0.68.0_linux_arm64.tar.gz"
frp_Dir_amd64="frp_0.68.0_linux_amd64"
frp_Dir_arm64="frp_0.68.0_linux_arm64"

Step 4: 验证

更新后做两件事：

语法检查：bash -n f8x
搜索残留旧版本号：用旧版本号 grep 一下，确认没有遗漏
```
grep "1.8.1" f8x  # 用旧版本号搜索，应该没有匹配
```

关联文件名变量的命名模式

f8x 中关联变量的后缀没有统一标准，以下是实际存在的几种：

后缀模式	示例	含义
`_bin_amd64` / `_bin_arm64`	`httpx_bin_amd64`	完整文件名（最常见）
`_File_amd64` / `_File_arm64`	`frp_File_amd64`, `chisel_File_amd64`	同上，另一种命名
`_Install_amd64`	`Nuclei_Install_amd64`	同上，早期命名
`_Dir_amd64` / `_Dir_arm64`	`frp_Dir_amd64`	解压后的目录名

更新某个工具时，先搜索该工具的变量前缀找出所有关联变量：

grep "^httpx_" f8x       # 找出 httpx 的所有版本相关变量
grep "^frp_" f8x         # 找出 frp 的所有版本相关变量

版本号格式注意事项

_Ver 变量通常带 v 前缀（v1.0.0），但文件名中一般不带（httpx_1.0.0_linux_amd64.zip）
少数工具的 _Ver 不带 v（如 Adinfo_Ver="v0.3" 但 release tag 是 v0.3）
通过 GitHub Releases 页面的 asset 文件名来确认准确格式，不要猜

常见陷阱

只改了 _Ver 忘了改 _bin_*：下载时 404，因为文件名里还是旧版本号
release 没有预编译文件：有些项目只打 tag 不发布 assets，或只有源码 tarball
pre-release 版本：check_releases.py 用的是 releases/latest API，不会返回 pre-release，但如果 fallback 到 tags 就可能拿到非稳定版
文件名格式变更：上游改了命名规则但没改功能，需要同步修改安装函数中的解压/移动逻辑
Arsenal 也用了版本变量：如果工具在 Arsenal 里有 case 块，检查是否也需要更新

关键文件

文件	作用
`/Users/f0x/pte-project/infra-plat/f8x/f8x`	主脚本，版本变量在行 93-435
`/Users/f0x/pte-project/infra-plat/f8x/check_releases.py`	版本检查脚本
`/Users/f0x/pte-project/infra-plat/f8x/f8x_version.sh`	版本覆盖（可选，用于测试）

f8x-version-update

f8x 版本更新

检查流程

Step 1: 运行 check_releases.py

Step 2: 人工筛选

Step 3: 逐个更新版本变量

简单情况：只有 _Ver

常见情况：_Ver + 关联文件名变量

复杂情况：_Ver + _File_* + _Dir_*

Step 4: 验证

关联文件名变量的命名模式

版本号格式注意事项

常见陷阱

关键文件

Mehr aus diesem Repository

Mehr aus diesem Repository

f8x 版本更新

检查流程

Step 1: 运行 check_releases.py

Step 2: 人工筛选

Step 3: 逐个更新版本变量

简单情况：只有 _Ver

常见情况：_Ver + 关联文件名变量

复杂情况：_Ver + _File_* + _Dir_*

Step 4: 验证

关联文件名变量的命名模式

版本号格式注意事项

常见陷阱

关键文件

简单情况：只有 `_Ver`

常见情况：`_Ver` + 关联文件名变量

复杂情况：`_Ver` + `_File_` + `_Dir_`

简单情况：只有 `_Ver`

常见情况：`_Ver` + 关联文件名变量

复杂情况：`_Ver` + `_File_` + `_Dir_`