@weotro/dx 0.1.12 → 0.1.14

package/skills/git-release/SKILL.md

@@ -1,210 +1,50 @@
 ---
 name: git-release
-description: 仅在用户显式调用 $git-release 或明确要求使用 git-release 技能时使用；不要通过关键词、任务类型或上下文自动触发。
+description: 仅在显式调用 git-release 时使用：准备或执行版本发布及回访审计。
 ---
 
 # Git Release
 
-## 目标
-
-在 `release/vX.Y.Z` 或 `release/vX.Y.Z-<prerelease>.N` 分支上，完成发布前检查、GitHub Release 创建和本次发布部署完成后的回访审计 Issue 建立；若当前不在 release 分支，则先从最新 `main` 自动创建目标 release 分支。
-
-## 执行原则
-
-- 全程使用中文输出。
-- 严格执行前置校验，任何硬性条件不满足时立即终止。
-- 发行说明必须结构化、可读、可追溯。
-- 发布完成必须留下一个可追踪的“部署完成后回访审计单” Issue；终端里临时打印 checklist 不算完成。
-- 回访 Issue 是审计本次 release 是否完整、正确落地的取证清单，不是部署操作手册。正文应围绕本次发布内容提出核对项，不编排部署步骤、命令顺序或服务器操作教程。
-- 本技能只编写回访审计 Issue，不执行生产验证。不得登录生产服务器、访问生产数据库、调用生产只读接口、查询生产监控或尝试取得生产凭据。
-- GitHub Release 创建成功不代表已经部署。所有需要部署完成后取证的审计项默认未勾选，留给运维或后续回访 agent 补充实际结果与证据。
-- 命令默认在仓库根目录执行。
-- 若能从当前 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)
+在宿主系统与开发者指令约束内，冲突时依次采用：当前任务的具体要求与已有授权 > 目标项目适用的 AGENTS.md > 本技能及其引用的通用流程。
+只读检索、本地草稿、可回滚编辑和常规测试可自主推断并继续；从相关文件和直接依赖开始，仅在证据不足或影响跨模块时扩大范围，复用仍有效的验证。
+仅在不可逆或难以回滚的修改缺少具体授权时，先完成预览、草稿与验证，再说明对象和影响并等待确认；会话中已有授权继续有效。缺少事实时先查证、标注假设并推进独立工作，确实无法确定操作目标时才询问。对外发送消息须有明确授权。
 
-## 修复
+## 发布准备
 
