@weotro/dx 0.1.0

package/skills/git-release/SKILL.md

@@ -0,0 +1,194 @@
+---
+name: git-release
+description: 仅在用户显式调用 $git-release 或明确要求使用 git-release 技能时使用；不要通过关键词、任务类型或上下文自动触发。
+---
+
+# Git Release
+
+## 目标
+
+在 `release/vX.Y.Z` 或 `release/vX.Y.Z-<prerelease>.N` 分支上，完成从发布前检查到 GitHub Release 创建的全流程；若当前不在 release 分支，则先从最新 `main` 自动创建目标 release 分支。
+
+## 执行原则
+
+- 全程使用中文输出。
+- 严格执行前置校验，任何硬性条件不满足时立即终止。
+- 发行说明必须结构化、可读、可追溯。
+- 命令默认在仓库根目录执行。
+- 若能从当前 release 分支或自动建分支流程唯一推断出合法版本号，直接使用该版本继续发布，不要询问用户确认。
+
+## 流程
+
+### 一、发布前检查
+
+1. 检查工作区是否干净：`git status --porcelain`。
+2. 若存在未提交变更，列出文件并终止流程。
+3. 检查当前分支：`git branch --show-current`。
+4. 若当前分支不匹配 `^release/v\d+\.\d+\.\d+(-(alpha|beta|rc)\.\d+)?$`，执行以下自动建分支流程（仅此场景执行）：
+- 同步远程与本地 `main`：`git fetch origin main --tags && git checkout main && git pull --ff-only origin main`。
+- 获取上一个已发布版本（优先）：`gh release list --limit 1 --json tagName,publishedAt --jq '.[0].tagName'`；若为空则回退 `git describe --tags --abbrev=0`。
+- 解析版本号并将最后一位加一（例如 `v1.2.3 -> v1.2.4`），得到新分支版本 `<NEXT_VERSION>`。
+- 创建并切换分支：`git checkout -b release/v<NEXT_VERSION>`。
+5. 再次检查当前分支，必须匹配：`^release/v\d+\.\d+\.\d+(-(alpha|beta|rc)\.\d+)?$`。
+6. 从分支名提取版本号，例如：
+- `release/v1.2.3` -> `v1.2.3` -> `1.2.3`
+- `release/v1.2.3-beta.2` -> `v1.2.3-beta.2` -> `1.2.3-beta.2`
+7. 检查目标 tag 是否已存在：`git tag -l "v<VERSION>"`。
+8. 输出推断出的版本号和推断来源，直接使用该版本号继续执行；不要向用户请求确认。
+9. 仅当无法从分支名或自动建分支流程唯一推断出合法版本号时，终止并要求用户显式指定目标版本。
+
+### 二、更新版本号
+
+1. 更新以下文件的 `version` 字段为纯版本号（不带 `v` 前缀）：
+- `package.json`
+- `apps/backend/package.json`
+- `apps/front/package.json`
+- `apps/admin-front/package.json`
+2. 仅修改 `version` 字段，不变更其他内容。
+3. 执行提交：
+
+```bash
+git add package.json apps/*/package.json
+git commit -F - <<'MSG'
+chore: bump version to <VERSION>
+
+更新所有 package.json 版本号为 <VERSION>
+
+发布准备提交
+MSG
+```
+
+### 三、收集与分析变更
+
+1. 优先获取最近已发布版本：
+
+```bash
+gh release list --limit 1 --json tagName,publishedAt --jq '.[0].tagName'
+```
+
+2. 若无 GitHub Release，回退：`git describe --tags --abbrev=0`。
+3. 采集范围：`<last-release-tag>..HEAD`。
+4. 收集数据：
+- `git log <last-release-tag>..HEAD --oneline`
+- `git log <last-release-tag>..HEAD --pretty=format:"%H|%s|%b"`
+- `git diff <last-release-tag>..HEAD --shortstat`
+5. 从提交中提取 PR 编号（合并提交、Refs、Closes 等），并用 `gh pr view` 获取标题与标签。
+6. 去重同一 PR。
+7. 分类变更：
+- 新增：`feat` 或 feature 标签
+- 优化：`refactor`、`perf`、`chore`
+- 修复：`fix` 或 bug 标签
+- 技术改进：`docs`、`test`、`build`、`ci`
+8. 过滤噪音：忽略无意义合并记录与 `chore: bump version`。
+9. 识别运维提醒：环境变量、数据库迁移、依赖更新、配置与部署变更。
+
+### 四、生成发行说明
+
+1. 生成 3-5 条发布摘要，按业务影响排序。
+2. 输出分类变更清单，关联 PR 或 Issue。
+3. 使用以下结构：
+
+```markdown
+# v<VERSION> 发行说明
+
+## 发布摘要
+
+- <核心变更1> (#PR)
+- <核心变更2> (#PR)
+- <核心变更3> (#PR)
+
+发布日期：<YYYY-MM-DD>
+对比分支：`<last-tag>...v<VERSION>`
+
+## 新增
+
+- <新增项> (#PR)
+
+## 优化
+
+- <优化项> (#PR)
+
+## 修复
+
+- <修复项> (#PR)
+
+## 技术改进
+
+- <技术改进项> (#PR)
+
+## 运维提醒
+
+- <提醒项>
+
+## 引用
+
+- PRs：#1, #2
+- Issues：#10
+- 共计 <X> 个提交
+
+## 升级指南
+
+1. <步骤1>
+2. <步骤2>
+```
+
+### 五、创建发布
+
+1. 创建 annotated tag：
+
+```bash
+git tag -a v<VERSION> -m "Release v<VERSION>"
+```
+
+2. 推送 tag：
+
+```bash
+git push origin v<VERSION>
+```
+
+3. 创建 GitHub Release：
+
+```bash
+gh release create v<VERSION> \
+  --title "v<VERSION>" \
+  --notes-file - <<'EOF'
+<完整发行说明>
+EOF
+```
+
+4. 输出发布 URL 与发布后检查清单。
+
+## 终止条件
+
+以下任一情况出现时终止流程并给出明确原因：
+
+- 工作区存在未提交修改。
+- 当前分支不符合 release 分支命名规则，且无法从 `main` 自动创建 release 分支。
+- 版本号格式非法或与现有 tag 冲突。
+- 自上次发布以来无新提交。
+
+## 输出模板
+
+### 发布前状态
+
+- 工作目录状态
+- 当前分支
+- 解析出的版本号
+- 版本格式校验结果
+- tag 冲突校验结果
+
+### 变更分析
+
+- 基准版本
+- 提交范围
+- 提交数与 PR 数
+- 代码变更统计
+- 分类统计
+
+### 发布结果
+
+- 版本号
+- 分支名
+- tag 推送状态
+- Release URL
+- 发布后清单

