这个 Skill 能做什么，适合哪些场景？
这是 manaflow-ai/cmux 仓库内置的 25 个技能之一，位于 skills/cmux-test-bisect/SKILL.md。它针对 PR CI 只跑筛选测试、完整套件在 main 上悄悄变红的痛点，用 scripts/ci/package_bisect.py 在 CI 上对旧提交逐点跑测试并生成失败矩阵。注意：它专属于 cmux 仓库本身，只覆盖 Packages/iOS 与 Packages/Shared 下的 SwiftPM 包套件，所有探针都在 CI 上运行而非本机。适用前提是你能为 manaflow-ai/cmux 这个仓库派发 CI 任务。
- 从失败的 CI 运行中读取完整失败集，并区分偶发（flake）与真实回归
- 用 package_bisect.py 在 CI 上对指定提交区间逐点运行 Swift 包测试（每个探针推送 bisect/ 分支，把今天的 iOS CI 文件铺到旧提交上）
- 输出按测试×探针排列的失败矩阵，给出 broken by <sha>、flaky、failing at the oldest probe 等判定
- 支持按正则筛选测试、--patch 应用已知修复、--bisect 并行第二个实验
- 引导读 culprit PR 的 diff，判定是“测试过时”还是“代码回归”，并按不同方式修复
- 指导用 test-ios.yml 定向验证，并在收尾时清理 bisect/ 分支
- 维护 cmux 的开发者发现 Packages/iOS 下的某个包套件在 main 上红了，想知道是哪次提交打破的
- PR CI 只跑了被筛选的测试，完整套件已漂移多周，需要一次性定位所有失败
- 被问到“是哪个 PR 弄坏了这个测试”，需要逐测试归因并区分测试过时与代码回归
- 二分过程中旧提交构建挂掉（已知原因），需要用 --patch 跳过已知问题继续二分真正的疑问
- 不属于 manaflow-ai/cmux 仓库的开发者：所有命令都硬编码为该仓库的 CI 工作流、包名和 runner 配置，无法直接迁移到其他项目
- 想在本机快速二分的用户：该技能明确禁止在 Mac 本地做完整构建，全部依赖 CI 排队，单次等待可达 45 分钟
- 针对 cmuxTests（app-host）失败的场景：该技能说明这类失败另有自动二分（#14510），不适用本流程
如何安装这个 Skill？
- 该技能深度绑定 manaflow-ai/cmux 仓库内部基础设施（package_bisect.py、test-ios.yml、org remote、Blacksmith），对其他仓库不可复用。
- 使用时将向 org remote 推送探针分支并触发 CI 付费运行，且会临时去掉 package-lint 门；确认前请知晓这些外部副作用。
- 核心脚本与 test-ios.yml 未在本次审查证据中，未经执行验证；置信度为低。
- 仓库许可元数据为 NOASSERTION，服务器目录为 BUSL-1.1（商用受限），引用技能前请确认许可合规。
- 技能为英文，无中文界面或中文环境适配说明。
- Shell / 命令行
- 网络访问
- 本地文件系统
GitHub CLI (gh)python3gitaccess to manaflow-ai/cmux CI (test-ios.yml)macOS/Linux checkout of cmux with upstream remote
该仓库的 README 没有为安装技能集合给出具体命令（技能文档仅给出技能内使用的命令），来源未记载独立的安装步骤；该技能位于仓库 skills/cmux-test-bisect/ 目录，作为仓库一部分使用。
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/manaflow-ai/cmux.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/cmux-test-bisect" ~/.claude/skills/
rm -rf "$tmp"根据源仓库地址和 Skill 路径自动生成，只复制这个 Skill 的文件夹。如果上文有作者提供的安装方式，请优先按作者说明操作；想只在当前项目中使用，把 ~/.claude/skills 换成项目里的 .claude/skills。
如何使用这个 Skill？
安装后，把下面任意一句发给 Agent 即可触发：
- Packages/iOS 下的 CmuxMobileShell 套件在 main 上红了，帮我二分找出是哪个提交打破的
- 是哪个 PR 弄坏了这个测试？逐个测试判断是测试过时还是代码回归
- PR CI 只跑了筛选的测试，完整套件已经漂移几周了，用 CI 二分定位所有失败
- 旧提交构建会挂掉，已知原因，加 --patch 跳过后继续二分这几个失败测试
技能由触发语激活（套件在 main 上变红、PR CI 只跑了部分测试、或被问哪个 PR 弄坏了测试）。核心流程：
- 用 gh run view 拿到今天的失败集，必要时跑两遍全量套件排除 flake；先搜是否已有修复中的 PR。
- 在自己的 worktree（从 upstream/main）里启动二分：
T=scripts/ci/package_bisect.py
python3 $T --package CmuxMobileShell start --points 6 <old-sha>..upstream/main
python3 $T --package CmuxMobileShell status --wait # 最长 45 分钟
python3 $T --package CmuxMobileShell next --dispatch
python3 $T --package CmuxMobileShell cleanup- 读 status 打印的矩阵（X 失败 / . 通过 / - 未在该探针运行 / ? 等待 / E 编译或 runner 失败）。INCOMPLETE 探针后的 '-' 不是通过，需用 --patch 加挂起修复再二分一次。
- 读 culprit PR，逐测试判定 stale test（改测试以表达原意）或 regression（改代码），不确定时选择让测试名保持真实的那种读法并在 PR 中说明。
值得知道的选项：--filter 正则缩小套件、--paths 改变中点候选提交范围、--patch 可重复地为每个探针应用修复提交、--bisect <name> 并行第二个实验（--package/--bisect 须放在子命令前）。状态存于 <git-common-dir>/package-bisect/<name>.，由同一 checkout 的所有 worktree 共享，日志按尝试缓存以便 status --refetch 增量下载。
这个 Skill 有哪些优点和局限？
- 所有探针都在 CI 上运行，不需要在笔记本上完整构建 cmux
- 失败矩阵按测试×探针呈现，可直接区分 broken by / fixed by / flaky / 越界等情形
- 考虑了真实工程陷阱：旧提交带旧 CI 脚本、挂起测试导致假破窗、flake 与回归的区分、INCOMPLETE 探针的 '-' 不是通过
- 内置收尾纪律：cleanup 清理 bisect 分支、在 PR 中 credit 改变行为的原 PR
- 完全绑定 manaflow-ai/cmux 仓库：包名、test-ios.yml、runner（auto/Blacksmith）、org remote mf 都是该仓库专属
- 单次探针等待最长 45 分钟，二分成本依赖 CI 排队
- 许可证标注为 NOASSERTION，仓库整体为 GPL-3.0-or-later 加部分 BUSL-1.1（web/ 等），采用前需自行确认技能文件本身的许可边界
这个 Skill 与同类方案有什么区别？
与相关 Skills 并排比较；分数均按同一 FSRS 标准得出。
| Skill | FS 评分 | Star 数 | 最近更新 | License |
|---|---|---|---|---|
| cmux 测试二分定位（cmux-test-bisect） 本页 | 51 · 谨慎使用 | ★ 28k | 1 天前 | NOASSERTION |
| CI 组件截图基线调查 ✓ Microsoft · 官方 | 37 · 不推荐 | ★ 193k | 3 天前 | MIT |
| VS Code 冒烟测试助手 ✓ Microsoft · 官方 | 53 · 谨慎使用 | ★ 193k | 3 天前 | MIT |
| 疑难 Bug 诊断法 | 47 · 谨慎使用 | ★ 281k | 3 天前 | MIT |
| SkillHub 测试与 CI 规范 | 47 · 谨慎使用 | ★ 5.2k | 3 天前 | Apache-2.0 |
技能本身将可由 test-ios.yml 读取包任务的 ci.yml 运行与之区分（ci.yml 无包任务），并提及 app-host（cmuxTests）失败走独立的自动二分（#14510）；仓库层面与 tmux 的对比属于终端产品范畴，与本技能无关。
FollowSkills 如何评估这个 Skill？
技能操作透明：探针通过 CI 推送 bisict/<name>/<sha> 分支并可用 cleanup 删除，提供回滚路径；明确说明探针会覆盖旧提交的 CI 文件并去掉 lint 门。扣分点：推送分支到 org remote、触发付费 CI 运行均无显式用户确认步骤，被覆盖的 CI 安全门（lint gate）被丢弃这一副作用仅一句带过，隔离与最小权限论证不完整。
指令自洽且失败模式描述细致（INCOMPLETE 探针、`-` 不是通过、shallow checkout 修复、adopt/—refetch、watchdog 等都有可诊断的处理路径），但核心脚本 scripts/ci/package_bisect.py 未在证据中提供，静态审查无法复现关键路径；按锚点不超过 10 分，再因脚本不可见扣 1。
触发条件明确（main 上红测、PR CI 只跑过滤测试、询问哪个 PR 弄坏测试），并清晰划出非适用范围（app-host cmuxTests 走自动 bisect #14510，仅限六个 SwiftPM 包）。扣分点：完全绑定本仓库及其 CI 基础设施（test-ios.yml、Blacksmith runner、org remote），无中文支持说明，环境外几乎不可用。
文档分层合理（准备→执行→读矩阵→判定→落地），命名稳定、表格化 verdict 清晰。扣分点：技能目录无独立许可证文件（仓库级 NOASSERTION 元数据），无版本号、变更日志或维护责任人声明，对 #14510 等引用无链接稳定性保证。
解决了真实且高价值的问题（过滤式 PR CI 导致 main 长期红测），给出从定位到落地的完整产出路径。扣分点：静态审查无法验证输出格式与矩阵读取是否可直接使用，效果依赖未提供的脚本与 CI 行为，按锚点不超过 7 分。
有可审计的仓库内一手材料（CI 工作流、agents/openai.yaml、详细流程文档），但技能引用的 package_bisect.py 与 test-ios.yml 本身未在证据中出现，无独立第三方执行证据，按静态校准不超过 5 分，再扣 1。
点击维度查看打分理由
证据充分度：低 — 主要依赖静态检查、作者材料或有限演示；适合发现线索，不适合做高风险决策。
查看完整评分方法 →