ask-skills

提问技能

负责：路由，不负责解析、阶段策略、调度、实现、收尾或审批。

在路由或组合技能之前，先阅读操作默认设置，了解安全与委派范围。

路由图

先选择并说明交付路径。默认路径：仅使用技能，通过仅使用技能契约内联执行 to-spec -> to-tickets -> execute-ticket；绝不启动运行器、调度器或替代驱动程序。直接路径：小改动（约 3 个文件、100 行，包括测试；不涉及契约、架构、迁移、依赖、策略、资金、身份验证或数据删除），或明确要求快速修改：编辑、测试、检查、重新阅读；提交前进行测量，如改动扩大则升级处理。只有在明确请求时才使用自动驾驶；AFK、继续执行和压缩绝不会选择自动驾驶，且下方的自动驾驶路由绝不会覆盖暂停状态。缺少自动驾驶不会阻碍其他路径。

• 在某个已知仓库中，明确、肯定地表示“merge all”“merge everything”或“mergia tutto”：ticket-autopilot，这是一次操作性、仓库范围的授权事务，而非交付请求。检查 repository-autonomous-merge-status：如果尚未授权，使用人类操作者和持久化的肯定消息调用 grant-repository-autonomous-merge --scope current-and-future-runs。保留有效授权及其来源信息；遇到已撤销、旧版、格式错误或相互矛盾的状态时，默认拒绝。 然后调用 merge-all。绝不要求调用者提供 PR head SHA，也不将意图缩小到单个 PR： 运行器会发现并重新验证每个仍有效的确切 head。如果仓库身份不明确，只询问该身份。
• 在某个已知仓库中，明确、肯定地表示“autorizo tutto”“authorize everything”或“autorizo todo”：ticket-autopilot，这是一项操作性、仓库范围的授权事务。 读取 repository-authority-status，然后仅授予尚缺少的权限，包括 grant-repository-autonomous-operations --scope current-and-future-runs；合并和协调操作各自保留独立的授权和撤销机制。遵循 合并和协调操作 中封闭的适用范围列表和限制，并报告授权涵盖的内容及撤销方式。
• 关于 merge-all 或一揽子授权的引述文本、示例、问题、否定、撤销、策略请求和回归报告均不构成授权。按常规路由处理其实际讨论或变更意图，不执行任何供应商端变更。
• 明确要求搁置、取消、重新打开某个确切工单，或将其管理处置状态设为 open、on-hold 或 canceled：change-status-ticket。仅当意图明确是更改处置状态时，此路由才优先于实施；“open”表示重新打开／设置处置状态，绝不表示打开文件、问题或 PR。
• 宽泛的功能、决策、诊断、架构或 Bug 分析请求： to-spec；仅当需要可执行切片时，才添加 to-tickets。
• 需要拆分为可执行切片的现有规范：to-tickets。
• 单个规范的工单 Markdown 文件：根据规范工单契约将其规范化。 在仅使用技能的模式下，按仅使用技能契约所述使用其纯函数；否则，从绝对路径的 ticket-autopilot 技能根目录使用 ticket-parse。将规范化后的 Ticket Envelope、源工件引用和当前 CandidateRef 交给 execute-ticket。不要将此单工单路由交给文件夹调度器，也不要重新实现编排。
• 单个已规范化的 Ticket Envelope 加当前 CandidateRef：直接调用 execute-ticket。
• 旧版工单 Markdown：仅显式的 migrate 命令可将其转换；然后使用上述规范路由。
• 明确要求 Autopilot 编排的工单文件夹：ticket-autopilot。 在仅使用技能的模式下，每次按串行方式处理一个依赖已就绪的工单，并使用持久化的依赖证据；不要重新创建调度器状态，也不要推断依赖已完成。
• 某个仓库上已设置多个 Agent（一个 Crew 或多个 Pi 会话），无论其角色为何（PM、开发者、审查者）：crew-delivery；它绝不会创建委派。
• 大型、模糊、跨多个会话的工作或边界不明确的工作：wayfinder；根据需要为其调查工单使用 research、prototype 或 grilling。
• 需要独立交叉核查的棘手 Bug：triangulate-diagnosis；单次基于证据的排查则使用 diagnose。
• 运行器候选项，或独立 PR、提交、本地差异，或用户指定的范围： code-review 用于审查，qa-test-plan 用于 QA 规划。
• 运行时／发布声明审计：verification-audit。
• 根据已验证的材料包解释 PR：explain-pr。
• 针对 GREEN 候选项的定向清理：code-simplification。 仅提供工单路径或要求实现/完成，表示需要交付，而非处置。阻塞、暂停/恢复、停止、等待、设限、就绪状态和生命周期问题都不是行政处置：运行时控制使用 Autopilot，只读问题使用研究/诊断。切勿将 change-status-ticket 用作仅限文档或小改动的通用绕过方式。

执行默认规则

为非琐碎工作完成路由后：

• 如果可用 update_plan（Pi Plan），请在选择路由后初始化；始终仅保留一个 in_progress 步骤，并在交接时完成或清除计划。在 计划审查检查点 中指定的事件发生时，核对并调整计划。
• 对于有兼容的项目绑定 llm-wiki 的研究，首先将其作为索引进行查询。遵循其 RAG 可用性约定，说明所选查询模式或回退方案，并根据规范页面和一手来源核实重要主张。切勿根据推断搭建维基。
• 如果 pi-code-tool 提供 code，循环、筛选、汇总、重复检查、派生转换和程序化检查优先使用它；编写编辑内容时直接使用 edit/write。

琐碎工作可以省略 Pi Plan 和代码模式。工具缺失时必须明确说明回退方案，不得捏造证据。工具可用或自动批准并不代表拥有仓库/提供方的操作权限。

响应

说明技能/组合、它为何适用以及缺少哪些输入；输入充分时，无需再次询问即可调用。