Which Skill 是一个用于技能选择的路由器。当用户不知道自己该用哪个技能时，它读取用户描述的情况，然后给出一个技能名称，并附上一句话说明理由。它只推荐、不调用：多数技能都需要用户自己启动，只有用户才能发起它们。若情况确实模糊，它只问一个能区分分支的问题，而不是列出所有选项。
用途与工作流定位 大多数工作沿着一条直线流程运行（决定 → 规格 → 工单 → 构建），产物放在 .scratch/<slug>/ 下。它按用户实际所处的位置来路由：
- 只有模糊想法、希望被压力测试 → grill-with-docs（在已有代码库中为默认），或 grill-me 进行纯访谈
- 工作太大、一次会话做不完、需要决策地图 → wayfinder
- 需要来源的开放问题、需要带引用的发现 → research
- 只有别人能回答的问题、需要发给对方的文档 → to-questionnaire
- 已谈定、需要写成文字 → to-spec
- 已有规格、需要生成工单文件 → to-tickets
- 收到外部 issue 或 PR、需要分类并简报 → triage
- 单个工单、需要端到端构建 → implement
- 已有规格、需要本次会话内快速并行构建全部 → implement-spec（其中 implement <spec> all 表示逐个构建、不使用子代理）
- 已有地图、规格或工单、不想盯着 → autopilot
开始之前，每个仓库需要运行一次 setup，写入跟踪器、状态词汇和领域文档结构。只有人类能完成的步骤（第三方面板、凭证、CI 密钥、一次性切换）交给 wizard 编写操作指南。
代码存在之后
- 审查 diff → code-review；希望用四个独立模型替代单一模型 → panel
- 在运行中的应用里验证 → verify
- 交付本次会话的工作 → commit
- 编写或重写 PR 正文 → pr（代理也会自行使用）
- PR 上有待处理的评审评论 → resolve-review-comments
- 要把一个 PR 一路推进到合并（评审、检查、修复、合并）→ triage-github-pr
- 合并或变基受阻 → resolving-merge-conflicts
- 即将结束会话、想知道还有什么未完成 → closeout
出问题时
- 损坏、抛错、失败或变慢 → diagnosing-bugs
- 积压的生产或评审机器人问题 → 按来源使用 fix-nightwatch-issues、fix-posthog-issues 或 fix-github-issues
- 问题在于代码形态而非单个缺陷 → improve-codebase-architecture 找机会，architecture-satisfaction 运行重构循环，codebase-design 提供二者共用的词汇
- 怀疑某个模块有问题 → code-smells-audit
- 没有已知问题、但想找出下一个未被察觉的问题并作为 PR 修复 → sweep
- 不确定状态模型或 UI 方向是否成立 → prototype
仓库维护 housekeeper（低风险清理）、repository-cleanup（分支、PR、stash、worktree）、scratch-cleanup（整理研究文件、移除已完成的工作、报告 .scratch/ 中未完成的工作）、dependency-audit（升级计划）、retro（回看本次会话或近期日志以改进环境）、domain-modeling（术语与 ADR）、laravel-herd-worktrees（worktree 加 .test URL）。
上下文即将耗尽时 顺序很重要，能保留一手来源的最省成本做法优先：
- 工作仍装得下就继续，多数会话根本用不到其余步骤。
- 下一个任务确实独立时，开一个新会话，不携带、不丢失。
- 下一个代理需要本次会话所学时用 handoff，它写出文档，你从磁盘上的一手来源干净开始。
- 当昂贵部分是跑腿、只需要结论回来时，委派给子代理。
- 最后才压缩。总结一次访谈或诊断会话，会把一手来源替换成自信却错误的转述；优先用 handoff，在上下文消失前把记录写下来。
什么都不匹配时 直接说明并直接回答问题。因为必须点名一个技能就退而求其次，比不选更糟：它会把一整套工作流花在错误形态的问题上。有两个技能用于元工作而非工作本身：writing-for-agents（编写任何供代理阅读的文档）和 teach（在此工作区内学习一个概念）。当本回答没有奏效时，wait-what 是应当求助的那一个。