-- <修复项> (#PR)
+从当前 release 分支、用户指定版本或项目版本策略确定目标版本，说明来源。若项目采用 `release/vX.Y.Z`（也支持 alpha/beta/rc）则沿用；其他命名服从项目规则。没有版本策略时可以准备下一补丁版本的本地草稿，公开发布前核实目标。
 
-## 技术改进
+检查工作区、基线与目标 tag。无关未提交改动保留；需要干净发布环境时使用隔离 worktree，继续在原工作区读取与起草。版本格式错误、tag 指向冲突或缺少发布内容时先诊断可修复原因，阻止有问题的发布操作，继续可完成的准备工作。
 
-- <技术改进项> (#PR)
+从项目实际 manifest 与发布配置确定需要更新的包，仅修改本次发布的版本字段；不假设存在 `apps/backend` 等目录。按项目规定运行发布检查与相关测试，复用当前输入的有效结果。需要提交时按明确文件路径暂存并核对。
 
-## 运维提醒
+## 发行说明
 
-- <提醒项>
+优先从 GitHub Release 确定上次发布，必要时结合 tags 与项目策略确认基线。首次发布按项目约定确定范围。读取该基线到目标提交的日志、diff 摘要和相关 PR；仅对影响理解有必要的文件展开内容。
 
-## 引用
+说明实质变更、对应 PR/Issue、兼容性和升级注意事项；按实际内容分类，不填无关栏目。先在本地完成发行说明和回访审计草稿，便于核对后发布。
 
-- PRs：#1, #2
-- Issues：#10
-- 共计 <X> 个提交
+## 创建发布
 
-## 升级指南
-
-1. <步骤1>
-2. <步骤2>
-```
-
-### 五、创建发布
-
-1. 创建 annotated tag：
+推送 tag 和创建 Release 可能触发不可逆的制品发布或部署。在执行前核对目标仓库、版本、commit、发行说明及现有授权；授权已明确覆盖这些对象时直接继续，否则准备好具体结果再确认。
 
+按项目发布流程创建 tag、推送并创建 Release；例如：
 ```bash
 git tag -a v<VERSION> -m "Release v<VERSION>"
-```
-
-2. 推送 tag：
-
-```bash
 git push origin v<VERSION>
+gh release create v<VERSION> --title "v<VERSION>" --notes-file <notes-path>
 ```
+预发布版本按项目规则设置 prerelease 标记。部分失败时先读回远端状态，复用已创建的 tag/Release，仅补齐剩余步骤；不覆盖冲突 tag，也不盲目重放发布。
 
-3. 创建 GitHub Release：
-
-```bash
-gh release create v<VERSION> \
-  --title "v<VERSION>" \
-  --notes-file - <<'EOF'
-<完整发行说明>
-EOF
-```
-
-4. 读回 Release，确认 tag、标题、正文和 URL 正确：`gh release view v<VERSION> --json tagName,name,body,url,isDraft,isPrerelease`。
-
-### 六、创建部署完成后回访审计 Issue
-
-1. 完整读取 [发布后回访契约](references/post-release-follow-up.md)。
-2. 以本次 Release 说明、`<last-release-tag>..HEAD` 的提交与 diff、关联 PR/Issue 为主，按需读取仓库内的部署配置、迁移、运维脚本和 ops manifest，建立“发布内容 -> 受影响对象 -> 发布后风险/预期行为 -> 审计证据”的映射。不得通过 SSH、生产域名、数据库、监控平台、云平台 API 或私有环境配置验证当前生产状态。
-3. 自动创建一个“本次 release 部署完成后的回访审计单” Issue。逐项覆盖本次发布中的新增、优化、修复、技术改进和运维提醒；只有与本次变更相关时，才加入版本一致性、服务健康、迁移、脚本、数据、配置、可观测性、业务验收、回滚或延迟观察项。
-4. 每个审计项写清关联发布内容、审计对象、通过标准和应附的脱敏证据。使用“核对/确认/观察”的审计表述，不写“登录、执行、重启、部署”等操作步骤，也不提供部署命令或操作顺序。
-5. Issue 初始状态写为“待部署完成后回访”。所有依赖部署后事实的 checklist 保持未勾选；Release、tag 或 CI 的成功只能作为发布信息，不能代替生产落地证据。
-6. 使用 `gh issue view` 读回 Issue，确认没有占位符；发行说明中的每项实质变更均有对应审计项或明确的不适用说明；正文不存在通用部署手册式步骤；然后输出 Issue URL。
-
-## 终止条件
-
-以下任一情况出现时终止流程并给出明确原因：
-
-- 工作区存在未提交修改。
-- 当前分支不符合 release 分支命名规则，且无法从 `main` 自动创建 release 分支。
-- 版本号格式非法或与现有 tag 冲突。
-- 自上次发布以来无新提交。
-- 无法创建或读回部署完成后回访审计 Issue。
-
-## 输出模板
-
-### 发布前状态
+读回 `gh release view v<VERSION> --json tagName,name,body,url,isDraft,isPrerelease`，核对内容和目标提交后报告实际结果。
 
-- 工作目录状态
-- 当前分支
-- 解析出的版本号
-- 版本格式校验结果
-- tag 冲突校验结果
+## 发布后回访
 
-### 变更分析
+准备审计草稿时按需读取 [发布后回访契约](references/post-release-follow-up.md)。以本次变更映射受影响对象、预期行为、通过标准和脱敏证据；不是部署操作手册。
 
-- 基准版本
-- 提交范围
-- 提交数与 PR 数
-- 代码变更统计
-- 分类统计
+默认本技能只编写回访审计 Issue，不执行生产验证；用户另有只读取证任务时按该任务范围继续。发布成功不代表部署完成，依赖部署后事实的审计项保持未勾选。
 
-### 发布结果
+任务包含创建回访 Issue 时，发布成功后创建并读回，确认实质变更均有对应审计项或不适用说明。创建失败时保留草稿与已发布状态，修复可恢复错误，仅补做未完成的 Issue 操作。
 
-- 版本号
-- 分支名
-- tag 推送状态
-- Release URL
-- 预期部署环境、品牌与 target
-- 部署完成后回访审计 Issue URL
-- 待回访审计与待观察项目数量
+最终报告版本、目标提交、Release URL、验证结果和回访 Issue（或本地草稿）链接；区分发布成功、部署状态未知与未完成项。

package/skills/git-release/references/post-release-follow-up.md

@@ -1,6 +1,6 @@
 # 部署完成后回访审计 Issue 契约
 
-本文件只在 GitHub Release 创建并读回成功后使用。产物是“本次 release 部署完成后的回访审计单”：用于在部署完成后核对本次发布是否完整、正确落地并留下证据，不用于指导如何部署。
+准备发布后审计草稿时即可读取本文件；外部创建与读回按入口技能的任务范围和授权执行。产物是“本次 release 部署完成后的回访审计单”：用于在部署完成后核对本次发布是否完整、正确落地并留下证据，不用于指导如何部署。
 
 ## 定位与边界
 
@@ -12,7 +12,7 @@
 
 Issue 应描述“部署完成后要确认什么、什么结果算通过、需要什么证据”。不要描述部署动作、命令顺序、登录路径、重启流程或故障处置步骤；这些内容属于部署 runbook。
 
-当前调用不连接或探测生产环境，包括 SSH、生产数据库、生产域名或 health 接口、监控平台、云平台部署 API、服务器日志和私有环境 profile，也不为此取得密钥、token 或生产权限。
+单纯生成回访审计单只需发布资料，不自动扩展为生产巡检。当前任务明确包含生产只读取证时，可利用已有权限采集相关证据；未知状态保留待核验，不猜测或取得无关凭据。
 
 GitHub Release、tag、CI 或部署工作流成功都不能证明生产已完成部署。Issue 初始状态统一写为“待部署完成后回访”，所有依赖生产事实的审计项保持未勾选。
 
@@ -75,7 +75,7 @@ GitHub Release、tag、CI 或部署工作流成功都不能证明生产已完成
 
 ## 完成边界
 
-`git-release` 本次调用完成的最低条件是：
+完整发布并创建回访 Issue 的完成条件如下；用户仅要求本地草稿时，以草稿覆盖范围和质量为准：
 
 - Release 已读回确认；
 - 本次发布的每项实质变更已映射到审计项或不适用说明；

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

@@ -1,111 +1,30 @@
 ---
 name: online-debug-guard
-description: 仅在用户显式调用 $online-debug-guard 或明确要求使用 online-debug-guard 技能时使用；不要通过关键词、任务类型或上下文自动触发。
+description: 仅在显式调用 online-debug-guard 时使用：远程在线调试与取证。
 ---
 
 # 在线调试安全护栏
 
-## 概览
+## 执行边界与优先级
 
-在线调试先确认环境，再按环境选择门禁。只有 `production` 需要检查当前是否为 Plan 模式；其他环境不做 Plan 模式门禁。
+在宿主系统与开发者指令约束内，冲突时依次采用：当前任务的具体要求与已有授权 > 目标项目适用的 AGENTS.md > 本技能及其引用的通用流程。
+只读检索、本地草稿、可回滚编辑和常规测试可自主推断并继续；从相关文件和直接依赖开始，仅在证据不足或影响跨模块时扩大范围，复用仍有效的验证。
+仅在不可逆或难以回滚的修改缺少具体授权时，先完成预览、草稿与验证，再说明对象和影响并等待确认；会话中已有授权继续有效。缺少事实时先查证、标注假设并推进独立工作，确实无法确定操作目标时才询问。对外发送消息须有明确授权。
 
-调试默认只读取证。需要改变远程状态、数据状态或进程状态时，先停下并取得用户明确授权。
+## 确定目标
 
-## 执行流程
+从当前任务、已有连接信息、项目配置和 SSH Host 推断目标环境，接受项目的环境别名（如 `prod1`、`test`）。先读相关配置核实映射；目标仍不唯一时继续本地定位，在连接不明确的远程主机前询问。未知环境不默认当作 development。
 
-1. 识别目标环境。
-2. 如果目标环境是 `production`，校验当前会话是否为 Plan 模式。
-3. 使用 SSH config 连接远程机器。
-4. 通过远程运行时、pm2、shared 环境变量目录和当前代码目录取证。
-5. 汇总目标环境、门禁结果、关键证据和下一步建议。
+生产环境的已授权只读取证不依赖 Plan 模式。连接优先使用项目指定的 SSH Host；`ai-prod`、`ai-staging` 仅是已有项目的示例，使用前核实实际配置。
 
-## 1. 识别目标环境
+## 取证
 
-只接受 `development`、`staging`、`production` 三种值。
+先检查与症状有关的版本、进程状态和有限时间窗的日志，再按证据扩展。服务由 pm2 管理时可用 `pm2 list`、`pm2 describe <app>`、`pm2 logs <app> --lines 200 --nostream`。配置路径从当前部署定位；仅提取所需字段，避免输出完整环境变量或凭据。
 
-如果用户未显式给出环境：
-- 先询问用户当前环境。
-- 若无法确认，则默认 `development`，并明确告知本次按 `development` 执行。
+区分本地源码与远程运行产物，用 commit、版本或构建时间确认实际版本。本地复现、草稿修复和常规测试可直接推进；测试应使用隔离数据，避免对真实服务产生写入。
 
-如果用户给了其他环境名，例如 `prod1`、`test`：
-- 立即终止。
-- 提示：`环境无效，仅支持 development/staging/production。`
+## 修改与验证
 
-## 2. Production 门禁
+任务已覆盖的可回滚修复，记录原状态和恢复方式后执行并验证。写库、删键、迁移、发布等操作先判断实际影响和现有授权；不可逆或难以回滚且尚未授权时，先准备具体操作方案与验证证据，再等待确认。重启、reload 等按服务中断风险和项目规定处理，不因已有授权跨轮失效而重复询问。
 
-当且仅当目标环境是 `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 环境目录和日志只读取证
-```
+报告实际目标环境、关键证据、修改与验证结果、仍未解决的事项。

package/skills/online-debug-guard/agents/openai.yaml

@@ -0,0 +1,2 @@
+policy:
+  allow_implicit_invocation: false

package/skills/prune-git-repository/SKILL.md

@@ -1,19 +1,25 @@
 ---
 name: prune-git-repository
-description: 仅在用户显式调用 $prune-git-repository、/prune-git-repository 或明确要求使用 prune-git-repository 技能时使用；不要通过关键词、任务类型或上下文自动触发。
+description: 仅在显式调用 prune-git-repository 时使用：预览或清理 Git 分支、标签、Release 和 worktree。
 ---
 
 # Prune Git Repository
 
+## 执行边界与优先级
+
+在宿主系统与开发者指令约束内，冲突时依次采用：当前任务的具体要求与已有授权 > 目标项目适用的 AGENTS.md > 本技能及其引用的通用流程。
+只读检索、本地草稿、可回滚编辑和常规测试可自主推断并继续；从相关文件和直接依赖开始，仅在证据不足或影响跨模块时扩大范围，复用仍有效的验证。
+仅在不可逆或难以回滚的修改缺少具体授权时，先完成预览、草稿与验证，再说明对象和影响并等待确认；会话中已有授权继续有效。缺少事实时先查证、标注假设并推进独立工作，确实无法确定操作目标时才询问。对外发送消息须有明确授权。
+
 Use the bundled scripts instead of rebuilding shell loops. Always run them from the target repository.
 
 ## Authorization gate
 
 Treat every execute mode as destructive.
 
-1. Require explicit current-turn authorization for the exact cleanup categories and thresholds.
+1. Infer categories and thresholds for a read-only preview from the task and script defaults. Authorization from earlier turns remains valid for the same scope.
 2. Run dry-run mode first and report counts, cutoff, keep sets, protected refs, and occupied branches.
-3. Pass `--execute` only after the authorization covers the previewed deletions.
+3. Pass `--execute` when existing authorization covers the previewed deletions, including any loss of uncommitted work. Otherwise present the concrete deletion list and impact, then wait for confirmation; dry-runs need no approval.
 4. Never delete the base branch, remote default branch, current worktree, or current branch.
 5. Preserve unrelated working-tree changes. Do not infer permission to push recent local-only branches.
 
@@ -28,8 +34,8 @@ When multiple categories are authorized, use this order:
 3. Remove extra worktrees first so checked-out candidate branches can be deleted.
 4. Prune branches.
 5. Prune Releases and tags.
-6. Fetch/prune and run the scripts again without `--execute`; require zero remaining candidates.
-7. Verify `main...origin/main`, a clean current worktree, server-side refs through `ls-remote`, and matching local/remote tag sets.
+6. Re-run only the selected previews; explain protected or deliberately retained candidates instead of expanding deletions to reach zero.
+7. Verify affected refs with server-side evidence and selected worktree/tag results. Preserve unrelated dirty files; do not require global branch/tag synchronization for a partial cleanup.
 
 ## Commands
 
@@ -69,7 +75,7 @@ Preview or retain only the newest tags and GitHub Releases:
   --remote origin --keep 10 --execute
 ```
 
-Use `--tags-only` only when the user explicitly excludes GitHub Releases. The combined mode requires the retained tag names and retained Release tag names to match; stop for user direction if they differ.
+Use `--tags-only` only when the user explicitly excludes GitHub Releases. The combined mode requires retained tag names and retained Release tag names to match. If they differ, inspect the discrepancy and prepare a corrected preview; request confirmation only if the required deletion scope exceeds existing authorization.
 
 ## Reporting
 

package/skills/prune-git-repository/references/pitfalls.md

@@ -40,4 +40,4 @@ Read this file before execute mode.
 - Use `git worktree remove --force --force` and wait for it to finish; dependency directories can make deletion slow.
 - Run `git worktree prune --expire now` for missing or partially removed worktrees.
 - If Git says a registered directory is not a working tree, delete only that already-validated registered directory, then prune. Never broaden the fallback to a parent directory shared with the current checkout.
-- After cleanup, raw porcelain output must contain exactly the current worktree.
+- After cleanup, verify the authorized worktrees are gone and retained worktrees remain; exactly one is expected only when all extra worktrees were authorized for removal.

package/skills/ship-issue-pr/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: ship-issue-pr
+description: 仅在显式调用 ship-issue-pr 时使用：实现、验证并交付 Issue 或 PR。
+disable-model-invocation: true
+---
+
+# Ship Issue PR
+
+统一 Codex 与 Claude Code 的交付入口。按当前任务的终点处理本地改动、PR 或合并。
+
+## 任务边界
+
+在宿主系统与开发者指令约束内，当前具体任务与已有授权 > 项目适用的 AGENTS.md > 本技能和共享参考。只读检索、本地草稿、可回滚编辑和常规测试自主推进，按证据扩展检索并复用验证。不可逆或难以回滚且未获具体授权的修改，先准备结果再确认；对外消息须有明确授权。
+
+## 读取共享流程
+
+读取本技能目录内的 [共享交付流程](references/core.md)。源码使用和 `dx initial` 安装后均使用同一相对路径；Claude 通过技能目录软链接访问同一份资料。
+
+共享流程按当前步骤读取：状态与范围 → 实现与验证 → 提交/PR → 已授权的合并与回访。已经完成的部分直接承接。
+
+## 按宿主选择工具
+
+依据当前会话和可用工具确定宿主，不按模型名称或“本机同时装了哪些 CLI”判断，无需用户选择运行时。
+
+| 当前宿主 | 需要外部协作时才读取 |
+| --- | --- |
+| Codex | [Codex 运行时](references/codex.md)：通过 ask_cc / delegate-cc 咨询、审查或执行 |
+| Claude Code | [Claude Code 运行时](references/claude-code.md)：通过可用的 Codex 插件协作 |
+| 其他或外部工具不可用 | 当前执行者直接完成可做的实现与自审，说明独立能力的限制 |
+
+轻改动直接推进，无需为了加载技能探测另一套运行时。仅加载当前宿主所需参考。外部执行者接手的是分配范围，完整交付与事实核验默认仍由主进程负责。

package/skills/ship-issue-pr/agents/openai.yaml

@@ -0,0 +1,2 @@
+policy:
+  allow_implicit_invocation: false

package/skills/ship-issue-pr/references/claude-code.md

@@ -0,0 +1,36 @@
+# Claude Code 运行时
+
+仅在 Claude Code 宿主确实需要 Codex 协作或已授权的后续委派时读取；交付范围、权限、验证复用与完成条件遵循共享流程。
+
+## Codex 通道
+
+先使用当前会话已暴露的插件能力。已安装对应 Codex 插件时，可用：
+
+- 方案咨询、实现或定制审查：`Agent(subagent_type: "codex:codex-rescue")`，在任务书中明确只读或可写责任范围。
+- 普通审查：Codex companion 的 `review`。
+- 需要挑战方案假设时：companion 的 `adversarial-review`。
+
+这些是可选插件的调用方式，`dx initial` 只安装技能和引用文件，不安装 Codex 插件或配置认证。通道不可用时主进程继续实现或自审并如实报告。
+
+## companion 与结果
+
+使用插件提供的实际路径。需要定位时，仅检查当前 Claude 配置目录内对应的 marketplace/cache 路径；常见默认位置是 `~/.claude/plugins/marketplaces/openai-codex/plugins/codex` 或 `~/.claude/plugins/cache/openai-codex/codex/<version>`。以实际安装版本与 `scripts/codex-companion.mjs --help` 核实参数，不硬编码某个缓存版本。
+
+确认后通过宿主异步工具运行，例如：
+```bash
+node "<plugin-root>/scripts/codex-companion.mjs" review --wait --base "<actual-base>"
+```
+
+保存本次返回的 job/agent ID、worktree 和输出位置，持续观察该任务。旧插件若只提供本地状态，按本次派发时间和 workspaceRoot 定位对应 job，再固定 ID；不要不断读取“最新任务”。
+
+旧版状态可能在 `~/.claude/plugins/data/codex-openai-codex/state/*/state.json` 及相邻 `jobs/<id>.json`。该格式中 `status=completed` 且 `phase=done` 表示返回，正文在 `result.rawOutput`；使用前确认实际版本格式。返回报告仍需核对 diff、验收范围与验证证据。
+
+## 责任与验证
+
+主进程默认负责 Git/GitHub 交付，Codex 只修改任务书分配的文件；咨询与审查为只读。交接包含目标、必要上下文、已有成果和项目实际验证命令。
+
+根据实际权限判断补跑项，不预设沙箱不能联网、绑定端口或运行数据库测试。核对版本、命令、环境和可读输出后复用验证，只补缺失或失效项。
+
+等待期间主进程可继续不重叠工作。静默告警触发诊断，接管前确保旧写进程停止；无法使用外部通道时自行继续，不把自审冒充独立审查。
+
+仅在已授权的后续交付需要独立执行者时，使用 `Agent(subagent_type: "general-purpose", run_in_background: true)`，指定 worktree、责任范围及授权终点，要求调用 `ship-issue-pr`。子任务发现范围外问题先记录，不自动继续派发。

package/skills/ship-issue-pr/references/codex.md

@@ -0,0 +1,26 @@
+# Codex 运行时
+
+仅在 Codex 宿主确实需要 Claude 协作或已授权的后续委派时读取；交付范围、权限、验证复用与完成条件遵循共享流程。
+
+## Claude 路由
+
+| 工作 | 技能 |
+| --- | --- |
+| 方案咨询、普通审查、对抗审查 | [ask_cc](../../ask_cc/SKILL.md) |
+| 已明确范围的实现与修复 | [delegate-cc](../../delegate-cc/SKILL.md) 的 `task` 模式 |
+
+用户显式调用统一入口后，可在其任务范围内调用这些依赖。只读取当前模式的必要说明。CLI 参数、模型顺序、认证、权限、状态解析和接续规则由依赖技能维护，不在这里复制。
+
+`ask_cc` 的咨询模式无工具权限。交接提供问题、相关源码与 diff、路径和必要验证结果；首次完整审查覆盖本次 PR diff，后续只补增量及其影响，不要求咨询方自行读仓库。证据不足时主进程补充材料。
+
+独立审查不复用实现或修复会话；主进程自审不得冒充独立审查。报告 findings 的位置、条件、影响与建议，主进程核验关键证据。
+
+执行任务提供工作目录、可修改文件或模块、项目指令与实际验收命令。明确存在其他协作者，只负责分配范围，保留他人修改。需要运行验证时按依赖技能设置具体允许命令。
+
+## 等待、验收与后续任务
+
+保存会话 ID，读取同一任务的流式结果；静默或宿主单次等待超时先排查，接管前确保旧写进程停止。依赖缺失或确实无法运行时主进程接手可完成的剩余工作，报告实际执行者与未完成验证。
+
+可核实的验证结果按共享流程复用，不因来自其他执行者而全部重跑。
+
+仅在已授权的后续交付需要独立执行者时，使用 `spawn_agent` 的可用角色，prompt 指定独立 worktree、目标、授权终点和责任文件，并要求调用 `ship-issue-pr`。子任务发现范围外问题先记录，不自动继续派发。

package/skills/ship-issue-pr/references/core.md

@@ -0,0 +1,88 @@
+# Ship Issue PR Core
+
+这是 `ship-issue-pr` 的共享交付流程。按当前任务读取相关章节；平台工具调用由入口的运行时参考补充。
+
+## 执行边界与优先级
+
+在宿主系统与开发者指令约束内，当前任务的具体要求和已有授权 > 项目适用的 AGENTS.md > 本文件及其他通用技能。项目规定的验证、分支与合并要求继续适用。
+
+只读检索、本地草稿、可回滚编辑和常规测试自主推进。从相关文件和直接依赖开始，只有证据不足或影响跨模块时扩大范围。已给出的授权跨轮有效；不可逆或难以回滚的修改缺少具体授权时，先准备可审阅的 diff、正文和验证结果，再说明对象及影响并等待确认。对外发送消息须有明确授权。
+
+本技能默认把本次范围内的工作交付到 PR；用户明确要求仅本地修改、仅审查或继续到合并时，按该终点执行。单独调用技能不授权部署、数据操作、无关 Issue 或无限扩展任务。缺少目标事实时先从上下文与配置查证；能独立进行的工作继续，确实无法确定目标时才询问。
+
+## 状态与范围
+
+检查当前分支、工作区状态、相关 diff 和已有交付记录；需要远端操作时再核对 remote、Issue、PR 和认证。基线、命令、模板和 CI 从项目实际配置确定，不假定 main、特定 monorepo 路径或没有 PR 检查。
+
+工作区有改动不代表需求已完成：按验收标准识别已完成和剩余工作，复用成果。无关改动保持原样；不明归属的文件先避开，必要时在隔离 worktree 继续。只在必须修改且无法安全保留时澄清归属。工具或认证缺失只阻塞依赖它的操作，本地准备继续。
+
+按本次需求或 diff 检查直接相关的重复实现；没有证据时不扩大为全仓历史审计。
+
+## Issue、分支与正文
+
+优先复用任务、分支或已有 PR 指向的 Issue。项目要求 Issue 时，在提交或 PR 前补齐；本地准备无需等 Issue 创建。任务包含创建 Issue 时，先准备背景、目标、可验证的验收标准及依赖说明，再创建并读回。没有仓库模板时使用这些字段即可，缺模板不构成阻塞。
+
+采用项目分支规则和指定基线；无规则时为本次交付创建独立分支，遵守宿主的默认命名前缀。已有合规分支可继续。创建 worktree 时保留任务所需的未提交上下文，按项目实际 setup 准备依赖，不默认执行全量构建或同步私有环境文件。
+
+Issue/PR 多行正文写入本次任务独立的临时文件，用 `--body-file` 传递；提交说明可用 `git commit -F`。正文写明实际变更、验证命令和结果、遗留风险以及已有 Issue 关联。修正影响理解的占位内容，合法代码示例或引用中的 TODO 不当作未完成工作。
+
+## 实现与协作
+
+主进程直接处理能可靠完成的改动。公共契约、数据迁移、权限、并发、计费或跨模块协调等风险可以促使增加定向检查或独立意见；文件数和行数本身不强制切换模型、发问或扫描全仓。
+
+用户要求专家协作，或复杂问题确实需要独立证据且环境允许时，使用入口对应的运行时。交接包含目标、工作目录、责任文件、项目约束、已完成成果和验收命令。默认由主进程负责 Git/GitHub 交付，执行者仅修改分配文件；明确另行分配的授权按任务处理。
+
+咨询只提供建议，实现才授予必要写权限。不同执行者避免同时修改同一范围，可在不重叠文件上继续工作；无法隔离时使用独立 worktree。外部通道不可用时自行接手剩余工作并说明限制，用户明确要求的独立审查仍需如实标记未完成。
+
+## 委派活性与接管
+
+保存本次任务 ID、工作目录、输出来源和责任文件基线，持续观察同一任务。有效日志、工具进展或责任文件变化可以证明活动；只读任务不要求文件修改。
+
+单次等待超时或静默告警只触发诊断，检查原会话、子命令、权限等待与错误；重复空心跳不代表进展。确认失败或无法推进后优先恢复；接管前确认原执行者及其写进程已停止，再核对现有成果，仅完成剩余工作。遵守用户取消要求，不盲目重放任务或绕过权限拒绝。
+
+## 验证与证据复用
+
+按项目 AGENTS.md 和实际测试配置完成必需检查，选择与改动相关的最小充分范围。纯文档或局部样式不因通用表格自动触发跨端 lint、全仓构建或数据库操作。
+
+记录被验证的代码与输入、覆盖范围、命令、实际执行者和可读结果。未提交改动也属于输入；不能只用 HEAD 代表含本地修改的验证现场。证据详细程度以能够判断是否仍适用为准。
+
+- 内容、基线与相关输入未变：复用已有验收、审查和测试证据，包括可核实的其他执行者结果。
+- 仅 commit SHA 改变、内容相同：核对后关联新提交，不重跑相同检查。
+- 代码、验收标准、依赖或环境变化：检查增量及受影响调用方，仅补跑受影响项。
+- 来源或覆盖不足：补齐缺失检查；影响无法界定时再扩大到当前交付的完整 diff 和必要测试。
+
+测试通过不能替代代码审查。失败按复现、日志或基线证据归因；已知失败清单只是线索，未收录不代表本次引入。保留失败事实，修复任务范围内的问题，其他问题写明影响。
+
+测试若会清理共享数据库或改动共用资源，使用隔离环境，或沿用项目的互斥机制。不要把生产迁移当常规测试，也不要通过固定全局锁路径假定所有项目共享一套数据库。
+
+## 审查与修复
+
+首次审查覆盖本次完整 diff 及必要上下文；有效审查已有覆盖时只查增量和受影响部分。发现提供文件位置、触发条件、影响与修复建议，优先处理正确性、安全和验收缺口。
+
+独立审查使用未参与实现的上下文；自审按自审报告，不冒充外部审查。审查次数由新变化和未解决问题决定，不设“每 PR 最多一次”或“固定三轮”的通用额度，也不为凑轮次重复检查。
+
+修复后验证受影响行为，复用其余证据。提交按逻辑变更组织，不要求每条 finding 单独一个 commit。确认有效的重大问题未解决时不声称可合并；无法在范围内解决时保留具体原因与后续建议，不靠创建 Issue 把失败改成通过。
+
+## 提交与 PR
+
+执行任务已授权的提交和 PR 交付。暂存明确的本次文件，并核对暂存 diff，避免带入无关修改或凭据；提交钩子改变内容时补验受影响部分。
+
+复用已有 PR。创建或更新后读回标题、正文、base、head 和 URL，确认发布的是已验证内容；部分失败先查远端实际状态，只补剩余操作。检查当前项目实际要求的 CI，不沿用“本仓库没有 PR CI”的历史假设。
+
+依赖 PR 未合并时，继续可独立完成的实现、审查和草稿准备；只延后依赖它的集成或合并。需要判断冲突时优先使用只读比较或隔离 worktree，不为探测冲突修改用户当前工作树。
+
+## 合并与回访
+
+仅当当前任务授权包含合并时执行。合并前确认验收范围已满足、必需测试和 CI 通过、重大 findings 已解决；核对最新远端 head、base 与验证对象。变化使证据失效时补查增量。
+
+使用项目允许的合并方式，绑定已核验的 head（例如 gh 的 `--match-head-commit`）；保留分支保护，不能用管理员开关绕过。自动合并已设置不代表已合并，读回 `mergedAt` 与状态后再报告；异步检查仍在运行时准确说明等待原因。
+
+合并后按任务要求回访关联 Issue，确认实际验收与关闭状态。只有本次确实完成整个 Issue 时才使用关闭关联；对误关或剩余工作按已有授权修正并报告。
+
+## 后续工作与交付
+
+范围外问题先记录本地发现、影响和建议。任务已明确授权创建 follow-up Issue 或委派后续交付时才执行；每项沿用原授权边界，不递归扩大外部写操作或派发深度。
+
+已授权的独立后续任务使用各自责任范围与合适基线；依赖当前未合并改动时先准备，集成条件满足后继续。回收 worktree 前确认成果已保留、没有待整合改动，授权覆盖删除；squash 合并后不能仅凭分支名称判断可强删。
+
+最终报告实际终点、本次改动、验证、Issue/PR 链接及未完成项。已创建 PR、已设置自动合并、已合并和已回访分别陈述；仅本地任务以本地产物完成，不强制走到远端合并。