@ranger1/dx 0.1.64 → 0.1.66

package/codex/skills/backend-artifact-deploy/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: backend-artifact-deploy
+description: 将后端部署从“目标机拉源码并编译”改造为“本地构建制品、目标机仅安装运行依赖并启动”的标准流程。用于 Node/NestJS/Nx/Prisma 等后端项目，尤其适合需要无源码部署、支持 dev/staging/prod 多环境、要求双层环境文件覆盖（如 .env.production 与 .env.production.local）、以及需要在 pm2 与 direct 启动方式之间切换的场景。
+---
+
+# 后端制品部署
+
+## 概览
+
+使用该技能时，先识别项目当前的环境变量加载链路与启动链路，再落地“制品打包脚本 + 服务器发布脚本 + 回滚策略”。
+目标是保证目标机器不需要源码编译，同时保持与项目既有环境覆盖规则一致。
+
+## 执行流程
+
+### 第一步：确认现状链路
+
+依次核对：
+
+1. 构建链路是否依赖源码目录（例如 dist 里软链回源码 `node_modules`）。
+2. 运行链路如何加载环境变量（是否是两层覆盖，是否通过 `dotenv -e A -e B`）。
+3. 数据库迁移链路是否依赖运行时环境（Prisma `generate` / `migrate deploy` 前是否已加载 env）。
+4. 进程启动是否仅支持 pm2，是否需要 direct 前台测试模式。
+
+如果项目已有统一入口（例如 `dx` 或内部脚手架），优先复用该入口，不要绕开既有环境策略。
+
+### 第二步：定义制品边界
+
+默认采用“轻制品”模式：
+
+1. 本地只打包编译产物与必要运行文件，不打包 `node_modules`。
+2. 目标机解压后再安装生产依赖。
+3. 制品命名固定含版本与时间片，例如 `backend-v<version>-<月-日-时-分>.tgz`。
+
+制品最小清单应包含：
+
+1. 编译产物目录（如 `dist/backend/**`）。
+2. 数据库 schema 与迁移目录（如 `prisma/schema/**`）。
+3. 生产依赖清单（`package.production.json` 重命名为 `package.json`）。
+4. 锁文件（`pnpm-lock.yaml`）。
+5. 启动配置（如 `ecosystem.config.cjs`）。
+6. 双层环境文件（`.env.<env>` 与 `.env.<env>.local`）。
+
+### 第三步：实现打包脚本
+
+打包脚本应支持参数：
+
+1. `--env dev|staging|prod`。
+2. `--version`（默认取后端 `package.json` 版本）。
+3. `--time`（格式 `MM-DD-HH-mm`）。
+
+脚本关键行为：
+
+1. 按环境构建（`dev -> --dev`，`staging/prod -> --prod`）。
+2. 复制双层环境文件到制品目录。
+3. 不在本地安装运行依赖。
+4. 生成 `tgz`。
+
+### 第四步：实现发布脚本
+
+发布脚本应支持参数：
+
+1. `--archive`（必填）。
+2. `--env dev|staging|prod`。
+3. `--start-mode pm2|direct`（默认 `pm2`）。
+4. `--env-file` 与 `--env-local-file`（可选覆盖路径）。
+5. `--skip-install`、`--skip-migration`、`--skip-pm2`。
+
+发布顺序建议：
+
+1. 解压到 `releases/<version>`。
+2. 准备双层 env 文件。
+3. 安装生产依赖。
+4. 执行 `prisma generate`。
+5. 执行 `prisma migrate deploy`。
+6. 切换 `current` 软链。
+7. 启动服务（pm2 或 direct）。
+8. 清理旧版本。
+
+### 第五步：双层环境加载规则（必须一致）
+
+所有关键步骤统一使用相同加载顺序：
+
+1. 基础层 `.env.<env>`。
+2. 覆盖层 `.env.<env>.local`。
+
+推荐显式写法：
+
+```bash
+APP_ENV="<env-name>" pnpm exec dotenv -e ".env.<env-name>" -e ".env.<env-name>.local" -- <command>
+```
+
+命令示例中的 `<command>` 包括：
+
+1. `pnpm exec prisma generate --schema=...`
+2. `pnpm exec prisma migrate deploy --schema=...`
+3. `pm2 startOrReload ...` 或 `node apps/backend/src/main.js`
+
+## 验证清单
+
+交付前必须至少验证：
+
+1. 打包脚本 `--help` 与语法检查通过。
+2. 发布脚本 `--help` 与语法检查通过。
+3. 制品内同时包含 `.env.<env>` 与 `.env.<env>.local`。
+4. 发布脚本在默认路径下能正确识别并使用两层 env。
+5. `start-mode=direct` 可前台启动。
+6. `start-mode=pm2` 可重载或启动。
+7. 版本目录与 `current` 切换正常，可回滚。
+
+## 常见陷阱
+
+1. 把 env 文件链接到自身，造成坏链路。
+2. 只加载 `.env.<env>`，遗漏 `.local` 覆盖。
+3. 迁移与启动阶段用不同 env 加载逻辑，导致行为不一致。
+4. staging 构建误用 development 或 production 的 env 层。
+5. 打包包含本机 `node_modules`，跨系统运行失败。
+
+## 参考资料
+
+需要细化实现时，读取：
+
+- `references/deployment-checklist.md`

