@weotro/dx 0.1.12 → 0.1.13

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@weotro/dx",
-  "version": "0.1.12",
+  "version": "0.1.13",
   "type": "module",
   "license": "MIT",
   "repository": {

package/skills/AUDIT.md

@@ -0,0 +1,48 @@
+# Skills 执行规则审计
+
+本次覆盖 `skills/` 下全部 11 个技能、相关 Markdown 引用和调用元数据。以下引文来自修改前版本，可通过 Git diff 核对。这里判断的是规则在当前任务中的效果；仅凭文字不能证明其作者当初是为某一旧模型设计，也未进行 Astra 行为基准测试。
+
+## 统一结果
+
+在宿主系统与开发者指令约束内，采用当前具体任务及已有授权 > 项目适用的 AGENTS.md > 通用技能与引用流程。只读检索、本地草稿、可回滚编辑和常规测试自主推进；不可逆或难以回滚且未获具体授权的操作，先完成预览和验证再确认。既有授权跨轮有效；真正无法确定目标时仍需澄清，对外消息仍需明确授权。
+
+检索从相关文件和直接依赖开始，按证据扩展；复用有效验证。全部 description 收敛为显式调用条件与一句用途，保留原有显式调用策略，并为原来缺少 agents/openai.yaml 的 4 个技能补齐 allow_implicit_invocation: false。依赖技能的路由细节放在正文。
+
+## 逐技能原句与处理
+
+| 技能 | 修改前原句 | 判断与处理 |
+| --- | --- | --- |
+| ask_cc | “调用前完整读取该技能，按其中的活性监控、诊断和接续规则执行。” | 咨询入口强制加载全部执行分支；改为读取咨询调用与结果处理，诊断、接续按需读取。保留脚本超时和模型降级的真实运行语义。 |
+| cc-ship-issue-pr | “完整读取 `SHIP_CORE` 后执行全部阶段。” | 不区分任务终点与已完成阶段；改为按当前任务读取和执行，并明确共享流程低于任务和项目规则。 |
+| delegate-cc | “执行前检查 `git status --short` 和已有 diff，记录涉及文件的初始状态及未跟踪文件。” | 未限定 diff 范围，可能把无关改动也拉入上下文；改为任务文件的 diff 和相关未跟踪文件。保留责任隔离及停止旧写进程后接管的必要约束。 |
+| delivering-design-handoff | “If the user asks to save time by writing the plan while review or fixes are pending, decline that shortcut and finish this gate first.” | 明确要求拒绝用户的并行草稿安排，倒置优先级；移除强制串行审查门禁，允许草稿并行，交付前核对一致性。 |
+| doctor | “所有项目完成后运行一次最终复检。” | 与每次修复后的复检叠加，单项修复也可能拉入全套环境检查；改为按任务范围检查、复用健康证据，只补失效或缺失项。 |
+| gh-dependabot-cleanup | “Confirm target and scope in one sentence.” | Confirm 容易被解释成等待确认；改为从任务与 remote 推断并说明后继续取证。本地修复不强制 commit、push 和 PR。 |
+| git-release | “若存在未提交变更，列出文件并终止流程。” | 无关草稿也阻断发布准备；改为保护改动、必要时隔离 worktree，继续本地准备。冲突 tag 仍阻止不安全发布。 |
+| online-debug-guard | “当且仅当目标环境是 `production` 时，必须确认当前处于 Plan 模式。” | 把生产只读取证绑定交互模式；移除 Plan 门禁，按操作副作用与已有授权判断。 |
+| oo-ship-issue-pr | “完整读取 `SHIP_CORE` 后执行全部阶段。” | 同 CC 入口；增加适配规则，避免小任务被固定阶段、外部专家和全量验证阻断。 |
+| prune-git-repository | “Require explicit current-turn authorization for the exact cleanup categories and thresholds.” | 跨轮丢弃授权，预览前就要求确认；改为先自主 dry-run，已有授权覆盖预览删除清单即可执行，新增删除范围才确认。 |
+| stagewise-ui-debugging | “若页面打不开、空白、或无法渲染，提示用户对应服务可能没启动或状态异常，让用户手动处理后再访问。” | 可本地修复的问题直接交回用户；改为自行检查端口、日志和依赖，启动或修复所需服务后重试。 |
+
+## 其他收敛项
+
+- 设计交接原句：“Do not create or update a PR for the docs-only handoff branch as part of this workflow, even when the repository's normal implementation flow expects PRs.” 改为服从用户或项目对 PR 的要求，不把通用技能放在项目之上。固定三份文档、两轮 subagent 审查和多次同样的占位扫描改为按任务规模组织产物和检查。
+- 在线调试原句：“先询问用户当前环境。”、“若无法确认，则默认 `development`”。改为先从任务、配置、SSH 映射核实；仍不唯一时才询问，未知环境不假定为开发环境。接受项目环境别名。
+- CC runtime 原句：“Codex 沙箱不能绑本地端口、不能起 PostgreSQL 共享内存、不能写主仓 `.git` index、无网络下载。” 改为根据实际宿主能力判断，不复制历史沙箱限制及固定跨端补跑清单。
+- CC runtime 原句：“等待期间工作树由 Codex 独占，主进程只做不写工作树的并行事项。” 改为独占分配的责任文件，其他不重叠工作可继续；文件观测限定责任路径。
+- CC runtime 原句：“重改动实现通道不可用时阻塞”。改为主进程接手剩余工作并如实说明执行者。
+- OO runtime 原句：“外部执行者的验证仅作参考。” 改为核对版本、环境、命令和可读输出后复用有效证据，只补缺失或失效验证。
+- 清理原句：“require zero remaining candidates”、“Verify ... a clean current worktree”。改为验证本次授权范围，允许保留保护对象和无关脏文件，不为达到零候选扩大删除。
+- 保留清理脚本的 dry-run、保护 refs、远端读回、精确 refspec 等实际数据保护，以及委派脚本的权限与接续契约；未修改可执行脚本。
+
+## 范围与验证
+
+目录外的 `agent-references/ship-issue-pr-core.md` 未修改。两个交付入口明确其适配优先级，旧共享流程中的硬门禁、固定验证矩阵和自动 follow-up 扩张不能覆盖当前任务。若有人绕过入口直接使用该共享文件，其旧文字仍存在。
+
+同步修改 `test/skill-metadata.test.js`：以 YAML 中实际的显式调用策略验证调用边界，不再依赖 description 中的固定句子。
+
+- `pnpm test`：50 个测试套件、414 项测试全部通过。
+- `git diff --check`：通过。
+- `quick_validate.py`：10 个技能通过；`ask_cc` 仅因原有下划线名称未通过 hyphen-case 校验，保留兼容入口，未改名。
+- 未触发技能的真实发布、远程清理或生产调试；文档规则的模型行为效果仍需后续实际使用验证。
+

package/skills/ask_cc/SKILL.md

@@ -1,13 +1,21 @@
 ---
 name: ask_cc
-description: 仅在用户显式调用 $ask_cc 或明确要求使用 ask_cc 技能，或用户已显式调用的 oo-ship-issue-pr 流程要求咨询时使用；不要通过关键词、任务类型或上下文自动触发。
+description: 仅在显式调用 ask_cc 时使用：咨询 Claude Code 获取第二意见。
 ---
 
 # ask_cc
 
+## 执行边界与优先级
+
+在宿主系统与开发者指令约束内，冲突时依次采用：当前任务的具体要求与已有授权 > 目标项目适用的 AGENTS.md > 本技能及其引用的通用流程。
+只读检索、本地草稿、可回滚编辑和常规测试可自主推断并继续；从相关文件和直接依赖开始，仅在证据不足或影响跨模块时扩大范围，复用仍有效的验证。
+仅在不可逆或难以回滚的修改缺少具体授权时，先完成预览、草稿与验证，再说明对象和影响并等待确认；会话中已有授权继续有效。缺少事实时先查证、标注假设并推进独立工作，确实无法确定操作目标时才询问。对外发送消息须有明确授权。
+
 使用 [delegate-cc](../delegate-cc/SKILL.md) 的咨询流程获取答案或第二意见，默认不授予工具权限。
 
-调用前完整读取该技能，按其中的活性监控、诊断和接续规则执行。咨询没有文件修改是正常现象，以本次会话的流式输出和进程状态辅助判断；静默只触发排查，不能仅因尚无答案就停止或换模型。
+已显式调用的 `oo-ship-issue-pr` 需要咨询时可进入本技能，沿用原任务范围与授权。
+
+调用前读取该技能的咨询调用与结果处理部分，按需查看诊断和接续规则。咨询没有文件修改是正常现象，以本次会话的流式输出和进程状态辅助判断；静默只触发排查，不能仅因尚无答案就停止或换模型。
 
 若用户明确要求修改代码或执行开发任务，转入该技能的 `task` 模式，按任务范围完成实现和验收。
 

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

@@ -1,12 +1,27 @@
 ---
 name: cc-ship-issue-pr
-description: 仅在用户显式调用 $cc-ship-issue-pr、/cc-ship-issue-pr 或明确要求使用 cc-ship-issue-pr 技能时使用，派发 follow-up 交付的 subagent 也从这里进入；不要通过关键词、任务类型或上下文自动触发。
+description: 仅在显式调用 cc-ship-issue-pr 时使用：通过 Claude Code 与 Codex 交付 Issue/PR。
 ---
 
 # CC Ship Issue PR
 
+## 执行边界与优先级
+
+在宿主系统与开发者指令约束内，冲突时依次采用：当前任务的具体要求与已有授权 > 目标项目适用的 AGENTS.md > 本技能及其引用的通用流程。
+只读检索、本地草稿、可回滚编辑和常规测试可自主推断并继续；从相关文件和直接依赖开始，仅在证据不足或影响跨模块时扩大范围，复用仍有效的验证。
+仅在不可逆或难以回滚的修改缺少具体授权时，先完成预览、草稿与验证，再说明对象和影响并等待确认；会话中已有授权继续有效。缺少事实时先查证、标注假设并推进独立工作，确实无法确定操作目标时才询问。对外发送消息须有明确授权。
+
 Claude Code 入口：主进程执行轻改动，Codex 承接重改动的方案讨论、实现与独立审查。
 
+## 共享流程适配
+
+共享文件是通用参考，不覆盖本入口的执行边界。只读取当前阶段和必要约束；已完成的工作与验证直接复用。
+- 轻改动按涉及文件推进；复杂度信号用于判断是否值得咨询，不自动触发全仓扫描或固定全量构建。命令、基线、模板和 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` 中当前任务所需阶段，按本入口的适配规则执行。运行时映射如下：
 
 - 主进程：当前 Claude Code。
 - 外部专家：Codex。
 - 入口显示名：`CC Ship Issue PR`。
 - Follow-up：Claude Code `Agent(subagent_type: "general-purpose", run_in_background: true)`。
 
-第一次进入外部专家或 follow-up 分支前，完整读取 [references/runtime.md](references/runtime.md)。该文件是本入口的平台调用契约；共享流程仍是交付语义的唯一真源。
+仅在进入外部专家或已授权的 follow-up 分支时读取 [references/runtime.md](references/runtime.md)。该文件是本入口的平台调用契约；共享流程提供交付参考，冲突按本入口的优先级解决。
 
-只有共享流程全部完成且 `mergedAt` 非空、Issue 回访完成，才输出 `CC Ship Issue PR 完成`。
+按当前任务约定的终点报告完成；只有实际 `mergedAt` 非空并完成 Issue 回访时才声称已合并并回访。

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

@@ -4,7 +4,7 @@
 
 ## Codex 通道
 
-Codex 永远不碰 Git 历史和 GitHub。它把改动落在工作树，由 Claude Code 主进程核验、验证和分组提交。
+默认由主进程负责 Git 历史和 GitHub，除非当前任务明确另行分配责任。它把改动落在工作树，由 Claude Code 主进程核验、验证和分组提交。
 
 - **方案讨论 / 实现 / 重修复**：`Agent(subagent_type: "codex:codex-rescue")`。
 - **普通 review**：Codex companion 的 `review` 子命令。
@@ -33,9 +33,7 @@ CODEX_ROOT=$(/bin/ls -d ~/.claude/plugins/marketplaces/openai-codex/plugins/code
 
 ## 补跑清单
 
-Codex 沙箱不能绑本地端口、不能起 PostgreSQL 共享内存、不能写主仓 `.git` index、无网络下载。派发 prompt 原文附上以下主进程补跑项：
-
-`dx db migrate`（实 apply）、后端 E2E、`dx build front --dev`、`flutter test`、Dart OpenAPI 生成（要下 Maven）、`git commit`。
+根据实际宿主权限与项目命令判断哪些验证可运行，不预设 Codex 的沙箱能力。只列本次改动需要且外部执行者无法完成的补跑项；迁移实 apply 不属于常规测试，先确认隔离环境与授权。
 
 ## 取结果
 
@@ -59,12 +57,12 @@ PY
 
 ## 等待与活性排查
 
-所有通道（含 follow-up）遵守共享流程的「委派活性与接管」规则。等待期间工作树由 Codex 独占，主进程只做不写工作树的并行事项。
+所有通道（含 follow-up）遵守共享流程的「委派活性与接管」规则。等待期间 Codex 独占分配的责任文件，主进程可继续不重叠的工作；责任无法隔离时使用独立 worktree。
 
 派发后保存本次 job/agent ID、worktree 和日志路径；上方按仓库列举 job 的脚本只用于发现候选，结合派发时间与任务信息确认后固定 ID，后续不得自动改查最新 job。保存派发基线，约每 2 分钟比较：
 
 - 本次 job 的新增日志、工具事件、输出正文，以及 `status` / `phase` 的实际变化。状态文件 mtime 刷新但内容未变不算进展。
-- 本次责任文件的内容变化：比较 `git diff --binary HEAD` 的内容指纹，并记录相关未跟踪文件的内容指纹；删除、新增、同一脏文件的再次修改都应被识别。只读审查不要求有文件修改。
+- 本次责任文件的内容变化：比较责任文件的 `git diff --binary HEAD -- <paths>` 内容指纹，并记录相关未跟踪文件的内容指纹；删除、新增、同一脏文件的再次修改都应被识别。只读审查不要求有文件修改。
 - 当前子命令与进程状态、权限请求或外部依赖等待。观测失败记为未知，不能当作无活动。
 
 连续多个观测窗口没有进展时，读取日志尾部和子命令状态，向原 agent 查询当前步骤及阻塞点；这个条件只触发排查，不触发停止或换执行者。重复错误、空心跳或无关文件变化不能证明任务在推进。
@@ -78,7 +76,7 @@ companion 的 `review --wait` / `adversarial-review --wait` 也通过宿主异
 - 阶段 7.3：先按共享流程复用已有审查；复杂度门禁命中且本次交付尚未用过 Codex 独立审查时执行 review（创建 PR 前的审查也计数）；需要挑战方案时执行 adversarial review。
 - reviewer：`Claude Code 主进程自审 / codex native review / codex adversarial review / codex 只读 subagent`。
 
-Codex 返回后主进程必须直读源码和 diff 核验，不采信转述。重改动实现通道不可用时阻塞；条件式独立审查不可用时由主进程完成本轮自审并在报告标明降级。
+Codex 返回后主进程必须直读源码和 diff 核验，不采信转述。重改动实现通道不可用时由主进程接手剩余工作并注明实际执行者；条件式独立审查不可用时由主进程完成本轮自审并在报告标明降级。
 
 ## Follow-up
 

package/skills/delegate-cc/SKILL.md

@@ -1,18 +1,26 @@
 ---
 name: delegate-cc
-description: 仅在用户显式调用 $delegate-cc 或明确要求使用 delegate-cc 技能，或已获用户调用授权的 ask_cc、oo-ship-issue-pr 流程要求委派时使用；不要通过关键词、任务类型或上下文自动触发。
+description: 仅在显式调用 delegate-cc 时使用：委派 Claude Code 执行开发任务或咨询。
 ---
 
 # delegate-cc
 
+## 执行边界与优先级
+
+在宿主系统与开发者指令约束内，冲突时依次采用：当前任务的具体要求与已有授权 > 目标项目适用的 AGENTS.md > 本技能及其引用的通用流程。
+只读检索、本地草稿、可回滚编辑和常规测试可自主推断并继续；从相关文件和直接依赖开始，仅在证据不足或影响跨模块时扩大范围，复用仍有效的验证。
+仅在不可逆或难以回滚的修改缺少具体授权时，先完成预览、草稿与验证，再说明对象和影响并等待确认；会话中已有授权继续有效。缺少事实时先查证、标注假设并推进独立工作，确实无法确定操作目标时才询问。对外发送消息须有明确授权。
+
 把 Claude Code 当作协作者。模型顺序固定为 Fable 5.1（`claude-fable-5-1`）→ Opus 5（`claude-opus-5`）→ 当前 sub-agent。保留本机现有认证。
 
+已显式调用的 `ask_cc` 或 `oo-ship-issue-pr` 需要委派时可进入本技能，沿用原任务范围与授权。
+
 ## 1. 准备交接
 
 - **咨询 `consult`**：用户需要答案、决策建议或评审意见。提供问题、相关代码或事实、约束；CLI 无工具权限，只返回建议。
 - **执行 `task`**：用户要求实现、修复或把开发任务交给 CC。任务书必须包含工作目录、目标、可修改文件或模块、适用的项目指令、验收标准和仓库实际验证命令。明确告知 CC 还有其他协作者，保留他人的改动，只负责分配范围。
 
-执行前检查 `git status --short` 和已有 diff，记录涉及文件的初始状态及未跟踪文件。分配互不重叠的文件；需要并发改同一文件时，先拆分责任或使用独立 worktree，指定由谁整合。worktree 不会自动携带未提交改动，必须提供任务所需的当前版本。CC 执行期间，主 agent 不同时修改其负责的文件。
+执行前检查 `git status --short` 和任务涉及文件的 diff，记录这些文件的初始状态及相关未跟踪文件。分配互不重叠的文件；需要并发改同一文件时，先拆分责任或使用独立 worktree，指定由谁整合。worktree 不会自动携带未提交改动，必须提供任务所需的当前版本。CC 执行期间，主 agent 不同时修改其负责的文件。
 
 将任务书写入临时 UTF-8 文件，只传必要上下文，排除凭据。完成条件：CC 无需当前对话即可理解目标、权限范围与完成标准。
 
@@ -30,7 +38,7 @@ python3 "$HOME/.agents/skills/delegate-cc/scripts/delegate_cc.py" --prompt-file
 python3 "$HOME/.agents/skills/delegate-cc/scripts/delegate_cc.py" --mode task --cwd /绝对路径/工作区 --prompt-file /绝对路径/任务.txt
 ```
 
-需要 CC 自行运行验证命令时，按本次授权追加 `--allow-command '仓库实际验证命令'`，可重复传入。使用具体命令而非开放全部 Bash；检查命令本身及其调用脚本的作用。现有 Claude Code 权限规则仍生效，`--allow-command` 只是增加允许规则，不是独立沙箱。文件责任范围通过任务书和验收控制，需要隔离时使用 worktree 或已有沙箱。
+需要 CC 自行运行验证命令时，按本次授权追加 `--allow-command '仓库实际验证命令'`，可重复传入。使用具体命令而非开放全部 Bash；根据命令和已知脚本判断副作用，仅对未知或可能破坏数据的脚本进一步检查。现有 Claude Code 权限规则仍生效，`--allow-command` 只是增加允许规则，不是独立沙箱。文件责任范围通过任务书和验收控制，需要隔离时使用 worktree 或已有沙箱。
 
 执行模式保留默认编码系统提示，开放 `Read,Glob,Grep,Edit,Write,Bash`，使用 `acceptEdits`，不能获批的工具请求自动拒绝。两种模式都关闭 hooks、MCP 和技能，避免额外任务链；主 agent 应把所需项目规则及技能要求写入任务书。本技能不使用 `bypassPermissions`，也不扩大任务至提交、推送、部署或对外发送消息。
 

package/skills/delivering-design-handoff/SKILL.md

@@ -1,290 +1,33 @@
 ---
 name: delivering-design-handoff
-description: 仅在用户显式调用 $delivering-design-handoff 或明确要求使用 delivering-design-handoff 技能时使用；不要通过关键词、任务类型或上下文自动触发。
+description: 仅在显式调用 delivering-design-handoff 时使用：整理设计、实施计划与工程交接资料。
 ---
 
 # Delivering Design Handoff
 
-## Overview
+## 执行边界与优先级
 
-Turn an approved design into a ready-to-assign engineering package with one closed loop: spec, spec review and fixes, implementation plan, plan review and fixes, handoff doc, issue, branch, commit, push, issue assignment comment, and copyable assignment text.
+在宿主系统与开发者指令约束内，冲突时依次采用：当前任务的具体要求与已有授权 > 目标项目适用的 AGENTS.md > 本技能及其引用的通用流程。
+只读检索、本地草稿、可回滚编辑和常规测试可自主推断并继续；从相关文件和直接依赖开始，仅在证据不足或影响跨模块时扩大范围，复用仍有效的验证。
+仅在不可逆或难以回滚的修改缺少具体授权时，先完成预览、草稿与验证，再说明对象和影响并等待确认；会话中已有授权继续有效。缺少事实时先查证、标注假设并推进独立工作，确实无法确定操作目标时才询问。对外发送消息须有明确授权。
 
-**Core principle:** after the design is approved, the user should not have to restate the delivery choreography. Each review gate must be completed and fixed before the next artifact is written.
+把已有设计整理为可交给工程师实施的文档。沿用已讨论的方向；尚有局部空缺时写明假设并继续草稿，不重新启动整轮设计问答。
 
-## When To Use
+## 文档与检查
 
-Use this only after the solution direction is already approved. If the design is still being explored, first use `brainstorming`.
+按项目惯例选择路径；无既有约定时使用：
+- 设计：`docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`，说明目标、方案、接口、兼容性、风险与验收标准。
+- 计划：`docs/superpowers/plans/YYYY-MM-DD-<topic>.md`，列出涉及文件、实现顺序、关键接口与实际验证命令。
+- 交接：`docs/superpowers/handoffs/YYYY-MM-DD-<topic>-handoff.md`，提供文档链接、实施顺序、风险和完成标准。小任务可按用户或项目要求合并文档。
 
-Typical user asks:
+设计、计划和交接草稿可并行完善；交付前核对三者一致性，修正实际影响实施的缺口。根据复杂度选择自审或独立审查，已有有效审查可复用；审查工具不可用时自行检查并注明限制。仅在需要相应写作方法且技能可用时读取 `brainstorming` 或 `writing-plans` 的相关章节。
 
-- “把这个方案写成设计文档并提 issue”
-- “写计划和交接文档，提交到 issue 分支”
-- “后续不想重复输入，从设计文档到 issue/分支/提交都自动做”
-- “给我一段可以直接复制给工程师的任务分配文字”
+## 交付
 
-## Required Output Contract
+1. 检查相关项目指令、分支及本次涉及文件的状态，保护已有改动。
+2. 完成任务要求的文档，检查关键接口、验收标准和失效链接；真实未决项标明假设与影响。
+3. 需要 Issue、提交、推送或分配评论时，先准备正文与明确文件清单，再按任务授权执行。只要求本地交接时，本地文档即可完成。
+4. 需要分支时从项目规定的基线创建，保留现有工作；按明确路径暂存并检查 diff。多行正文用临时文件与 `--body-file` 或 `git commit -F` 传递。
+5. 已授权发布交接评论时，包含分支、提交、文档链接和可复制的任务分配文字，并读回核对。用户或项目要求 PR 时，纳入本次交付。
 
-By the end, produce all of these or clearly state the blocker:
-
-| Item | Required shape |
-| --- | --- |
-| Design spec | `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`, created using the design-doc discipline from `brainstorming` |
-| Spec adversarial review | Reviewer subagent completed before the plan exists; valid findings applied to the spec, or explicit rejected findings with reasons |
-| Implementation plan | `docs/superpowers/plans/YYYY-MM-DD-<topic>.md`, created by using `writing-plans` |
-| Plan adversarial review | Reviewer subagent findings applied to the plan, or explicit rejected findings with reasons |
-| Handoff doc | `docs/superpowers/handoffs/YYYY-MM-DD-<topic>-handoff.md` |
-| GitHub issue | Structured issue with background, goals, plan, acceptance criteria, and doc paths |
-| Issue branch | `codex/docs/<issue-id>-<slug>` for docs-only handoff, or matching repo convention |
-| Commit | Conventional commit ending with `Refs: #<issue-id>` |
-| Push | Branch pushed with upstream |
-| Issue comment | Comment linking branch, commit, spec, plan, and handoff, plus the same project-manager-style assignment block from the final answer |
-| Final answer | Short status plus a copyable project-manager-style assignment block |
-
-## Workflow
-
-### 1. Confirm starting state
-
-- Read project instructions: `AGENTS.md`, referenced ruler docs, and git workflow docs.
-- Check branch and worktree:
-
-```bash
-rtk git status --short --branch
-rtk git remote -v
-rtk gh auth status
-```
-
-- If there are unrelated dirty changes, do not overwrite them. If the handoff docs are the only dirty files, continue.
-
-### 2. Write the design spec
-
-Use `brainstorming` for the design-document phase. If the conversation already contains an approved design, do not restart exploratory questioning; treat that approved discussion as the input and apply `brainstorming`'s write-design-doc and self-review standards.
-
-Create `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`.
-
-Spec sections:
-
-- Background
-- Goals
-- Non-goals
-- Chosen approach and rejected alternatives
-- Backend/frontend/data/API design as applicable
-- Error handling
-- Testing and verification
-- Compatibility and risks
-- Acceptance criteria
-
-Run a self-review:
-
-```bash
-rtk rg -n "TBD|TODO|待定|占位|\\.\\.\\." <spec-path>
-```
-
-Fix every hit that is a placeholder. A literal example such as `new BasePaginationResponseDto(total, page, limit, items)` is allowed; vague ellipses are not.
-
-### 3. Dispatch adversarial review
-
-Spawn one reviewer subagent. The prompt must include:
-
-- spec path
-- repo root
-- current approved design context
-- review axes: correctness, missing edge cases, repo convention violations, testability, and handoff ambiguity
-- “read-only, do not modify files”
-
-Apply all valid findings to the spec. If rejecting a finding, record the reason in the handoff doc's review notes and mention it briefly in the final answer only if material.
-
-**Gate before planning:** do not create the implementation plan until the reviewer subagent has returned, every valid spec finding has been fixed, every rejected finding has a recorded reason, and the spec placeholder scan has passed again. If the reviewer subagent is still running, timed out, or failed, this gate is not complete. If the user asks to save time by writing the plan while review or fixes are pending, decline that shortcut and finish this gate first.
-
-### 4. Create the implementation plan
-
-Announce and use `writing-plans`:
-
-> I'm using the writing-plans skill to create the implementation plan.
-
-Start this step only after Step 3 is complete.
-
-Create `docs/superpowers/plans/YYYY-MM-DD-<topic>.md` using the `writing-plans` required structure:
-
-- header with goal, architecture, tech stack, and global constraints
-- file map before tasks
-- bite-sized tasks with exact files, interfaces, steps, commands, and expected results
-- self-review for spec coverage, placeholders, and type consistency
-
-Run placeholder scan:
-
-```bash
-rtk rg -n "TBD|TODO|待定|占位|\\.\\.\\." <plan-path>
-```
-
-Fix every true placeholder. Do not proceed to handoff until the plan can guide an engineer without asking back.
-
-### 5. Dispatch plan adversarial review
-
-Spawn one reviewer subagent for the plan. The prompt must include:
-
-- spec path
-- plan path
-- repo root
-- review axes: spec coverage, task order, file ownership, testability, missing code/commands, placeholders, type/interface consistency, and repo convention violations
-- “read-only, do not modify files”
-
-Apply all valid findings to the plan. If a finding reveals a spec defect, fix the spec too and re-check plan consistency.
-
-### 6. Write the handoff document
-
-Create `docs/superpowers/handoffs/YYYY-MM-DD-<topic>-handoff.md`.
-
-This is separate from the implementation plan. It is the short assignment packet for a human engineer:
-
-- Issue title and eventual issue id placeholder until issue exists
-- branch name placeholder until branch exists
-- links/paths to spec and plan
-- why the work matters
-- implementation order summary
-- top risks and invariants
-- required verification commands
-- delivery boundary and acceptance checklist pointer
-
-Run placeholder scan over all docs. Placeholders that must be filled before commit, such as issue id after creation, must not remain.
-
-```bash
-rtk rg -n "TBD|TODO|待定|占位|\\.\\.\\." <spec-path> <plan-path> <handoff-path>
-```
-
-### 7. Create the GitHub issue
-
-Use heredoc, never `-m` or literal `\n`.
-
-Issue body must include:
-
-- Background
-- Goals
-- Plan
-- Acceptance criteria with objective checkboxes
-- Links or paths to the spec, implementation plan, and handoff doc
-
-Labels should match repo conventions. Prefer labels for backend/frontend/admin/database/api/docs when they exist.
-
-After issue creation, fill the concrete issue id and URL into the handoff doc if it used placeholders.
-
-### 8. Create the issue branch
-
-Fetch the base and create a clean issue branch:
-
-```bash
-rtk git fetch origin main --prune
-rtk git switch -c codex/docs/<issue-id>-<slug> origin/main
-```
-
-If the spec was created before switching, remember that untracked files usually follow the checkout but tracked edits may not. Verify both docs are present after the switch. If content disappears, recover it intentionally with `git show`, `git stash`, or re-apply the patch; never use destructive checkout/reset.
-
-After branch creation, fill the concrete branch name into the handoff doc if needed. Run final placeholder scan:
-
-```bash
-rtk rg -n "TBD|TODO|待定|占位|\\.\\.\\." <spec-path> <plan-path> <handoff-path>
-```
-
-### 9. Commit and push
-
-Stage only the intended docs:
-
-```bash
-rtk git add <spec-path> <plan-path> <handoff-path>
-rtk git diff --cached --stat
-rtk git diff --cached --check
-```
-
-Commit:
-
-```bash
-rtk git commit -F - <<'MSG'
-docs: add <topic> handoff
-
-变更说明：
-- 新增设计文档，固化已确认方案、风险、测试和验收标准。
-- 新增实施计划和交接文档，拆分实现任务、文件范围和验证命令。
-
-Refs: #<issue-id>
-MSG
-```
-
-Push:
-
-```bash
-rtk git push -u origin <branch>
-```
-
-Comment on the issue with branch, commit, spec path, plan path, handoff path, and the copyable project-manager-style assignment block from the final answer. This issue comment is mandatory; do not finish with only a local final answer.
-
-### 10. Do not create a pull request
-
-This skill stops after the handoff docs are committed, pushed to the remote issue branch, and linked from the GitHub issue comment. Do not create or update a PR for the docs-only handoff branch as part of this workflow, even when the repository's normal implementation flow expects PRs.
-
-If the user explicitly asks for a PR, treat that as a separate follow-up workflow after this handoff is complete.
-
-### 11. Final verification
-
-Before claiming completion, run:
-
-```bash
-rtk git status --short --branch
-rtk git log -1 --oneline
-rtk git rev-parse --abbrev-ref --symbolic-full-name @{u}
-```
-
-Report actual state. If no tests/builds were run because this is docs-only, say that.
-
-Read back the issue comments and verify that the latest handoff comment contains the branch, commit, spec path, plan path, handoff path, and the same assignment block shown in the final answer. If `gh issue comment` failed, the comment is missing, or the readback does not match the final assignment block, fix that before claiming completion.
-
-## Final Answer Template
-
-Keep it short, then include this copyable block:
-
-```markdown
-已准备好交接资料：
-
-- Issue：#<issue-id> <issue-url>
-- 分支：`<branch>`
-- 提交：`<sha> <subject>`
-- 设计文档：`<spec-path>`
-- 实施计划：`<plan-path>`
-- 交接文档：`<handoff-path>`
-
-以下交接评论已同步写入 Issue，可直接派发给开发工程师：
-
-请基于 `<branch>` 接手实现 Issue #<issue-id>：<issue-title>。
-
-先阅读：
-1. `<spec-path>`
-2. `<plan-path>`
-3. `<handoff-path>`
-
-实现时请按实施计划的 Task 顺序推进，并重点守住以下约束：
-- <top-risk-or-constraint-1>
-- <top-risk-or-constraint-2>
-- <top-risk-or-constraint-3>
-
-完成后请至少运行：
-- `<verification-command-1>`
-- `<verification-command-2>`
-- `<verification-command-3>`
-
-验收标准以 Issue #<issue-id> 的 checklist 为准。实现过程中如遇到与设计文档冲突的细节，先在 Issue 中同步风险和建议处理方式。
-```
-
-In Codex app, after successful git actions, also emit the app directives for branch creation, staging, commit, and push.
-
-## Common Mistakes
-
-- Writing the issue before the spec is stable and then forgetting to update links.
-- Writing the implementation plan before spec adversarial review has completed and valid findings have been fixed.
-- Skipping adversarial review because the spec “looks obvious”.
-- Treating the handoff doc as the implementation plan. The implementation plan must be produced with `writing-plans`, reviewed, and fixed before the handoff doc.
-- Skipping adversarial review of the implementation plan.
-- Creating the branch from the current stale feature branch instead of `origin/main`.
-- Committing on an unrelated branch.
-- Writing a handoff that says “add tests” without exact files, behaviors, and commands.
-- Forgetting the issue comment, leaving the receiving engineer to hunt for branch and docs.
-- Posting an issue comment with links only, but omitting the project-manager-style assignment block.
-- Creating or updating a PR for the docs-only handoff branch instead of stopping after commit, push, and issue comment.
-- Final answer lists artifacts but omits the copyable project-manager-style assignment block.
+最终给出实际产物链接、验证结果及简短可复制的交接文字：从哪个分支接手、先读什么、实施重点、验收命令。只报告实际完成的提交、推送和评论。

package/skills/delivering-design-handoff/agents/openai.yaml

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

package/skills/doctor/SKILL.md

@@ -1,10 +1,16 @@
 ---
 name: doctor
-description: 仅在用户显式调用 $doctor 或明确要求使用 doctor 技能时使用；不要通过关键词、任务类型或上下文自动触发。
+description: 仅在显式调用 doctor 时使用：检查或修复本机 agent 开发环境。
 ---
 
 # Doctor
 
+## 执行边界与优先级
+
+在宿主系统与开发者指令约束内，冲突时依次采用：当前任务的具体要求与已有授权 > 目标项目适用的 AGENTS.md > 本技能及其引用的通用流程。
+只读检索、本地草稿、可回滚编辑和常规测试可自主推断并继续；从相关文件和直接依赖开始，仅在证据不足或影响跨模块时扩大范围，复用仍有效的验证。
+仅在不可逆或难以回滚的修改缺少具体授权时，先完成预览、草稿与验证，再说明对象和影响并等待确认；会话中已有授权继续有效。缺少事实时先查证、标注假设并推进独立工作，确实无法确定操作目标时才询问。对外发送消息须有明确授权。
+
 ## 概览
 
 本技能用于把当前机器调整到可稳定运行 agent 开发工作流的状态。
@@ -13,7 +19,7 @@ description: 仅在用户显式调用 $doctor 或明确要求使用 doctor 技
 
 ## 目标状态
 
-最终环境应尽量满足：
+完整环境体检时参考以下目标；单项修复仅检查目标工具及直接依赖，已有健康证据可复用：
 
 - `python3` 可用。
 - `python` 可调用 Python 3，或有清晰说明当前系统无需/不应创建该别名。
@@ -28,7 +34,7 @@ description: 仅在用户显式调用 $doctor 或明确要求使用 doctor 技
 
 ## 执行原则
 
-- 先诊断，再修复；不要未经确认就重复安装已经健康的工具。
+- 先诊断，再修复；健康工具直接复用，已明确需要的可回滚修复自主执行。
 - 优先使用系统已有的包管理器和用户态安装路径。
 - 遇到多个可行方案时，选择对系统影响最小、最容易回滚的方案。
 - 对需要管理员权限、网络下载或会修改 shell 配置的动作，执行前简短说明影响。
@@ -37,7 +43,7 @@ description: 仅在用户显式调用 $doctor 或明确要求使用 doctor 技
 
 ## 建议工作流
 
-1. 收集上下文：
+1. 按任务范围收集必要上下文；完整体检可检查：
    - 操作系统与架构
    - 当前 shell 与 PATH
    - `python3`、`python`、`node`、`npm`、`pnpm`、`dx`、`agent-browser`、`rg`、`gh`、`rtk` 的存在性与版本
@@ -46,12 +52,12 @@ description: 仅在用户显式调用 $doctor 或明确要求使用 doctor 技
 2. 对照目标状态判断缺口。
 3. 制定最小修复动作并执行。
 4. 每次修复后重新验证相关项。
-5. 所有项目完成后运行一次最终复检。
+5. 汇总已验证的结果，只补查仍缺证据或被后续修改影响的项。
 6. 输出报告。
 
 ## 验证要求
 
-最终复检至少覆盖：
+按本次修复范围选择验证项；完整体检覆盖下列适用项：
 
 - 每个目标命令是否可被当前 shell 找到。
 - 每个目标命令的版本或基本健康输出。

package/skills/doctor/agents/openai.yaml

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

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

@@ -1,15 +1,21 @@
 ---
 name: gh-dependabot-cleanup
-description: 仅在用户显式调用 $gh-dependabot-cleanup 或明确要求使用 gh-dependabot-cleanup 技能时使用；不要通过关键词、任务类型或上下文自动触发。
+description: 仅在显式调用 gh-dependabot-cleanup 时使用：修复 Dependabot 安全告警。
 ---
 
 # GH Dependabot Cleanup
 
+## 执行边界与优先级
+
+在宿主系统与开发者指令约束内，冲突时依次采用：当前任务的具体要求与已有授权 > 目标项目适用的 AGENTS.md > 本技能及其引用的通用流程。
+只读检索、本地草稿、可回滚编辑和常规测试可自主推断并继续；从相关文件和直接依赖开始，仅在证据不足或影响跨模块时扩大范围，复用仍有效的验证。
+仅在不可逆或难以回滚的修改缺少具体授权时，先完成预览、草稿与验证，再说明对象和影响并等待确认；会话中已有授权继续有效。缺少事实时先查证、标注假设并推进独立工作，确实无法确定操作目标时才询问。对外发送消息须有明确授权。
+
 ## 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.
+1. Infer the repository and scope from the task and current remote, state the choice, and fetch evidence without waiting for reconfirmation.
 2. Fetch open alerts with `gh api`.
 3. Classify alerts into:
    - patchable: has `first_patched_version`
@@ -19,7 +25,7 @@ Use this skill to complete a Dependabot remediation loop with minimal manual inp
 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.
+8. For an authorized PR delivery, commit, push, and open a focused PR; a local remediation request finishes with the verified local changes.
 9. Report residual risk (unpatched alerts) in PR and final reply.
 
 ## Default Commands
@@ -49,6 +55,3 @@ Include these sections:
 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/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/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,7 @@
 | 阶段 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、输出字节和文件观测摘要，疑似停滞时检查原会话与工作树。宿主单次等待结束后继续观察同一会话，不设置按总耗时自动终止的外层超时器，也不把尚未返回当作降级依据。
 
@@ -39,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