@weotro/dx 0.1.11 → 0.1.13

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/oo-ship-issue-pr/SKILL.md

@@ -1,12 +1,27 @@
 ---
 name: oo-ship-issue-pr
-description: 仅在用户显式调用 $oo-ship-issue-pr、/oo-ship-issue-pr 或明确要求使用 oo-ship-issue-pr 技能时使用；不要通过关键词、任务类型或上下文自动触发。
+description: 仅在显式调用 oo-ship-issue-pr 时使用：通过 Codex 与 Claude Code 交付 Issue/PR。
 ---
 
 # OO Ship Issue PR
 
+## 执行边界与优先级
+
+在宿主系统与开发者指令约束内，冲突时依次采用：当前任务的具体要求与已有授权 > 目标项目适用的 AGENTS.md > 本技能及其引用的通用流程。
+只读检索、本地草稿、可回滚编辑和常规测试可自主推断并继续；从相关文件和直接依赖开始，仅在证据不足或影响跨模块时扩大范围，复用仍有效的验证。
+仅在不可逆或难以回滚的修改缺少具体授权时，先完成预览、草稿与验证，再说明对象和影响并等待确认；会话中已有授权继续有效。缺少事实时先查证、标注假设并推进独立工作，确实无法确定操作目标时才询问。对外发送消息须有明确授权。
+
 Codex 入口：主进程执行轻改动；Claude 咨询与独立审查调用 [ask_cc](../ask_cc/SKILL.md)，重改动实现与修复调用 [delegate-cc](../delegate-cc/SKILL.md) 的 `task` 模式。调用、模型选择和降级均复用这两个技能。
 
+## 共享流程适配
+
+共享文件是通用参考，不覆盖本入口的执行边界。只读取当前阶段和必要约束；已完成的工作与验证直接复用。
+- 轻改动按涉及文件推进；复杂度信号用于判断是否值得咨询，不自动触发全仓扫描或固定全量构建。命令、基线、模板和 CI 要求从目标项目确定。
+- 当前任务优先于共享文件的硬门禁、阶段顺序和固定措辞；本地准备无需等 Issue、模板、外部专家或合并就绪。工具不可用时可自主接手并准确记录降级。
+- 不明归属的已有改动保留，先在隔离范围继续工作；仅在必须覆盖且归属无法查明时询问。测试失败依靠基线或复现证据归因，不能仅凭未列入已知失败清单就认定是本次引入。
+- Follow-up 先记为本地发现，只有任务授权包含创建 Issue、对外评论或委派后续交付时才执行这些动作。
+- 提交、PR、合并和回访按本次约定的终点执行；合并等难以回滚动作缺少具体授权时，准备好可审阅的结果后确认。
+
 ## 步骤一：加载共享流程
 
 ```bash
@@ -15,13 +30,13 @@ SHIP_CORE="$AGENTS_ROOT/references/ship-issue-pr-core.md"
 test -f "$SHIP_CORE"
 ```
 
-完整读取 `SHIP_CORE` 后执行全部阶段。运行时映射如下：
+读取 `SHIP_CORE` 中当前任务所需阶段，按本入口的适配规则执行。运行时映射如下：
 
 - 主进程：当前 Codex。
 - 外部专家：通过 `ask_cc` 或 `delegate-cc` 调用的 Claude Code；审查使用独立上下文，不复用实现或修复会话。
 - 入口显示名：`OO Ship Issue PR`。
 - Follow-up：Codex `spawn_agent` 的 `worker` 角色。
 
-第一次进入外部专家或 follow-up 分支前，完整读取 [references/runtime.md](references/runtime.md)。该文件是本入口的平台调用契约；共享流程仍是交付语义的唯一真源。
+仅在进入外部专家或已授权的 follow-up 分支时读取 [references/runtime.md](references/runtime.md)。该文件是本入口的平台调用契约；共享流程提供交付参考，冲突按本入口的优先级解决。
 
