@weotro/dx 0.1.12 → 0.1.14

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

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

@@ -1,536 +0,0 @@
-# Ship Issue PR Core
-
-这是 `cc-ship-issue-pr` 与 `oo-ship-issue-pr` 共用的外部流程真源，不独立调用。
-
-入口技能必须先完成自身运行时门禁，再完整读取本文件。入口技能只负责平台差异；本文件负责交付阶段、复杂度门禁、Git/GitHub 约束、验证矩阵、审查循环、合并和回访。两者冲突时，平台调用方式服从入口技能，交付语义服从本文件。
-
-## 入口契约
-
-入口技能必须在执行本流程前明确：
-
-- **主进程**：当前宿主 agent，负责全部授权判断、轻改动、Git/GitHub 写操作、权威验证和事实核验。
-- **外部专家**：重改动的方案讨论、实现、独立 review 或 adversarial review 承接者。
-- 只读讨论、可写实现、普通 review、adversarial review 四种调用方式。
-- 外部专家的补跑清单、结果取得、等待/超时与不可用时的处理。
-- follow-up subagent 的派发工具、当前入口技能名和后台运行方式。
-- 审查报告里的 reviewer 名称，以及成功/阻塞输出的入口显示名。
-
-外部专家永远不写 Git 历史和 GitHub。它只在工作树落改动或返回报告，最终结论由主进程核验。
-
-## 委派活性与接管
-
-适用于方案讨论、实现、审查、修复和 follow-up。派发时记录执行者 ID、工作目录、日志或输出位置及责任文件基线；后续始终观察同一任务。
-
-- 新增有效日志、工具调用进展、输出内容或责任文件修改，任一出现就更新最后活动记录并继续等待。同一文件反复编辑也算变化；只读任务可以只有日志。总耗时、单次等待超时、尚无最终答复都不能作为终止或替换依据。
-- 静默阈值只触发诊断：检查原任务日志、当前子命令、进程状态及权限/依赖等待，必要时向原执行者询问进度。静默推理、长测试和观测渠道不可用都不等于死亡；重复报错或空心跳也不等于有效进展。
-- 明确失败退出，或持续无有效进展且诊断证实无法继续（例如死锁、失联且执行进程已不存在、不可恢复错误），才进入恢复或接管。能够解除阻塞时优先恢复原任务；证据不足时保留任务并报告未知状态。用户明确取消时按取消要求处理。
-- 接管前记录诊断证据，确认原任务及其写入子进程已停止，再核对现有 diff、新文件和验证结果。交接仅包含剩余工作；保留已完成成果，不从头重放，也不让两个执行者同时写同一范围。
-
-## 复杂度门禁
-
-每次派发外部专家前先过这道门禁。命中任一信号即**重改动**，走外部专家；一个都不命中即**轻改动**，主进程直接做。派发往返成本高于轻改动直改，门禁结果和命中/未命中的信号编号必须记入审查报告。
-
-1. 改公共 API、DTO/OpenAPI 契约、数据库 schema 或迁移、权限/安全边界、计费/积分结算。
-2. 改并发、事务、缓存、重试、幂等、状态机或流式管线的语义。
-3. 跨模块或跨端（backend/front/admin/mobile/packages 之间），且需要协调契约、共享状态，或与数据库迁移/数据回填联动。
-4. 实现文件超过 5 个，或有效可执行改动超过约 100 行（测试、快照、生成产物不计）。
-5. 仅审查站点适用：主进程初审发现未确认的 Critical/Major，需要独立证据裁决。
-
-三个站点共用这一份信号清单，输入不同：
-
-- **方案与实现**（阶段四）：按 Issue 验收标准预估改动面。预估命中信号时，先走方案讨论定案，再派外部专家实现；拿不准按轻改动直改，实际 diff 若命中信号，审查站点按重改动兜底。
-- **审查**（阶段 7.3）：按 `gh pr diff` 的实际 diff 判定。
-- **修复**（阶段 7.4）：按单条修复自身的改动面判定，与原问题的严重级无关。
-
-## 硬门禁
-
-| 门禁 | 要求 |
-|---|---|
-| 中文输出 | 过程说明、报告、阻塞原因用中文 |
-| Issue | 提交/发 PR 前必须有 Issue ID；没有就先创建 |
-| Follow-up | 发现不属于本次范围的问题即建 follow-up Issue（当前入口技能被调用即为授权），正文质量同阶段二；建完按 **Follow-up 即建即派** 判闸门，并在 PR body 与审查报告登记编号 |
-| 分支 | 禁止在 `main` 直接提交；分支必须含 Issue ID |
-| 命令位置 | 从仓库根目录执行；Flutter 命令在 `apps/mobile` |
-| 模板 | Issue/PR 正文结构一律取自 `.github/`，禁止自造结构 |
-| Heredoc | 多行 Issue body、commit message、PR body、PR comment 必须用 heredoc |
-| 暂存 | 按明确路径 `git add <path>`，禁止 `git add -A` / `git add .` |
-| 验证 | 发 PR 前必须有覆盖当前版本的相关验证记录；按下方证据复用规则补跑失效或缺失项 |
-| 正文质量 | 模板占位注释、`TODO`、`TBD`、「稍后补充」残留一律阻塞 |
-| 合并 | 只能 `gh pr merge --squash --auto`，禁止 `--admin` |
-| 真完成 | 必须轮询到 `mergedAt` 非空，并回访关联 Issue 状态 |
-
-## Follow-up 即建即派
-
-Follow-up Issue 建完就派出独立 subagent 在自己的 worktree 里跑完整条链路，本次交付继续往下走。攒成清单等用户下次再派，等于把交付责任退回给用户。
-
-### 派发闸门
-
-按顺序判，命中即停：
-
-1. **需要用户授权**——新依赖、生产数据操作或回填、部署发布、真实外部资源（域名、密钥、素材、第三方配置）、产品或设计决策未定、验收标准写不出来。→ 只建 Issue **不派**，在成功输出里写明编号和缺哪一项授权。
-2. **依赖本次改动**——follow-up 要动本 PR 尚未合并的代码，或改动文件与本 PR 重叠。→ 记账，**阶段九本 PR 合并后再派**，那时 `origin/main` 已带上本次改动。
-3. **其余**——建完 Issue 立即派，不等本次交付结束。
-
-### 派发步骤
-
-worktree 从 `origin/main` 起：从当前分支起会把本 PR 未合并的提交带进 follow-up PR，PR diff 和审查全部失真。分支 `<type>` 按 follow-up 自身性质取值，取值范围同阶段三，不要一律写 `fix`。
-
-```bash
-WT=~/.ship-worktrees/ai-monorepo-<issue-id>
-mkdir -p ~/.ship-worktrees
-git fetch origin main
-git worktree add -b <type>/<issue-id>-<slug> "$WT" origin/main
-```
-
-新 worktree 只有入库文件，`node_modules` 和 `.env*.local` 都被 gitignore。不用手工补：`dx` 每条命令的启动检查都会从主检出根目录同步 `.env.*.local`，并在 `node_modules` 缺失时跑 `pnpm install --frozen-lockfile`。一条命令 bootstrap 到位，和 `paseo.json` 的 `worktree.setup` 同款：
-
-```bash
-(cd "$WT" && dx build all)
-```
-
-不要用 `dx worktree make`：它建的分支叫 `issue-<n>`，不符合当前流程的 `<type>/<id>-<slug>` 格式，还会 `git fetch origin main:main` 动本地 `main`。
-
-然后使用入口技能声明的 follow-up 派发通道，prompt 必须包含：
-
-- 「工作目录是 `<WT 绝对路径>`，每条命令都从这里执行，不要进入主检出或别的 worktree。」
-- 「调用当前入口技能交付 Issue #<id>，直到 `mergedAt` 非空且回访完成；技能清单里没有它就读取入口技能文件全文。」
-- 「Issue 和分支都已建好，从阶段二起走：阶段二绑定已有 Issue #<id>，不要新建 Issue，不要新建分支。」
-- 「你自己发现的 follow-up 只建 Issue 并写进 PR body，不要继续派发。」——派发深度只有一层，否则一次交付会无限扇出。
-- 「外部专家通道不可用时按入口技能的降级规则处理，并在 PR body 记录。」
-- 下方**并发边界**的后端 E2E 抢锁写法原文。
-
-入口技能必须把自身名称、subagent 工具和后台运行方式写进派发 prompt；共享流程不猜测宿主工具。
-
-### 并发边界
-
-本机只有一套本地 PostgreSQL 和一份 `.env.e2e.local`，两条交付线同时跑后端 E2E 会互相清库，失败看起来像代码回归。要跑后端 E2E 的一律先抢锁：
-
-```bash
-until mkdir /tmp/ship-issue-pr-e2e.lock 2>/dev/null; do sleep 30; done
-dx test e2e backend <file-or-dir>; rc=$?
-rmdir /tmp/ship-issue-pr-e2e.lock; exit $rc
-```
-
-整段使用入口技能声明的后台执行方式运行。记录持锁任务与进程身份；等待过久时检查持锁者日志和进程状态。只有确认持锁者及其测试子进程已结束才清理遗留锁，不能仅凭锁目录 mtime 判死或抢占。
-
-同时在跑的 follow-up subagent 最多 3 个。超出的由主进程记在待派清单里，等某条线的完成通知到达后再派下一个——排队没有别的执行者，主进程不记就等于丢了。
-
-### 登记与回收
-
-派发后主进程不等它，继续本次交付。每个派出的 follow-up 在 PR body、审查报告和成功输出里都要有一行：Issue 编号、worktree 路径、subagent 名。
-
-完成通知到达时向用户汇报它是合并了还是阻塞了。确认合并后回收 worktree 和本地分支——PR 走 `--squash` 合并，git 不认为分支已合并，`git branch -d` 会被拒，必须 `-D`：
-
-```bash
-git worktree remove ~/.ship-worktrees/ai-monorepo-<issue-id>
-git branch -D <type>/<issue-id>-<slug>
-```
-
-## 阶段一：状态检测
-
-```bash
-git status --short
-git branch --show-current
-git log origin/main..HEAD --oneline
-git diff --stat origin/main...HEAD
-gh pr status
-```
-
-| 现状 | 入口 | 跳到该阶段前必须先补齐 |
-|---|---|---|
-| 有需求但工作树干净 | 阶段二起完整链路 | — |
-| 工作树改动经确认属于本次任务 | 阶段二起完整链路，**跳过阶段四** | 先按下方要求区分相关与无关改动 |
-| 工作树只有无关改动 | 阶段二起完整链路，**照常走阶段四** | 同上；无关改动原样留在工作树，不暂存、不提交 |
-| 工作树干净且分支有未发 PR 提交 | 阶段六 | 阶段二的 Issue 绑定、阶段三的分支合规、阶段五的验证 |
-| 当前分支已有 OPEN PR | 阶段七 | 上一行全部，外加阶段六的 PR body 读回校验与依赖冲突检查 |
-| 工作树干净、无分支差异、无 OPEN PR | 输出「无需交付」并结束 | — |
-
-快捷入口只省掉已经做过的动作，不豁免任何门禁。先收集本次任务已有的验收、审查和验证记录，按下方证据复用规则核对。补齐前禁止进入目标阶段：没有 Issue ID 就先建 Issue，分支不合规就先改分支，验证缺失或失效就补跑，依赖 PR 未真合并就停下。
-
-阻塞条件：不在 Git 仓库；`gh auth status` 不可用；当前分支为 `main` 且无法创建新分支。
-
-保护工作区内一切未提交改动。发现脏工作树时先逐个文件区分本次任务相关与无关修改，不覆盖、不回退、不顺手整理无关文件；禁止 `git checkout <ref> -- <path>` 一类静默覆盖命令。
-
-脏工作树不等于「本次实现已完成」。只有确认改动确实实现了本次需求才允许跳过阶段四；改动与本次任务无关时照常走阶段四，并在阶段五只暂存本次任务的文件。判断不了归属就直接问用户，不要猜。
-
-## 阶段二：Issue 创建或绑定
-
-先从用户输入、分支名、commit、已有 PR body 提取 Issue ID。提取不到就创建。
-
-创建前先开工查 `main` 有没有并行的重复交付，撞车了先拆聚焦范围再动手。
-
-**正文结构取自仓库模板**，`gh issue create` 不会自动套模板，必须自己读出来再填：
-
-```bash
-sed '1,/^---$/d' .github/ISSUE_TEMPLATE/issue.md > /tmp/ship-issue-pr-issue-body.md
-```
-
-按模板段落逐段填写真实内容，再创建：
-
-```bash
-gh issue create \
-  --title "fix(scope): 问题摘要" \
-  --label enhancement \
-  --body-file /tmp/ship-issue-pr-issue-body.md
-```
-
-标题格式 `<type>(<scope>): 简洁目标` 或 `[模块] 简洁目标`。标签从 `bug`、`enhancement`、`documentation`、`performance`、`refactor`、`backend`、`frontend`、`infrastructure`、`test` 中选。
-
-填写质量要求，模板本身不管这些：
-
-- 「验收标准」每条必须能在 diff、命令输出或手测步骤中找到证据。写不出可验证的标准就先停下回到目标澄清，禁止用「代码更优雅」凑数。
-- 「背景」要让 reviewer 理解为什么现在要做，附失败证据、相关文件/PR/Issue。
-- 「目标」写完成后可观察的状态，不写操作清单。
-- 依赖上游配置、外部服务或后续 PR 时，必须写进正文。
-
-创建后读回校验：
-
-```bash
-gh issue view <ISSUE_ID> --json title,body,labels,url
-```
-
-```bash
-gh issue view <ISSUE_ID> --json body -q .body > /tmp/ship-issue-pr-issue-readback.md
-grep -oE '<!--.*-->' .github/ISSUE_TEMPLATE/issue.md | grep -qFf - /tmp/ship-issue-pr-issue-readback.md \
-  && echo "阻塞：模板提示注释未替换" || echo "占位检查通过"
-grep -c '^- \[ \]' /tmp/ship-issue-pr-issue-readback.md
-```
-
-校验失败条件：缺模板任一段落；验收标准少于 1 条；验收标准是动作清单而非可验证结果；模板提示注释未替换；`- [ ]` 空条目仍留在正文。
-
-## 阶段三：分支
-
-格式 `<type>/<issue-id>-<slug>`，`<type>` 只能是 `feat`、`fix`、`refactor`、`docs`、`chore`、`test`。
-
-```bash
-git switch -c fix/1234-short-topic
-```
-
-当前分支是 `main` 或不含 Issue ID 时必须新建；已合规则继续使用。
-
-## 阶段四：实现
-
-工作树已有改动时跳过本阶段。
-
-先按**复杂度门禁**判定：
-
-- **轻改动**：主进程直接实现。先读涉及目录的 `AGENTS.md`，改动收敛在 Issue 验收标准范围内，完成后直接进阶段五。
-- **重改动**：先走方案讨论定案，再派外部专家实现。
-
-### 方案讨论（仅重改动）
-
-主进程先读涉及目录的 `AGENTS.md` 和相关源码，写出自己的初步方案：实现路径、涉及文件、关键取舍、已想到的备选。有了初步方案再讨论，问题清单越具体，讨论产出越有用。
-
-然后使用入口技能声明的只读方案讨论通道，prompt 写死「只讨论方案，禁止任何写操作，不要递归委派」，并附 Issue 原文与验收标准、初步方案、备选与取舍、希望裁决的具体问题。同一任务的相关取舍合并成一次讨论，不反复往返。
-
-外部专家返回后主进程逐条核验它引用的事实（直读源码验证，不采信转述），采纳与拒绝各记一句理由，最终方案由主进程拍板。
-
-### 派外部专家实现（仅重改动）
-
-使用入口技能声明的实现通道，按入口技能声明的结果取得与等待规则推进。prompt 必须包含：
-
-- Issue 编号、原文目标与逐条验收标准。
-- 方案讨论定案的最终方案原文。
-- 涉及的目录，以及该目录 `AGENTS.md` 要求先读。
-- 「改动留在工作树，不要 `git commit`、不要 `git push`、不要碰 GitHub」。
-- 入口技能声明的补跑清单，并要求把无法运行的验证列出来交回。
-- 「不要递归委派给别的 agent」。
-
-外部专家返回后，主进程逐条核验它的结论，不照单全收：
-
-```bash
-git status --short
-git diff --stat
-```
-
-改动范围超出 Issue 目标、或引入未经说明的依赖时，主进程收敛回范围内，不带进提交。
-
-## 验收、审查与验证证据复用
-
-证据绑定代码和输入，不绑定「PR 创建前/后」或阶段编号。默认实现后做最低充分验证、提交并创建 PR，再在阶段七完成首次正式审查；进入本流程前已有的有效审查可以直接承接，无需为了发 PR 额外增加一轮。单纯 commit、push、创建 PR、更新正文或进入合并阶段不触发重审或重跑。
-
-每次完成验收、审查或权威验证时记录以下信息；先保存在本次任务记录中，创建 PR 后将来源与复用结论写入审查报告：
-
-- **版本与范围**：仓库、目标 base 分支及其 SHA、merge-base、被检查的 HEAD 与 tree SHA、覆盖的 diff/文件和 Issue 验收标准。未提交改动用包含相关新增文件的内容快照标识；提交后核对实际内容一致，再关联 commit，不能只记录当时的 HEAD。
-- **审查证据**：实际 reviewer、是否独立于实现/修复、报告来源、findings 及处理状态。实现者自检、方案咨询和一句「已审查」不能代替独立审查报告。
-- **验证证据**：实际执行者、命令与参数、结果及日志来源、影响结果的环境/工具链/依赖和配置标识（不记录密钥）。验证过程中格式化、代码生成或钩子改了输入时，记录最终版本并补跑受影响项。
-
-复用前由主进程确认来源可读、范围充分、结论仍适用。主进程先前亲自执行并读取输出的验证可以复用；外部执行者的结果仍按入口运行时契约处理。混有无关工作树改动时，必须确认它们没有影响被验证的提交内容，否则在隔离的 worktree 验证目标版本。
-
-| 当前状态 | 处理 |
-|---|---|
-| 内容、base、验收范围及相关验证输入均未变，证据完整 | 直接复用，记录来源；已有完整审查无需再次通读同一 diff |
-| 只有 commit SHA 变化，tree、base 和其他输入一致 | 核对内容后将原证据关联新 HEAD，无需重跑 |
-| 有新增修改、修复、验收标准变化，或 base/依赖/配置/环境变化 | 比较前后差异，复查增量及其影响的调用方、不变量和验收项；只重跑受影响的验证命令，保留未受影响证据并记录理由 |
-| 缺少记录、无法确认版本一致或无法界定影响范围 | 补做缺失检查；无法界定影响时审查完整当前 diff，并执行阶段五适用的验证矩阵 |
-
-审查与验证分别判断是否可复用；测试通过不能代替代码审查。当前 diff 仍须过复杂度门禁：重改动只有自审记录时，仍需补齐 7.3 的条件式独立审查或按入口契约记录降级，才算审查完整。历史失败和未处理 findings 继续保留，不能因复用而改记为通过。PR 前已完成的独立外部审查计入同一交付的「每 PR 最多一次」额度；历史额度与当前覆盖范围分别记录，后续新增改动由主进程补审。
-
-## 阶段五：验证与提交
-
-按改动范围确定最低充分验证，复用有效记录，仅执行缺失或失效项：
-
-| 改动范围 | 必跑命令 |
-|---|---|
-| 任意 JS/TS | `dx lint` |
-| mobile（哪怕只加一行 import） | `dx lint`（含 `design:lint`，覆盖 Dart） |
-| 后端 | `dx build backend --dev`，相关 `dx test unit backend [path]` |
-| 后端 E2E 相关 | `dx test e2e backend <file-or-dir>`，禁止无参全量 |
-| 前端用户端 | `dx build front --dev`，相关 `dx test unit front [path]` |
-| 管理端 | `dx build admin --dev`，相关 `dx test unit admin [path]` |
-| DTO/API 契约 | `dx export openapi --dev` 后再 `dx build api-contracts` |
-| 共享包 | `dx build shared` 或相关 shared 测试 |
-| Flutter | `cd apps/mobile && flutter analyze`，相关 `flutter test <path>` |
-| 范围不确定 | `dx lint` + `dx build affected --dev` + 相关测试 |
-
-失败先查 `docs/agents/known-test-failures.md`：清单里有就是既有失败，清单里没有就按本次改动引入处理。修复或新发现既有失败时同步更新该清单。
-
-无法在本 PR 内修复的既有失败，创建 follow-up Issue，并在 PR body 与审查报告同时登记编号。
-
-提交由主进程做，每个逻辑变更一个 commit。
-
-按明确路径暂存，禁止 `git add -A` / `git add .`：工作树可能带着用户的无关未提交改动，全量暂存会把草稿甚至密钥一起提交推送，也让 PR 范围失控。暂存后必须核对 `--cached` 清单，出现本次任务之外的文件就撤出该文件重来。
-
-```bash
-git add <本次改动的明确路径>
-git diff --cached --stat
-git commit -F - <<'MSG'
-fix: 简洁摘要
-
-变更说明：
-- 说明关键改动
-- 说明影响范围
-
-Refs: #123
-MSG
-```
-
-标题必须是 Conventional Commit。既有问题的顺手修复单独用 `chore(precheck):` 提交，与本次功能改动分开。
-
-提交后核对 commit 内容与验证快照一致；提交钩子或暂存范围造成内容差异时，按证据复用规则补验，再进入阶段六。
-
-## 阶段六：PR 创建或更新
-
-```bash
-git push -u origin HEAD
-git log origin/main..HEAD --oneline
-git diff origin/main...HEAD --stat
-```
-
-**正文结构取自仓库模板**：
-
-```bash
-cp .github/pull_request_template.md /tmp/ship-issue-pr-pr-body.md
-```
-
-按模板段落填真实内容后自检再创建。并行交付多个 PR 时用带 PR 号的文件名，不要共用同一个 `/tmp` 路径：
-
-```bash
-# 模板自带的提示注释必须已被替换；按模板原文匹配，不要按字面 `<!--` 匹配
-grep -oE '<!--.*-->' .github/pull_request_template.md | grep -qFf - /tmp/ship-issue-pr-pr-body.md \
-  && echo "阻塞：模板提示注释未替换" || echo "占位检查通过"
-! grep -qE '稍后补充|TODO|TBD' /tmp/ship-issue-pr-pr-body.md
-grep -q 'Closes: #[0-9]' /tmp/ship-issue-pr-pr-body.md
-
-gh pr create --base main --title "fix: 简洁摘要" --body-file /tmp/ship-issue-pr-pr-body.md
-```
-
-按字面 `<!--` 匹配会误伤讨论模板机制本身的 PR，正文里合法引用 HTML 注释会被判成占位残留。
-
-填写质量要求：
-
-- 「已做的验证」必须列实际命令、涉及测试文件、关键结果。写「已测试」「本地通过」等于没写。命令没跑就不许创建 PR。
-- 有新增/修改测试时必须列测试文件；没有测试时说明为什么没有。
-- Issue 有未覆盖的验收标准时，「遗留的问题」不得写「无」，必须补做或建 follow-up Issue 并引用。
-- `#123` 只用于真实 Issue/PR 引用；普通序号写 `[1]`、`问题 1`，避免被 GitHub 误链接。
-- 更新既有 PR 时同样要过这套检查，不合格立刻 `gh pr edit <PR_NUMBER> --body-file` 修正。
-
-创建或更新后读回：
-
-```bash
-gh pr view <PR_NUMBER> --json title,body,url
-```
-
-body 为空、缺模板段落、模板提示注释未替换、留有占位符、「已做的验证」没有实际命令、缺 `Closes: #<issue-id>`，任一命中即修正后重读。
-
-### 依赖与冲突
-
-PR body 标了 `PR Train`、`依赖 #<PR_NUMBER>` 时，先确认依赖 PR 的 `mergedAt` 非空，否则停止，禁止继续审查或合并。
-
-```bash
-git fetch origin main
-git merge --no-commit --no-ff origin/main
-```
-
-无冲突则 `git merge --abort` 继续。有冲突则 `git merge --abort` 后真实合并、解冲突、重跑验证、单独提交并推送，commit 说明保留哪一侧语义及原因。
-
-## 阶段七：审查修复循环
-
-最多 3 轮实际审查修复。首次进入先核对已有证据，每轮只补齐 Issue 验收、验证流水线、代码审查和逐项修复中的缺失或失效项。证据全部有效且满足终止条件时，发布复用报告后直接进入阶段八；复用不算新一轮审查。
-
-### 7.1 Issue 验收（主进程）
-
-```bash
-gh issue view <ISSUE_ID> --json title,body,state
-gh pr diff <PR_NUMBER>
-```
-
-先确认 Issue 标准及 PR diff 相对已有记录的变化。已有证据覆盖的验收项直接引用；对新增、变化或缺证据的标准逐条核对：
-
-| 状态 | 后续 |
-|---|---|
-| 通过 | 记录文件/行号或模块 |
-| 部分 | 必须修复 |
-| 未实现 | 必须补做或拆 follow-up Issue |
-| 超出范围 | PR body 补释或拆 Issue |
-
-### 7.2 验证流水线（主进程）
-
-按证据复用规则补跑阶段五中缺失或受本轮变化影响的命令；阶段五或上一轮修复后已验证同一输入时直接引用结果。失败必须保留完整错误：文件、行号、命令、失败摘要。
-
-### 7.3 代码审查
-
-主进程先核对已有审查的版本、范围、reviewer 和问题处理状态。没有有效审查时通读 `gh pr diff` 全部改动；已有完整有效审查时直接复用，有后续修改时只审增量及受影响上下文。无法界定影响范围时恢复完整审查。核查 diff 涉及文件内的真实 bug，不主动扩大到无关模块。
-
-外部专家独立审查是条件式补充，同时满足两条才派发：
-
-1. 实际 diff 命中**复杂度门禁**任一信号（重改动）。
-2. 本次交付尚未用过外部专家审查——同一 PR 最多一次，含创建 PR 前对本次交付的独立审查；派发前查任务记录与本 PR 已有报告的 reviewer、独立性和覆盖范围，确认已有独立外部审查即只由主进程补审未覆盖的改动。轻改动 PR 的这次额度可以留到后续 diff 扩大首次命中信号时再用。
-
-使用入口技能声明的 review 通道。需要挑战实现方案、状态机、不变量或安全边界时改用 adversarial review；需要对照 Issue 验收标准或排除已确认问题时，把定制上下文一并传入。
-
-外部专家返回后主进程逐条核验，直读源码复核，不采信转述。合并重复项，记录拒绝依据。
-
-无论 reviewer 是谁，每条进入报告的问题必须有四要素：严重级、文件:行号、具体问题、具体改法。缺四要素或只写「建议优化」的条目不进报告。功能未实现类问题归入 7.1，不在这里重复。
-
-| 严重级 | 例子 | 默认处理 |
-|---|---|---|
-| Critical | 构建失败、测试失败、安全漏洞、数据丢失 | 必修 |
-| Major | 逻辑缺陷、错误处理缺失、性能问题、验收部分缺失 | 修复或拆 follow-up |
-| Minor | 命名、局部风格、文档、小范围清理 | 小于 5 行优先修，否则写拒绝理由 |
-
-发布审查报告评论：
-
-```bash
-gh pr comment <PR_NUMBER> --body-file - <<'MSG'
-## 代码审查报告（第 N 轮）
-
-### 概要
-
-- Critical：0 / Major：0 / Minor：0
-- reviewer：主进程自审 / 外部专家 review / 外部专家 adversarial review
-- 复杂度门禁：轻改动（未命中信号）/ 重改动（命中信号 N）；外部专家额度：未用 / 本轮已用 / 此前已用
-- 证据：base / merge-base / HEAD / tree；验收、审查与验证各自的原记录来源和覆盖范围
-- 本次处理：复用 / 增量补查 / 首次完整检查；变化与失效原因（如有）；复用报告沿用原轮次
-
-### 验证流水线
-
-- Lint：通过/失败
-- 构建：通过/失败（实际命令）
-- 测试：通过/失败/跳过（实际命令）
-
-### 问题列表
-
-| 严重级 | 文件:行号 | 描述 | 建议改法 | 处理 |
-|---|---|---|---|---|
-| Major | path/file.ts:42 | 具体描述 | 具体改法 | 修复/拒绝/follow-up |
-
-### 拒绝依据
-
-- 逐条写具体理由
-MSG
-```
-
-### 7.4 逐项修复
-
-按 `Critical -> Major -> Minor` 处理，每个问题一个 commit，禁止攒到最后。
-
-修复默认主进程直接改；只有单条修复自身命中**复杂度门禁**信号（判定的是这次修复的改动面，不是原问题的严重级）才派外部专家，规则同阶段四。
-
-修复后复查问题与受影响上下文，重跑受影响的验证并更新证据，再发布修复报告评论，列出已修复项及其 commit、拒绝项及理由、follow-up 项及 Issue 编号。下一轮直接承接这些证据。
-
-### 循环终止
-
-结束条件：验收全部完成；验证全部通过或不可修项已登记 follow-up；无未处理的 Critical/Major。
-
-已达 3 轮仍未满足时，禁止合并，走阻塞输出。
-
-## 阶段八：合并
-
-合并前读取 PR 的最新 `headRefOid`、base 并刷新目标分支，核对远端 head 与本地已检查提交一致、相关工作树输入与证据一致。若有变化，按证据复用规则回到阶段七补齐；全部有效时直接发布验证总结评论，引用已完成的实际命令与证据来源、审查轮数和问题统计。验证失败时禁止写「可合并」。
-
-```bash
-gh pr merge <PR_NUMBER> --squash --auto --match-head-commit <已核对的HEAD_SHA>
-gh pr view <PR_NUMBER> --json state,mergedAt,url
-```
-
-本仓库的 GitHub Actions 都不在 `pull_request` 上触发，PR 没有 CI 门禁——质量门禁全靠上面的本地验证。不要等待或监控 `gh pr checks`，`--auto` 设置后通常立即合并。
-
-终止条件：`mergedAt` 非空即成功；`state=CLOSED` 且 `mergedAt=null` 为阻塞；轮询数分钟仍未合并则输出 stuck 状态，禁止 `--admin` 越权。
-
-## 阶段九：回访
-
-```bash
-gh pr view <PR_NUMBER> --json mergedAt,mergeCommit,url
-gh issue view <ISSUE_ID> --json state,title,url
-```
-
-确认 Issue 因 `Closes:` 正确关闭、验收标准真的全部覆盖、PR body 的遗留项都有 follow-up Issue。Issue 被误关但仍有未完成验收标准时，重开或拆 follow-up，并在最终输出写明编号。
-
-用一组 commit 带入 main 的集成分支会让各 PR 的 `Closes:` 全部失效，此时必须手工逐个回访关闭。
-
-本 PR 已进 main，把**派发闸门**第 2 挡记账的 follow-up 现在派出去，`origin/main` 已经带上本次改动。
-
-## 成功输出
-
-只在确认真合并和回访完成后输出：
-
-```text
-<入口显示名> 完成
-
-- Issue：#123 标题
-- PR：#456 链接
-- 分支：fix/123-short-topic
-- 实现：重改动（方案讨论 + 外部专家）/ 轻改动（主进程直改）；Commit：首个提交摘要；修复提交 X 个
-- 验证：Lint 通过；构建通过；测试通过/跳过原因
-- 审查：N 轮；发现 X 个；修复 Y 个；拒绝 Z 个
-- 合并：已合并到 main，merged_at=<timestamp>
-- 回访：Issue 状态已确认
-- Follow-up：#789 已派发（worktree ~/.ship-worktrees/ai-monorepo-789，subagent <名字>）；#790 未派（缺生产数据操作授权）
-```
-
-## 阻塞输出
-
-```text
-<入口显示名> 阻塞
-
-- 停止阶段：阶段名
-- 已完成：已完成的可审计动作
-- 阻塞原因：具体错误、缺权限、验证失败、依赖未合并
-- 不应做的事：禁止绕过的门禁
-- 下一步建议：可执行命令或需要用户提供的信息
-```
-
-## 红旗
-
-出现这些想法时停止，回到对应阶段：
-
-- 「这个改动很小，不需要 Issue。」
-- 「PR body 之后再补。」/「先写『已通过本地测试』。」
-- 「模板注释留着不影响阅读。」
-- 「既有测试失败不是我引入的，跳过。」——查 `known-test-failures.md`，没有就是本次引入。
-- 「这个改动很简单，但派外部专家更保险。」——过复杂度门禁，轻改动主进程直改。
-- 「方案直接问外部专家，我照它说的做。」——先写出自己的初步方案再讨论，避免被锚定；拍板权在主进程。
-- 「方案讨论太啰嗦，重改动直接开写。」——预估命中信号就必须先讨论定案。
-- 「改动命中信号了，不过我直接改更快。」——重改动派外部专家，直改省下的时间会在审查修复里还回去。
-- 「修了一轮，再让外部专家复查一次。」——外部专家审查每 PR 最多一次，后续由主进程复审。
-- 「派给外部专家了，我先空等。」——按入口技能声明的等待与超时规则推进；可并行时只做不写工作树的事。
-- 「外部专家说改好了，直接提交。」——主进程必须核验 diff 和验证结果。
-- 「外部专家跑验证失败了，让它反复重试。」——查入口技能的补跑清单，由主进程执行权威验证。
-- 「让外部专家顺手 commit 一下。」——Git 历史只由主进程写。
-- 「follow-up 先记着，等用户下次再派。」——过**派发闸门**，只有第 1 挡才留给用户。
-- 「follow-up 的 worktree 从当前分支开更省事。」——从 `origin/main` 起，否则本 PR 未合并的提交会混进 follow-up PR。
-- 「派出去的 subagent 也让它自己往下派 follow-up。」——派发深度只有一层，它只建 Issue。
-- 「GitHub 显示 mergeable，不用逐条核对验收标准。」
-- 「auto-merge 已设置，所以算完成。」
-- 「先 `--admin` 合了再说。」

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

@@ -1,27 +0,0 @@
----
-name: cc-ship-issue-pr
-description: 仅在用户显式调用 $cc-ship-issue-pr、/cc-ship-issue-pr 或明确要求使用 cc-ship-issue-pr 技能时使用，派发 follow-up 交付的 subagent 也从这里进入；不要通过关键词、任务类型或上下文自动触发。
----
-
-# CC Ship Issue PR
-
-Claude Code 入口：主进程执行轻改动，Codex 承接重改动的方案讨论、实现与独立审查。
-
-## 步骤一：加载共享流程
-
-```bash
-AGENTS_ROOT="${AGENTS_HOME:-$HOME/.agents}"
-SHIP_CORE="$AGENTS_ROOT/references/ship-issue-pr-core.md"
-test -f "$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)。该文件是本入口的平台调用契约；共享流程仍是交付语义的唯一真源。
-
-只有共享流程全部完成且 `mergedAt` 非空、Issue 回访完成，才输出 `CC Ship Issue PR 完成`。