package/codex/skills/backend-artifact-deploy/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "后端制品部署"
+  short_description: "跨项目复用的后端制品构建发布与双层环境变量合并流程"
+  default_prompt: "Use $backend-artifact-deploy to design and implement source-free backend artifact deployment with layered env handling."

package/codex/skills/backend-artifact-deploy/references/deployment-checklist.md

@@ -0,0 +1,66 @@
+# 后端制品部署检查清单
+
+## 一、改造前采样
+
+1. 查找构建后是否存在软链回源码依赖：
+
+```bash
+rg -n "ln -sfn.*node_modules|node_modules.*ln -sfn" <backend-package-json-path>
+```
+
+2. 查找环境加载入口：
+
+```bash
+rg -n "dotenv -e|dotenv --override|ConfigModule.forRoot|loadEnvironment|env-layers" -S <repo-root>
+```
+
+3. 查找启动命令：
+
+```bash
+rg -n "start:prod|pm2|node .*main" -S <repo-root>
+```
+
+## 二、打包脚本最低要求
+
+1. 接收 `--env`、`--version`、`--time`。
+2. 制品名包含版本与时间片。
+3. 打入 `.env.<env>` 与 `.env.<env>.local`。
+4. 不打入 `node_modules`（轻制品模式）。
+
+## 三、发布脚本最低要求
+
+1. 解压到 `releases/<version>` 并切换 `current`。
+2. 支持 `pm2` 与 `direct` 两种启动方式。
+3. 在 install、migrate、start 三阶段都用同一套双层 env 加载顺序。
+4. 支持 `--env-file` 与 `--env-local-file` 覆盖路径。
+
+## 四、上线前验证命令
+
+```bash
+bash -n scripts/release/backend-build-release.sh
+bash -n scripts/release/backend-deploy-release.sh
+scripts/release/backend-build-release.sh --env staging
+tar -tzf release/backend/*.tgz | rg "\.env\.staging(\.local)?$"
+```
+
+## 五、发布后验证
+
+1. 进程检查：
+
+```bash
+pm2 status
+pm2 logs backend --lines 120
+```
+
+2. 健康检查：
+
+```bash
+curl -f http://127.0.0.1:3000/health
+```
+
+3. 回滚检查：
+
+```bash
+ln -sfn /opt/ai-backend/releases/<old-version> /opt/ai-backend/current
+pm2 reload backend --update-env
+```

package/codex/skills/gh-dependabot-cleanup/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: gh-dependabot-cleanup
+description: Use when a user asks to check or remediate GitHub Dependabot alerts and deliver one closed-loop PR, including alert triage, dependency updates, verification, and PR creation with unresolved items clearly documented.
+---
+
+# GH Dependabot Cleanup
+
+## Overview
+Use this skill to complete a Dependabot remediation loop with minimal manual input. Rely on `gh` directly, fix all patchable alerts in scope, and document unpatched alerts without auto-dismiss.
+
+## Closed Loop Workflow
+1. Confirm target and scope in one sentence.
+2. Fetch open alerts with `gh api`.
+3. Classify alerts into:
+   - patchable: has `first_patched_version`
+   - unpatched: no `first_patched_version`
+   - direct vs transitive
+4. Announce remediation plan before edits.
+5. Apply dependency changes (prefer overrides/resolutions for transitive alerts).
+6. Refresh lockfile.
+7. Run required project verification commands.
+8. Commit, push, and open exactly one PR.
+9. Report residual risk (unpatched alerts) in PR and final reply.
+
+## Default Commands
+```bash
+# 1) Fetch open alerts JSON
+gh api -H 'Accept: application/vnd.github+json' \
+  '/repos/OWNER/REPO/dependabot/alerts?state=open&per_page=100'
+
+# 2) Tabular triage view
+gh api -H 'Accept: application/vnd.github+json' \
+  '/repos/OWNER/REPO/dependabot/alerts?state=open&per_page=100' \
+  | jq -r '.[] | [.number, .security_vulnerability.package.name, .dependency.relationship, .security_advisory.severity, (.security_vulnerability.first_patched_version.identifier // "none"), .security_vulnerability.vulnerable_version_range, .html_url] | @tsv'
+
+# 3) Typical lock refresh (adapt to repo)
+pnpm install --lockfile-only
+```
+
+## Decision Rules
+- Keep unpatched alerts open by default; do not dismiss unless explicitly requested.
+- If one package maps to multiple alerts, upgrade once to the highest required safe version.
+- Keep the PR focused on security dependency remediation only.
+- If repo has branch/issue conventions, follow them strictly.
+
+## PR Requirements
+Include these sections:
+1. Fixed alerts: alert id, package, target version
+2. Remaining alerts: alert id, reason (for example, no upstream patch)
+3. Verification: exact commands run and outcomes
+4. Risk note: what is deferred and why
+
+## Fast Trigger
+修复安全警告

