@weotro/dx 0.1.13 → 0.1.14

package/README.md

@@ -302,7 +302,7 @@ dx cache clear -Y
 关于 `dx initial`：
 
 - `dx initial` 会把 npm 包内置的 `skills/` 覆盖同步到 `~/.agents/skills`。
-- 包内共享 agent reference 会覆盖同步到 `~/.agents/references`，供多个 skill 共用同一真源。
+- 技能的流程、运行时引用和脚本都放在各自目录内，随整个技能一同同步。
 - `~/.claude/skills` 中包内管理的同名非软链接 skill 会先删除，再创建指向 `~/.agents/skills` 的软链接。
 - `~/.codex/skills` 中包内管理的同名非软链接 skill 会被清理；已有软链接不会按旧副本删除。
 - 从包内移除的历史 skill 会在 `~/.agents/skills`、`~/.claude/skills`、`~/.codex/skills` 中一并清理。
@@ -312,6 +312,12 @@ dx cache clear -Y
 
 安装或升级 dx 后，运行 `dx initial` 即可同步。默认脚本位置为 `~/.agents/skills/delegate-cc/scripts/delegate_cc.py`；旧咨询入口为 `~/.agents/skills/ask_cc/scripts/ask_cc.py`。
 
+Issue/PR 交付统一使用 `ship-issue-pr`：在 Codex 中调用 `$ship-issue-pr`，在 Claude Code 中调用 `/ship-issue-pr`。技能按当前宿主选择工具，轻改动由当前执行者直接完成，需要外部协作时才读取对应运行时。
+
+升级 dx 后再次运行 `dx initial`，会整体更新 `~/.agents/skills/ship-issue-pr/`，并清理已移除的技能和独立引用文件。现有调用统一改为 `ship-issue-pr`。Claude 的软链接直接读取同一份更新；入口同时声明 Codex 和 Claude 的显式调用策略。外部 Claude CLI 或 Codex 插件仍需自行安装并完成认证，目录兼容不代表外部通道已可用。
+
+默认安装根目录固定为当前用户的 `~/.agents` 和 `~/.claude`；`dx initial` 当前不读取 `AGENTS_HOME` 或 `CLAUDE_CONFIG_DIR`。引用文件使用技能目录内的相对路径。需要从本仓库验证当前修改时，使用 `node ./bin/dx.js --config-dir ./example/dx/config initial`；日常 `dx initial` 同步的是当前安装的 npm 包内容。
+
 关于 `help`：
 
 - `dx --help`

package/lib/codex-initial.js

@@ -5,7 +5,7 @@ import os from 'node:os'
 import { logger } from './logger.js'
 
 const TEMP_DIR_PATTERN = /^\..+\.(tmp|backup)-\d+-\d+$/
-const MANAGED_AGENT_REFERENCES = ['ship-issue-pr-core.md']
+const REMOVED_AGENT_REFERENCES = ['ship-issue-pr-core.md']
 
 // 历史上曾在 skills/ 目录托管、但后续已删除的 skill 名称。
 // 来源：git log --all --diff-filter=A --name-only -- 'skills/*' | sed -n 's#^skills/\([^/]*\)/.*#\1#p' | sort -u