-只有共享流程全部完成且 `mergedAt` 非空、Issue 回访完成，才输出 `OO Ship Issue PR 完成`。
+按当前任务约定的终点报告完成；只有实际 `mergedAt` 非空并完成 Issue 回访时才声称已合并并回访。

package/skills/oo-ship-issue-pr/references/runtime.md

@@ -4,7 +4,7 @@
 
 ## Claude 技能路由
 
-用户显式调用 `oo-ship-issue-pr` 后，按下表调用其依赖技能。先完整读取对应 `SKILL.md`，再执行其中的流程；路径相对于本文件，`dx initial` 会将这些技能安装在同一个 skills 根目录下。
+用户显式调用 `oo-ship-issue-pr` 后，按下表调用其依赖技能。读取对应 `SKILL.md` 的当前模式与必要约束，再执行适用流程；路径相对于本文件，`dx initial` 会将这些技能安装在同一个 skills 根目录下。
 
 | 共享流程阶段 | 调用技能 | 本阶段目标 |
 |---|---|---|
@@ -13,7 +13,9 @@
 | 阶段 7.3 adversarial review | [ask_cc](../../ask_cc/SKILL.md) | 挑战假设、不变量、反例与失败路径 |
 | 阶段四重改动实现、阶段 7.4 重修复 | [delegate-cc](../../delegate-cc/SKILL.md) 的 `task` 模式 | 按最终方案修改代码并提供验证结果 |
 
-本入口只补充交付上下文与验收要求。CLI 参数、模型顺序、权限配置、等待与超时、状态解析、接续及降级统一按依赖技能执行，不在这里另写调用脚本或重试链。依赖文件缺失时先运行 `dx initial` 恢复；仍无法读取时报告缺失路径，不临时仿写该技能。
+本入口只补充交付上下文与验收要求。CLI 参数、模型顺序、权限配置、等待与超时、状态解析、接续及降级统一按依赖技能执行，不在这里另写调用脚本或重试链。依赖文件缺失时先定位现有安装；确需恢复且在任务范围内时使用 `dx initial`。依赖仍不可用时由主进程继续可完成的实现或自审，说明缺失能力，不冒充外部审查。
+
+所有通道（含 follow-up）遵守共享流程的「委派活性与接管」规则。依赖脚本的 `--timeout` 是无活动告警阈值；读取其 PID、输出字节和文件观测摘要，疑似停滞时检查原会话与工作树。宿主单次等待结束后继续观察同一会话，不设置按总耗时自动终止的外层超时器，也不把尚未返回当作降级依据。
 
 ## 交接上下文
 
@@ -37,7 +39,7 @@
 
 取得结果、等待停止、处理部分改动、接续或降级均按依赖技能执行。主进程取得最终结果后直读源码和 diff，核验结论、合并重复项并记录拒绝依据；仅派发成功或返回成功声明不算阶段完成。
 
-外部执行者的验证仅作参考。交接材料附本阶段需补跑的清单，并要求报告未运行的验证及原因；权威验证由 Codex 主进程执行并阅读输出。主进程已有验证按共享流程的证据复用规则承接，后续阶段只补跑缺失或失效项。
+外部执行者提供命令、代码版本、环境与可读输出后，主进程核对证据并复用有效结果；只补跑缺失、失效或无法核实的验证。报告未运行项及实际原因，不因执行者身份重复全部测试。
 
 阶段 7.3 仍服从共享流程的证据复用、复杂度门禁和每 PR 最多一次外部专家审查约束。创建 PR 前已有的独立外部审查也继续计数并按覆盖范围复用；同一阶段因证据不足补充材料或按依赖技能降级，不能被当作后续轮次重新派发审查的额度。
 

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/stagewise-ui-debugging/SKILL.md

@@ -1,17 +1,23 @@
 ---
 name: stagewise-ui-debugging
-description: 仅在用户显式调用 $stagewise-ui-debugging 或明确要求使用 stagewise-ui-debugging 技能时使用；不要通过关键词、任务类型或上下文自动触发。
+description: 仅在显式调用 stagewise-ui-debugging 时使用：对比 Stagewise 设计稿与前端 UI。
 ---
 
 # Stagewise UI 调试
 