package/codex/skills/gh-dependabot-cleanup/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Dependabot Cleanup PR"
+  short_description: "Fix GitHub Dependabot alerts in one PR workflow"
+  default_prompt: "Use $gh-dependabot-cleanup to remediate open Dependabot alerts and create one PR."

package/codex/skills/git-commit-and-pr/SKILL.md

@@ -0,0 +1,208 @@
+---
+name: git-commit-and-pr
+description: 在 Git 仓库中执行自动化 Issue、Commit、PR 工作流。用于以下场景：需要零输入一键完成 Issue→分支→Commit→PR；需要根据仓库状态自动判断下一步；需要创建结构化 GitHub Issue；需要基于暂存变更生成规范 commit；需要推送分支并创建 Pull Request；需要串联输出清晰阶段结果。支持仅建 Issue、仅建 PR、指定 Issue 编号、指定 PR 基准分支。
+---
+
+# Git Commit And PR
+
+## 目标
+
+在最少人工输入下完成 `Issue -> Branch -> Commit -> PR` 标准流程，并保持可审计输出。
+
+## 默认行为（零输入）
+
+当用户只调用 `/git-commit-and-pr` 且不带参数时，执行“全自动模式”，不再向用户追问：
+
+1. 检查仓库状态与当前分支。
+2. 若工作树有未提交改动：执行 Issue -> Branch -> Commit -> PR。
+3. 若工作树干净：对比当前分支与 `main`（或默认基准）差异，并检查最近提交，判断是否应直接创建 PR。
+4. 若工作树干净且存在分支差异：直接推送并创建 PR（不再创建新 Issue/Commit）。
+5. 输出 Issue、Commit、PR 链接与下一步命令。
+
+说明：保留所有旧能力，不影响 `--issue`、`--issue-only`、`--pr --base`。
+
+## 执行原则
+
+- 全程中文输出。
+- 先检查状态，再决定执行阶段。
+- 禁止在 `main/master` 直接提交代码。
+- 优先自动完成，不因“小缺信息”中断；只在不可执行时报阻塞。
+- 输出必须包含：已完成项、阻塞原因、下一步建议。
+
+## 输入形式
+
+- 自动模式：`/git-commit-and-pr`
+- 指定 Issue：`/git-commit-and-pr --issue <ID>`
+- 仅创建 Issue：`/git-commit-and-pr --issue-only`
+- 仅创建 PR：`/git-commit-and-pr --pr --base <BRANCH>`
+
+## 流程
+
+### 一、状态检测（并行）
+
+```bash
+git status --short
+git branch --show-current
+git log -1 --format='%H %s' 2>/dev/null || echo "no-commits"
+```
+
+补充检测：
+
+```bash
+git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null || echo "no-upstream"
+git remote -v
+git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo "origin/main"
+git log --oneline -n 5
+git log origin/main..HEAD --oneline
+git diff --stat origin/main...HEAD
+```
+
+决策规则：
+
+- `--issue-only`：仅走 Issue 创建并结束。
+- `--pr`：跳过 Issue/Commit，直接走 PR 流程。
+- 默认模式：
+  - 若 `git status --short` 非空：按 `Issue -> Branch -> Commit -> PR` 全链路执行。
+  - 若 `git status --short` 为空且 `origin/main..HEAD` 有提交差异：直接执行 PR 创建。
+  - 若 `git status --short` 为空且无分支差异：输出“无需创建 PR”，并结束。
+
+### 二、Issue 创建
+
+1. 收集上下文：
+- `git status --short`
+- `git diff --stat`
+- 可选去重：`gh issue list --search "<关键词>" --limit 5`
+
+2. 生成标题：`[模块] 简洁描述` 或 `[类型] 功能/问题描述`。
+
+3. 标签：从 `bug`、`enhancement`、`documentation`、`performance`、`refactor`、`backend`、`frontend`、`infrastructure` 中选择。
+
+4. 正文结构固定：背景、现状/问题、期望行为、执行计划、影响范围、相关资源。
+
+5. 创建命令（heredoc）：
+
+```bash
+gh issue create \
+  --title "[模块] 问题摘要" \
+  --label label1 --label label2 \
+  --body-file - <<'MSG'
+## 背景
+[背景]
+
+## 现状/问题
+[问题]
+
+## 期望行为
+[目标]
+
+## 执行计划
+- [ ] 步骤一
+- [ ] 步骤二
+
+## 影响范围
+[范围]
+MSG
+```
+
+### 三、分支处理（新增强制步骤）
+
+1. 若当前分支是 `main/master`，必须切新分支后再提交。
+2. 若存在 Issue 编号，分支名优先：`codex/fix/<issue-id>-<slug>`。
+3. 若已在合法功能分支且用户显式要求保留，则继续使用当前分支。
+
+示例：
+
+```bash
+git switch -c codex/fix/1234-short-topic
+```
+
+### 四、Commit 流程
+
+1. 暂存与检查：
+
+```bash
+git add -A
+git diff --cached --stat
+```
+
+2. 根据 `git diff --cached` 生成提交：
+
+```bash
+git commit -F - <<'EOF'
+<type>: <概要>
+
+变更说明：
+- <变更项一>
+- <变更项二>
+
+Refs: #<issue-id>
+EOF
+```
+
+3. `type` 仅用：`feat/fix/refactor/docs/chore/test`。
+
+4. 提交后确认：
+
+```bash
+git status
+git log -1 --oneline
+```
+
+### 五、PR 创建
+
+1. 推送分支：
+
+```bash
+git push -u origin HEAD
+```
+
+2. 变更分析：
+
+```bash
+git log origin/main..HEAD --oneline
+git diff origin/main...HEAD --stat
+```
+
+3. 创建 PR（默认 `--base main`）：
+
+```bash
+gh pr create --base main --title '<type>: <概要>' --body-file - <<'EOF'
+## 变更说明
+
+- <变更项>
+
+## 测试
+
+- [ ] 本地测试通过
+
+Closes: #<issue-id>
+EOF
+```
+
+4. 成功后输出评审命令：`/pr-review-loop --pr <PR_NUMBER>`。
+
+## 质量检查
+
+- 标题简洁可读，语义明确。
+- 描述包含背景、问题、目标、影响范围。
+- 提交与 PR 文案可核对到 diff。
+- 标签与提交类型匹配。
+- 不泄露敏感信息。
+
+## 失败与阻塞输出
+
+输出以下四项：
+
+- 停止阶段
+- 已完成列表
+- 阻塞原因
+- 继续执行命令建议
+
+## 成功输出
+
+输出以下四项：
+
+- Issue 编号与标题
+- Commit 摘要
+- PR 编号与链接
+- 下一步评审命令