@@ -13,6 +13,8 @@ const MANAGED_AGENT_REFERENCES = ['ship-issue-pr-core.md']
 // 这些名字需要在 ~/.agents、~/.claude、~/.codex 三处彻底清理（软链或真实目录都清）。
 // 将来从 skills/ 删除新的 skill 时，把它追加到这里即可。
 const DELETED_SKILLS = [
+  'oo-ship-issue-pr',
+  'cc-ship-issue-pr',
   'autospec',
   'backend-audit-fixer',
   'backend-layering-audit-fixer',
@@ -29,7 +31,6 @@ const DELETED_SKILLS = [
   'pr-ship',
   'pr-train-ship',
   'create-issue',
-  'ship-issue-pr',
   'third-party-review',
 ]
 
@@ -151,43 +152,6 @@ async function copyDirMerge({ srcDir, dstDir }) {
   return { fileCount }
 }
 
-async function copyManagedFiles({ srcDir, dstDir, fileNames }) {
-  let fileCount = 0
-
-  for (const fileName of fileNames) {
-    const source = join(srcDir, fileName)
-    const target = join(dstDir, fileName)
-    const token = `${process.pid}-${Date.now()}`
-    const temporary = join(dstDir, `.${fileName}.tmp-${token}`)
-    const backup = join(dstDir, `.${fileName}.backup-${token}`)
-    let hasBackup = false
-
-    try {
-      const sourceStat = await fs.stat(source)
-      if (!sourceStat.isFile()) throw new Error(`agent reference 不是文件: ${source}`)
-
-      await fs.copyFile(source, temporary)
-      if (await lstatIfExists(target)) {
-        await fs.rename(target, backup)
-        hasBackup = true
-      }
-      await fs.rename(temporary, target)
-      if (hasBackup) await fs.rm(backup, { recursive: true, force: true })
-      fileCount++
-    } catch (error) {
-      await fs.rm(temporary, { recursive: true, force: true })
-      if (hasBackup && !(await lstatIfExists(target))) {
-        await fs.rename(backup, target)
-        hasBackup = false
-      }
-      if (hasBackup) await fs.rm(backup, { recursive: true, force: true })
-      throw error
-    }
-  }
-
-  return { fileCount }
-}
-
 async function removeManagedNonSymlinkSkills(skillsDir, skillNames) {
   for (const skillName of skillNames) {
     const target = join(skillsDir, skillName)
@@ -277,14 +241,12 @@ export async function runCodexInitial(options = {}) {
 
   const homeDir = options.homeDir || os.homedir()
   const srcSkillsDir = join(packageRoot, 'skills')
-  const srcAgentReferencesDir = join(packageRoot, 'agent-references')
   const agentsSkillsDir = join(homeDir, '.agents', 'skills')
   const agentsReferencesDir = join(homeDir, '.agents', 'references')
   const claudeSkillsDir = join(homeDir, '.claude', 'skills')
   const codexSkillsDir = join(homeDir, '.codex', 'skills')
 
   await assertDirExists(srcSkillsDir, '模板目录 skills')
-  await assertDirExists(srcAgentReferencesDir, '模板目录 agent-references')
   const skillNames = await collectSkillNames(srcSkillsDir)
 
   // 护栏：已删除名单不得与现存 skill 重叠，否则会把刚同步的 skill 又清掉（自相矛盾）。
@@ -296,7 +258,6 @@ export async function runCodexInitial(options = {}) {
   await ensureDir(codexSkillsDir)
   await ensureDir(claudeSkillsDir)
   await ensureDir(agentsSkillsDir)
-  await ensureDir(agentsReferencesDir)
 
   await removeManagedNonSymlinkSkills(codexSkillsDir, skillNames)
   await removeManagedNonSymlinkSkills(claudeSkillsDir, skillNames)
@@ -310,19 +271,17 @@ export async function runCodexInitial(options = {}) {
 
   await removeStaleTempDirs(agentsSkillsDir)
   const copyStats = await copyDirMerge({ srcDir: srcSkillsDir, dstDir: agentsSkillsDir })
-  await removeStaleManagedFileArtifacts(agentsReferencesDir, MANAGED_AGENT_REFERENCES)
-  const referenceStats = await copyManagedFiles({
-    srcDir: srcAgentReferencesDir,
-    dstDir: agentsReferencesDir,
-    fileNames: MANAGED_AGENT_REFERENCES,
-  })
-  await removeStaleManagedFileArtifacts(agentsReferencesDir, MANAGED_AGENT_REFERENCES)
   await removeStaleTempDirs(agentsSkillsDir)
   await linkSkillsToClaude({ skillNames, agentsSkillsDir, claudeSkillsDir })
+  if (await pathExists(agentsReferencesDir)) {
+    await removeStaleManagedFileArtifacts(agentsReferencesDir, REMOVED_AGENT_REFERENCES)
+    for (const fileName of REMOVED_AGENT_REFERENCES) {
+      await fs.rm(join(agentsReferencesDir, fileName), { force: true })
+    }
+  }
 
   logger.success('已初始化 skills 模板')
   logger.info(`agents skills: 覆盖复制 ${copyStats.fileCount} 个文件 -> ${agentsSkillsDir}`)
-  logger.info(`agents references: 覆盖复制 ${referenceStats.fileCount} 个文件 -> ${agentsReferencesDir}`)
   logger.info(`claude skills: 已创建 ${skillNames.length} 个软链接 -> ${claudeSkillsDir}`)
   logger.info(`codex skills: 已清理 ${skillNames.length} 个包内托管 skill 的旧副本 -> ${codexSkillsDir}`)
   logger.info(

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@weotro/dx",
-  "version": "0.1.13",
+  "version": "0.1.14",
   "type": "module",
   "license": "MIT",
   "repository": {
@@ -19,7 +19,6 @@
     "bin/",
     "lib/",
     "skills/",
-    "agent-references/",
     "LICENSE",
     "README.md",
     "package.json"

package/skills/ask_cc/SKILL.md

@@ -13,7 +13,7 @@ description: 仅在显式调用 ask_cc 时使用：咨询 Claude Code 获取第
 
 使用 [delegate-cc](../delegate-cc/SKILL.md) 的咨询流程获取答案或第二意见，默认不授予工具权限。
 
-已显式调用的 `oo-ship-issue-pr` 需要咨询时可进入本技能，沿用原任务范围与授权。
+已显式调用的 `ship-issue-pr` 需要咨询时可进入本技能，沿用原任务范围与授权。
 
 调用前读取该技能的咨询调用与结果处理部分，按需查看诊断和接续规则。咨询没有文件修改是正常现象，以本次会话的流式输出和进程状态辅助判断；静默只触发排查，不能仅因尚无答案就停止或换模型。
 

package/skills/delegate-cc/SKILL.md

@@ -13,7 +13,7 @@ description: 仅在显式调用 delegate-cc 时使用：委派 Claude Code 执
 
 把 Claude Code 当作协作者。模型顺序固定为 Fable 5.1（`claude-fable-5-1`）→ Opus 5（`claude-opus-5`）→ 当前 sub-agent。保留本机现有认证。
 
-已显式调用的 `ask_cc` 或 `oo-ship-issue-pr` 需要委派时可进入本技能，沿用原任务范围与授权。
+已显式调用的 `ask_cc` 或 `ship-issue-pr` 需要委派时可进入本技能，沿用原任务范围与授权。
 
 ## 1. 准备交接
 

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/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、已设置自动合并、已合并和已回访分别陈述；仅本地任务以本地产物完成，不强制走到远端合并。

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/AUDIT.md

@@ -1,48 +0,0 @@
-# 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/cc-ship-issue-pr/SKILL.md

@@ -1,42 +0,0 @@
----
-name: cc-ship-issue-pr
-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
-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 回访时才声称已合并并回访。

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

@@ -1,83 +0,0 @@
-# Claude Code Runtime Contract
-
-仅在共享流程进入外部专家或 follow-up 分支时读取。
-
-## Codex 通道
-
-默认由主进程负责 Git 历史和 GitHub，除非当前任务明确另行分配责任。它把改动落在工作树，由 Claude Code 主进程核验、验证和分组提交。
-
-- **方案讨论 / 实现 / 重修复**：`Agent(subagent_type: "codex:codex-rescue")`。
-- **普通 review**：Codex companion 的 `review` 子命令。
-- **adversarial review**：Codex companion 的 `adversarial-review` 子命令。
-- **定制上下文审查**：只读 `Agent(subagent_type: "codex:codex-rescue")`，prompt 明确禁止写操作和递归委派。
-
-companion 每次调用都动态解析插件路径：
-
-```bash
-CODEX_ROOT=$(/bin/ls -d ~/.claude/plugins/marketplaces/openai-codex/plugins/codex 2>/dev/null \
-  || /bin/ls -d ~/.claude/plugins/cache/openai-codex/codex/*/ 2>/dev/null | sort -V | tail -1) \
-  && node "$CODEX_ROOT/scripts/codex-companion.mjs" --help
-```
-
-插件升级会换版本目录，不把解析结果硬编码回技能。
-
-普通 review：
-
-```bash
-CODEX_ROOT=$(/bin/ls -d ~/.claude/plugins/marketplaces/openai-codex/plugins/codex 2>/dev/null \
-  || /bin/ls -d ~/.claude/plugins/cache/openai-codex/codex/*/ 2>/dev/null | sort -V | tail -1) \
-  && node "$CODEX_ROOT/scripts/codex-companion.mjs" review --wait --base main
-```
-
-需要挑战方案时把 `review` 换成 `adversarial-review`。需要定制上下文时改派只读 Codex agent。
-
-## 补跑清单
-
-根据实际宿主权限与项目命令判断哪些验证可运行，不预设 Codex 的沙箱能力。只列本次改动需要且外部执行者无法完成的补跑项；迁移实 apply 不属于常规测试，先确认隔离环境与授权。
-
-## 取结果
-
-`codex:codex-rescue` 可能转后台。按 `workspaceRoot` 精确匹配当前仓库：
-
-```bash
-python3 - <<'PY'
-import glob, json, os
-root = os.path.realpath(os.getcwd())
-rows = []
-for f in glob.glob(os.path.expanduser('~/.claude/plugins/data/codex-openai-codex/state/*/state.json')):
-    for j in json.load(open(f)).get('jobs', []):
-        if os.path.realpath(j.get('workspaceRoot', '')) == root:
-            rows.append((j.get('createdAt'), j.get('id'), j.get('kind'), j.get('status'), j.get('phase'), f))
-for r in sorted(rows)[-5:]:
-    print(r)
-PY
-```
-
-定位到 job 后读取同目录 `jobs/<id>.json`。只有 `status=completed` 且 `phase=done` 才算返回，报告正文取 `result.rawOutput`。
-
-## 等待与活性排查
-
-所有通道（含 follow-up）遵守共享流程的「委派活性与接管」规则。等待期间 Codex 独占分配的责任文件，主进程可继续不重叠的工作；责任无法隔离时使用独立 worktree。
-
-派发后保存本次 job/agent ID、worktree 和日志路径；上方按仓库列举 job 的脚本只用于发现候选，结合派发时间与任务信息确认后固定 ID，后续不得自动改查最新 job。保存派发基线，约每 2 分钟比较：
-
-- 本次 job 的新增日志、工具事件、输出正文，以及 `status` / `phase` 的实际变化。状态文件 mtime 刷新但内容未变不算进展。
-- 本次责任文件的内容变化：比较责任文件的 `git diff --binary HEAD -- <paths>` 内容指纹，并记录相关未跟踪文件的内容指纹；删除、新增、同一脏文件的再次修改都应被识别。只读审查不要求有文件修改。
-- 当前子命令与进程状态、权限请求或外部依赖等待。观测失败记为未知，不能当作无活动。
-
-连续多个观测窗口没有进展时，读取日志尾部和子命令状态，向原 agent 查询当前步骤及阻塞点；这个条件只触发排查，不触发停止或换执行者。重复错误、空心跳或无关文件变化不能证明任务在推进。
-
-companion 的 `review --wait` / `adversarial-review --wait` 也通过宿主异步工具启动，保留会话 ID 并读取输出和本次 job；宿主单次等待结束后继续观察同一会话，不给前台命令套固定时长的自动终止器。只有确认失败或排查证实无法推进，才按共享接管规则处理；正常运行但尚未返回不算通道不可用。
-
-## 阶段与报告映射
-
-- 阶段四方案讨论：只读 Codex agent；主进程先写初步方案，最终拍板权在主进程。
-- 阶段四实现与阶段 7.4 重修复：可写 Codex agent，prompt 要求不 commit、不 push、不碰 GitHub、不递归委派。
-- 阶段 7.3：先按共享流程复用已有审查；复杂度门禁命中且本次交付尚未用过 Codex 独立审查时执行 review（创建 PR 前的审查也计数）；需要挑战方案时执行 adversarial review。
-- reviewer：`Claude Code 主进程自审 / codex native review / codex adversarial review / codex 只读 subagent`。
-
-Codex 返回后主进程必须直读源码和 diff 核验，不采信转述。重改动实现通道不可用时由主进程接手剩余工作并注明实际执行者；条件式独立审查不可用时由主进程完成本轮自审并在报告标明降级。
-
-## Follow-up
-
-使用 `Agent(subagent_type: "general-purpose", run_in_background: true)`，prompt 指定 worktree 绝对路径并要求调用 `cc-ship-issue-pr`。派发深度只允许一层；子 agent 发现的新 follow-up 只建 Issue。派不动 Codex 时子 agent 自己实现，并在 PR body 记录主进程直改。

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

@@ -1,42 +0,0 @@
----
-name: 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
-AGENTS_ROOT="${AGENTS_HOME:-$HOME/.agents}"
-SHIP_CORE="$AGENTS_ROOT/references/ship-issue-pr-core.md"
-test -f "$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)。该文件是本入口的平台调用契约；共享流程提供交付参考，冲突按本入口的优先级解决。
-
-按当前任务约定的终点报告完成；只有实际 `mergedAt` 非空并完成 Issue 回访时才声称已合并并回访。

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

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

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

@@ -1,50 +0,0 @@
-# Codex Runtime Contract
-
-仅在共享流程进入外部专家或 follow-up 分支时读取。
-
-## Claude 技能路由
-
-用户显式调用 `oo-ship-issue-pr` 后，按下表调用其依赖技能。读取对应 `SKILL.md` 的当前模式与必要约束，再执行适用流程；路径相对于本文件，`dx initial` 会将这些技能安装在同一个 skills 根目录下。
-
-| 共享流程阶段 | 调用技能 | 本阶段目标 |
-|---|---|---|
-| 阶段四方案讨论 | [ask_cc](../../ask_cc/SKILL.md) | 只读咨询，裁决初步方案、备选与取舍 |
-| 阶段 7.3 review | [ask_cc](../../ask_cc/SKILL.md) | 对照 Issue 与当前 diff 返回独立 findings |
-| 阶段 7.3 adversarial review | [ask_cc](../../ask_cc/SKILL.md) | 挑战假设、不变量、反例与失败路径 |
-| 阶段四重改动实现、阶段 7.4 重修复 | [delegate-cc](../../delegate-cc/SKILL.md) 的 `task` 模式 | 按最终方案修改代码并提供验证结果 |
-
-本入口只补充交付上下文与验收要求。CLI 参数、模型顺序、权限配置、等待与超时、状态解析、接续及降级统一按依赖技能执行，不在这里另写调用脚本或重试链。依赖文件缺失时先定位现有安装；确需恢复且在任务范围内时使用 `dx initial`。依赖仍不可用时由主进程继续可完成的实现或自审，说明缺失能力，不冒充外部审查。
-
-所有通道（含 follow-up）遵守共享流程的「委派活性与接管」规则。依赖脚本的 `--timeout` 是无活动告警阈值；读取其 PID、输出字节和文件观测摘要，疑似停滞时检查原会话与工作树。宿主单次等待结束后继续观察同一会话，不设置按总耗时自动终止的外层超时器，也不把尚未返回当作降级依据。
-
-## 交接上下文
-
-每次交接包含当前 worktree 绝对路径、阶段、Issue 原文与逐条验收标准、base，以及该阶段所需的方案、代码和验证证据。任务仅覆盖当前阶段，不运行完整 `oo-ship-issue-pr`；Git 历史、GitHub 操作、权威验证和最终事实核验由 Codex 主进程负责。
-
-### 咨询与独立审查
-
-`ask_cc` 的咨询模式无工具权限。主进程先读取适用的 `AGENTS.md`、相关源码和当前 diff，将必要内容连同文件路径、行号、验证结果写进咨询材料；审查材料覆盖整个 PR diff，另附影响判断所需的上下文。仅提供仓库路径或要求 Claude 自行读文件不构成完整交接。证据不足时由主进程补充材料后继续同一审查阶段。
-
-- 方案讨论：附主进程初步方案、备选与取舍、希望裁决的具体问题；最终方案由主进程拍板。
-- 普通 review：要求按严重级返回 findings，每项包含 `文件:行号`、证据、影响和具体修法。
-- adversarial review：先挑战方案假设、构造反例和失败路径，再按同样格式返回 findings。
-
-审查使用全新独立上下文，不复用实现或修复会话。通过依赖技能降级后，只有未参与实现或修复的独立执行者完成的审查才计入外部专家审查；主进程自审不得冒充独立审查。
-
-### 实现与修复
-
-按 `delegate-cc` 的任务书要求，附最终方案原文、可修改文件或模块、适用项目指令、验收标准及仓库实际验证命令。保护已有改动，只在指定 worktree 和分配范围内工作，改动留在工作树。需要 Claude 运行验证时按该技能声明允许的具体命令。
-
-## 验收与报告
-
-取得结果、等待停止、处理部分改动、接续或降级均按依赖技能执行。主进程取得最终结果后直读源码和 diff，核验结论、合并重复项并记录拒绝依据；仅派发成功或返回成功声明不算阶段完成。
-
-外部执行者提供命令、代码版本、环境与可读输出后，主进程核对证据并复用有效结果；只补跑缺失、失效或无法核实的验证。报告未运行项及实际原因，不因执行者身份重复全部测试。
-
-阶段 7.3 仍服从共享流程的证据复用、复杂度门禁和每 PR 最多一次外部专家审查约束。创建 PR 前已有的独立外部审查也继续计数并按覆盖范围复用；同一阶段因证据不足补充材料或按依赖技能降级，不能被当作后续轮次重新派发审查的额度。
-
-reviewer 按实际执行者记录为 `Codex 主进程自审`、`Claude Code（ask_cc）review/adversarial review` 或实际降级执行者，并记录依赖技能返回的请求模型及降级情况。实现与修复记录使用 `delegate-cc task` 及实际执行者；自身接管的审查记为自审，不计入外部专家审查。
-
-## Follow-up
-
-完整 follow-up 包含 Git/PR 交付，使用 Codex `spawn_agent` 的 `worker` 角色在后台承接；Claude 技能只负责上表中的专家阶段。prompt 指定 worktree 绝对路径并要求调用 `oo-ship-issue-pr`。明确告知 worker 它不是代码库中唯一执行者，不回退其他人的改动，只在指定 worktree 工作。派发深度只允许一层；worker 发现的新 follow-up 只建 Issue。