+## 执行边界与优先级
+
+在宿主系统与开发者指令约束内，冲突时依次采用：当前任务的具体要求与已有授权 > 目标项目适用的 AGENTS.md > 本技能及其引用的通用流程。
+只读检索、本地草稿、可回滚编辑和常规测试可自主推断并继续；从相关文件和直接依赖开始，仅在证据不足或影响跨模块时扩大范围，复用仍有效的验证。
+仅在不可逆或难以回滚的修改缺少具体授权时，先完成预览、草稿与验证，再说明对象和影响并等待确认；会话中已有授权继续有效。缺少事实时先查证、标注假设并推进独立工作，确实无法确定操作目标时才询问。对外发送消息须有明确授权。
+
 ## 概览
 
 用于对齐 `design/ui_kits/app/` 设计稿和 `apps/front` 前端页面。核心原则：改 UI 前先在相同视口下，对比 Stagewise 包装后的设计站和前端站。
 
 ## 速查
 
-| 目标 | 用户可能需要手动运行 | 访问地址 |
+| 目标 | 未启动时的候选命令 | 默认访问地址 |
 | --- | --- | --- |
 | 设计稿 | `dx start stagewise-design-system` | `http://localhost:8766/ui_kits/app/` |
 | 前端页面 | `dx start stack-front` | `http://localhost:3002` |
@@ -20,22 +26,22 @@ description: 仅在用户显式调用 $stagewise-ui-debugging 或明确要求使
 
 ## 流程
 
-1. 使用浏览器前，提醒用户这两个服务可能已经启动；如果没启动，可以手动运行：
+1. 从项目配置核实地址并检查服务状态，复用已启动的实例。缺少服务时，根据项目实际命令自主启动所需的本地开发服务；默认命令示例：
    ```bash
    dx start stagewise-design-system
    dx start stack-front
    ```
-2. 用浏览器工具访问两个 Stagewise 地址。若页面打不开、空白、或无法渲染，提示用户对应服务可能没启动或状态异常，让用户手动处理后再访问。
-3. 在相同浏览器视口下对比设计稿和前端。桌面和移动端宽度都要看；视口不同会造成假的对齐差异。
+2. 用浏览器工具访问所需页面。打不开、空白或渲染异常时，自行检查端口、启动日志和依赖，修复可回滚的本地问题后重试；需要用户凭据或交互时说明具体阻塞。
+3. 在相同浏览器视口下对比本次涉及的组件或页面。响应式改动检查桌面和移动端；单一断点修改先验证该断点，影响布局时再扩展。
 4. 检查 DOM 时记住：两个页面都经过 Stagewise 包装。包装节点、桥接覆盖层、注入属性可能和裸应用 DOM 不同。优先做视觉对比和稳定的应用层选择器检查；编辑前先确认样式来自产品 UI，而不是 Stagewise 外壳。
 5. 修改后端或前端页面后，页面会自动刷新到最新状态。需要确认时重新查看或刷新浏览器对比，不要先急着重启服务。
-6. 如果任务涉及真实 UI 实现，以仓库设计规则为准：`design/readme.md`、`design/SKILL.md`、`ruler/design-system.md`。
+6. 如果任务涉及真实 UI 实现，按项目指令读取涉及组件的设计规则；`design/readme.md`、`design/SKILL.md`、`ruler/design-system.md` 仅在实际存在且与本次修改相关时读取。
 
 ## 触发示例
 
 用户说：“调一下前端和设计稿的卡片间距。”
 
-动作：加载本技能，提醒用户两个 `dx start` 命令，打开 `8766/ui_kits/app/` 和 `3002`，设置相同桌面和移动端视口，视觉对比后再按需要修改前端或设计源。
+用户显式调用本技能后，检查服务、定位该卡片并在同一视口对比，修改间距并验证受影响的布局。普通间距调整不自动加载本技能。
 
 ## 常见误区
 

package/skills/stagewise-ui-debugging/agents/openai.yaml

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