package/codex/skills/git-commit-and-pr/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Git Commit 与 PR"
+  short_description: "零输入自动执行 Issue、分支、Commit、PR 全流程"
+  default_prompt: "使用 $git-commit-and-pr 在当前仓库自动完成 Issue、分支、Commit、PR 全流程。"

package/codex/skills/git-release/SKILL.md

@@ -0,0 +1,187 @@
+---
+name: git-release
+description: 在 Git 仓库中执行标准化版本发布流程并自动生成高质量中文发行说明。用于以下场景：需要从 release 分支发布新版本；需要从分支名提取并校验语义化版本（含 alpha/beta/rc 预发布）；需要批量更新多个 package.json 的 version 字段并提交；需要基于最近 GitHub Release 汇总提交与 PR 信息、分类变更、生成发布摘要；需要创建 annotated tag、推送远端并创建 GitHub Release。
+---
+
+# Git Release
+
+## 目标
+
+在 `release/vX.Y.Z` 或 `release/vX.Y.Z-<prerelease>.N` 分支上，完成从发布前检查到 GitHub Release 创建的全流程。
+
+## 执行原则
+
+- 全程使用中文输出。
+- 严格执行前置校验，任何硬性条件不满足时立即终止。
+- 发行说明必须结构化、可读、可追溯。
+- 命令默认在仓库根目录执行。
+
+## 流程
+
+### 一、发布前检查
+
+1. 检查工作区是否干净：`git status --porcelain`。
+2. 若存在未提交变更，列出文件并终止流程。
+3. 检查当前分支：`git branch --show-current`。
+4. 仅接受以下正则：`^release/v\d+\.\d+\.\d+(-(alpha|beta|rc)\.\d+)?$`。
+5. 从分支名提取版本号，例如：
+- `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`
+6. 检查目标 tag 是否已存在：`git tag -l "v<VERSION>"`。
+7. 向用户确认版本号；若用户修改版本号，重新校验格式与 tag 冲突。
+
+### 二、更新版本号
+
+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 分支命名规则。
+- 版本号格式非法或与现有 tag 冲突。
+- 自上次发布以来无新提交。
+
+## 输出模板
+
+### 发布前状态
+
+- 工作目录状态
+- 当前分支
+- 解析出的版本号
+- 版本格式校验结果
+- tag 冲突校验结果
+
+### 变更分析
+
+- 基准版本
+- 提交范围
+- 提交数与 PR 数
+- 代码变更统计
+- 分类统计
+
+### 发布结果
+
+- 版本号
+- 分支名
+- tag 推送状态
+- Release URL
+- 发布后清单

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

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