package/skills/git-release/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Git Release"
+  short_description: "在 release 分支上自动完成版本发布与发行说明生成"
+  default_prompt: "使用 $git-release 按规范执行一次发布并生成高质量发行说明。"
+
+policy:
+  allow_implicit_invocation: false

package/skills/online-debug-guard/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: online-debug-guard
+description: 仅在用户显式调用 $online-debug-guard 或明确要求使用 online-debug-guard 技能时使用；不要通过关键词、任务类型或上下文自动触发。
+---
+
+# 在线调试安全护栏
+
+## 概览
+
+在线调试先确认环境，再按环境选择门禁。只有 `production` 需要检查当前是否为 Plan 模式；其他环境不做 Plan 模式门禁。
+
+调试默认只读取证。需要改变远程状态、数据状态或进程状态时，先停下并取得用户明确授权。
+
+## 执行流程
+
+1. 识别目标环境。
+2. 如果目标环境是 `production`，校验当前会话是否为 Plan 模式。
+3. 使用 SSH config 连接远程机器。
+4. 通过远程运行时、pm2、shared 环境变量目录和当前代码目录取证。
+5. 汇总目标环境、门禁结果、关键证据和下一步建议。
+
+## 1. 识别目标环境
+
+只接受 `development`、`staging`、`production` 三种值。
+
+如果用户未显式给出环境：
+- 先询问用户当前环境。
+- 若无法确认，则默认 `development`，并明确告知本次按 `development` 执行。
+
+如果用户给了其他环境名，例如 `prod1`、`test`：
+- 立即终止。
+- 提示：`环境无效，仅支持 development/staging/production。`
+
+## 2. Production 门禁
+
+当且仅当目标环境是 `production` 时，必须确认当前处于 Plan 模式。
+
+如果不是 Plan 模式，立即终止并提示：
+
+```text
+已终止：当前为 production 环境，但会话不在 Plan 模式。
+请切换到 Plan 模式后再继续在线调试。
+```
+
+`development` 和 `staging` 不需要检查 Plan 模式，也不需要检查本地 `.env.*` 文件是否存在。
+
+## 3. 远程连接规范
+
+调试或查找问题时，通过本机 SSH config 中已有的 Host 配置连接远程机器。
+
+远程连接参数固定来自以下 SSH config Host：
+- `production` 环境：`ai-prod`
+- `staging` 环境：`ai-staging`
+
+```bash
+ssh ai-prod
+ssh ai-staging
+```
+
+连接后如果需要 root 权限，运行：
+
+```bash
+sudo -s
+```
+
+不要手写散落的 IP、用户名、私钥路径或临时 SSH 参数；优先复用 SSH config，避免连错机器。
+
+## 4. 远程取证规范
+
+远程服务通常由 pm2 管理。优先使用 pm2 的只读命令获取信息，例如：
+
+```bash
+pm2 list
+pm2 describe <app>
+pm2 logs <app> --lines 200
+pm2 env <id>
+```
+
+远程环境变量通常在：
+
+```text
+/home/ubuntu/work/{$project_name}/shared
+```
+
+需要数据库、Redis、第三方服务等连接参数时，到该目录读取对应环境文件或配置。读取机密时只用于定位问题，不在最终回复中暴露完整密钥、密码或 token。
+
+## 5. 代码与产物边界
+
+本地运行代码一般在当前目录下执行。
+
+远程机器上运行的是编译后的产物。排查时区分：
+- 本地源码：用于阅读、复现、运行测试和定位实现逻辑。
+- 远程产物：用于确认线上实际运行版本、pm2 进程、日志、环境变量和部署状态。
+
+不要假设远程源码与本地源码完全一致；需要时用版本号、提交 SHA、构建时间、pm2 环境或部署目录内容交叉确认。
+
+## 安全规则
+
+- 默认只读：优先查询、检查、对比、日志分析。
+- 未获用户明确授权前，禁止写库、删键、迁移、重启、reload、发布、修改远程文件或改环境变量。
+- 需要执行写操作时，先说明操作对象、影响范围、回滚方式和为什么必须这么做。
+- 输出结论必须包含：目标环境、Plan 门禁是否适用与结果、关键证据、下一步建议。
+
+## 标准开场模板
+
+```text
+开始在线调试前先执行安全门禁：
+1) 确认环境（development/staging/production）
+2) 只有 production 需要校验当前是否为 Plan 模式
+3) 门禁通过后，通过 SSH config 连接远程机器，并优先用 pm2、shared 环境目录和日志只读取证
+```