用途：该技能用于在隔离的 git worktree 中处理单个开放的 GitHub issue，完成实现后交付。核心原则是 worktree 优先，不在主检出上实现。PR 机制（push、创建 PR、合并）交由 arc-git-pr-check 处理。
用法：用户以工单引用调用，可加 ship 模式。工单引用支持 #14 或 14（GitHub issue 编号），或 W-000014（issue 标题或正文中的 story ID）。若未提供引用则询问并停止。模式包括：--ship merge（独立运行时默认，squash 合并 PR 并清理 worktree）、--ship auto（启用 squash 自动合并后停止）、--ship pr（编排下默认，打开 PR 后停止，保留 worktree 和分支供审查迭代）。
主要步骤：解析 gh issue view 确认 issue 为 OPEN；从标题提取 W- ID 或使用 issue-<number>，并以 feat/<id>-<short-kebab-slug> 命名分支；按 WORKTREE.md 从仓库根创建 worktree 和分支，后续读写编辑测试提交均在该 worktree 进行；阅读 issue 正文与评论中的计划或验收标准，非平凡且无计划时运行 arc-planning-work；做满足验收标准的最小正确改动并运行测试、lint、类型检查；按 arc-conventional-commits 提交，正文含 Closes #<number>；按所选模式交付。独立运行时从 worktree 运行 arc-git-pr-check 脚本：run.sh --ship <merge|auto|pr> --title "<conventional title>" --body-file <path> --staged-only，不要用原始 gh 命令自行 push 或创建合并 PR。合并模式下 PR 合并后清理 worktree、剪枝并删除本地功能分支；pr 与 auto 模式保留 worktree 和分支并报告路径与 PR URL。
编排模式：父级负责创建和拥有 worktree、决定方案、检查证据并保留审查判断权。代码探索用 codex-explore，机械实现用 composer-implement，困难实现或调试用 codex-implement，独立正确性、回归、安全、验收标准审查用 codex-check，偏品味 UI/UX、API、架构、文案、文档、提示词或技能审查用 opus-review；Codex 不可用时回退到对应的 opus-explore、opus-check 或 opus-implement。写操作 worker 仅在隔离 worktree 内做限定编辑和验证，不得提交、push、评论、合并、部署、改密钥或动无关文件；审查 worker 只返回发现。验收后父级通过 mechanical-commit-push 提交推送、直接用 gh pr create 开 PR、用 mechanical-post-comment 发评论、用 mechanical-merge 执行明确授权的合并或自动合并。
限制：仅用于计划请求应改用 arc-planning-work；多 issue 并行用 arc-parallel-implement；对 --ship pr 打开的 PR 审查迭代用 arc-pr-review-loop。不要在已关闭 issue 上开工，不要修改主检出或无关 worktree 的文件，成功合并后不要遗留 worktree。官方文本未提供，价格、平台与效果等暂无资料。