package/lib/opencode-initial.js

@@ -39,6 +39,37 @@ async function collectTemplateFiles(dir) {
   return out
 }
 
+async function collectAllFiles(dir) {
+  const out = []
+
+  async function walk(current) {
+    let entries
+    try {
+      entries = await fs.readdir(current, { withFileTypes: true })
+    } catch {
+      return
+    }
+
+    for (const entry of entries) {
+      const full = join(current, entry.name)
+      if (entry.isDirectory()) {
+        if (entry.name === '__pycache__' || entry.name === '.pytest_cache') {
+          continue
+        }
+        await walk(full)
+        continue
+      }
+      if (!entry.isFile()) continue
+      const lowerName = entry.name.toLowerCase()
+      if (lowerName.endsWith('.pyc') || lowerName.endsWith('.pyo') || lowerName.endsWith('.pyd')) continue
+      out.push(full)
+    }
+  }
+
+  await walk(dir)
+  return out
+}
+
 async function ensureDir(path) {
   await fs.mkdir(path, { recursive: true })
 }
@@ -84,6 +115,37 @@ async function copyTemplateTree({ srcDir, dstDir }) {
   return { total: files.length, md: mdCount, py: pyCount, json: jsonCount }
 }
 
+async function copyDirMerge({ srcDir, dstDir }) {
+  const files = await collectAllFiles(srcDir)
+
+  for (const file of files) {
+    const rel = relative(srcDir, file)
+    const target = join(dstDir, rel)
+    await ensureDir(dirname(target))
+    await fs.copyFile(file, target)
+  }
+
+  return { fileCount: files.length }
+}
+
+async function copySkillsDirectories({ srcSkillsDir, dstSkillsDir }) {
+  const entries = await fs.readdir(srcSkillsDir, { withFileTypes: true })
+  let copiedDirs = 0
+  let copiedFiles = 0
+
+  for (const entry of entries) {
+    if (!entry.isDirectory()) continue
+    const srcDir = join(srcSkillsDir, entry.name)
+    const dstDir = join(dstSkillsDir, entry.name)
+    await ensureDir(dstDir)
+    const stats = await copyDirMerge({ srcDir, dstDir })
+    copiedDirs++
+    copiedFiles += stats.fileCount
+  }
+
+  return { copiedDirs, copiedFiles }
+}
+
 function resolveTemplateRoot(packageRoot) {
   return [join(packageRoot, '@opencode')]
 }
@@ -117,15 +179,20 @@ export async function runOpenCodeInitial(options = {}) {
   const srcCommands = join(existingRoot, 'commands')
   const dstAgents = join(dstRoot, 'agents')
   const dstCommands = join(dstRoot, 'commands')
+  const srcSkills = join(packageRoot, 'codex', 'skills')
+  const dstSkills = join(homeDir, '.codex', 'skills')
 
   await assertDirExists(srcAgents, '模板目录 agents')
   await assertDirExists(srcCommands, '模板目录 commands')
+  await assertDirExists(srcSkills, '模板目录 codex/skills')
 
   await ensureDir(dstAgents)
   await ensureDir(dstCommands)
+  await ensureDir(dstSkills)
 
   const agentsStats = await copyTemplateTree({ srcDir: srcAgents, dstDir: dstAgents })
   const commandsStats = await copyTemplateTree({ srcDir: srcCommands, dstDir: dstCommands })
+  const skillsStats = await copySkillsDirectories({ srcSkillsDir: srcSkills, dstSkillsDir: dstSkills })
 
   logger.success(`已初始化 OpenCode 模板到: ${dstRoot}`)
   logger.info(
@@ -138,4 +205,5 @@ export async function runOpenCodeInitial(options = {}) {
       `${commandsStats.py > 0 ? ` + ${commandsStats.py} 个 .py 文件` : ''}` +
       `${commandsStats.json > 0 ? ` + ${commandsStats.json} 个 .json 文件` : ''}`
   )
+  logger.info(`skills: ${skillsStats.copiedDirs} 个目录，覆盖复制 ${skillsStats.copiedFiles} 个文件 -> ${dstSkills}`)
 }

package/lib/vercel-deploy.js

@@ -18,8 +18,9 @@ const TARGET_CONFIGS = {
   admin: {
     configFile: 'vercel.admin.json',
     projectIdEnvVar: 'VERCEL_PROJECT_ID_ADMIN',
-    deployCwd: 'apps/admin-front',
-    deployMode: 'prebuilt'
+    deployCwd: '.',
+    deployMode: 'prebuilt',
+    prebuiltCwd: '.'
   },
   'telegram-bot': {
     configFile: 'vercel.telegram-bot.json',
@@ -168,8 +169,13 @@ function readLinkedProjectContext(contextRoot) {
 }
 
 function clearLinkedProjectContext(contextRoot) {
-  const path = join(contextRoot, VERCEL_PROJECT_LINK_PATH)
-  rmSync(path, { force: true })
+  const linkDir = join(contextRoot, '.vercel')
+  rmSync(linkDir, { force: true, recursive: true })
+}
+
+function clearVercelBuildOutput(contextRoot) {
+  const outputDir = join(contextRoot, '.vercel', 'output')
+  rmSync(outputDir, { force: true, recursive: true })
 }
 
 async function runVercel(args, options = {}) {
@@ -375,9 +381,8 @@ export async function deployToVercel(target, options = {}) {
         `检测到 ${VERCEL_PROJECT_LINK_PATH} 但解析失败: ${linkedContext.parseError.message}`
       )
       if (strictContext) {
-        logger.error('strictContext 已开启，已阻止继续部署以避免回退污染')
-        process.exitCode = 1
-        return
+        logger.warn('strictContext 已开启：自动清理 .vercel 后继续部署')
+        clearLinkedProjectContext(prebuiltCwd)
       }
     }
 
@@ -388,11 +393,11 @@ export async function deployToVercel(target, options = {}) {
         `  本地链接: org=${maskIdentifier(linkedContext.orgId)} project=${maskIdentifier(linkedContext.projectId)}`
       )
       if (strictContext) {
-        logger.error('strictContext 已开启，已阻止部署（请清理 .vercel 或修正环境变量）')
-        process.exitCode = 1
-        return
+        logger.warn('strictContext 已开启：检测到冲突，自动清理 .vercel 后继续部署')
+        clearLinkedProjectContext(prebuiltCwd)
+      } else {
+        logger.warn('strictContext 已关闭，继续执行（可能存在误部署风险）')
       }
-      logger.warn('strictContext 已关闭，继续执行（可能存在误部署风险）')
     }
 
     logger.info(
@@ -431,6 +436,8 @@ export async function deployToVercel(target, options = {}) {
       if (strictContext && process.env.DX_VERCEL_KEEP_LINK !== '1') {
         clearLinkedProjectContext(prebuiltCwd)
       }
+      // 避免 Vercel 本地预构建产物残留导致 EEXIST（如 _global-error.func 符号链接冲突）
+      clearVercelBuildOutput(prebuiltCwd)
 
       // 第一步：本地构建
       logger.step(`本地构建 ${t} (${environment})`)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ranger1/dx",
-  "version": "0.1.64",
+  "version": "0.1.66",
   "type": "module",
   "license": "MIT",
   "repository": {
@@ -19,6 +19,7 @@
     "bin/",
     "lib/",
     "@opencode/",
+    "codex/",
     "LICENSE",
     "README.md",
     "package.json"