sling

sling CLI

sling 是 StarSling 面向 Agent 的 GitHub Actions 命令行工具。它可查询 实时 CI 数据——一次运行、一个作业、一次尝试，或一个账号的运行器分钟数——数据来自 StarSling 的控制平面，结果以结构化 JSON 输出到 stdout，并使用稳定的退出代码表。此版本为 只读：它只读取和分析数据，没有任何 sling 命令会更改 GitHub 中的内容。

此技能负责根据请求选择合适的工具。 查询运行、作业或支出的实时情况 → 使用 sling。任何会 更改 CI 状态的操作 → 使用 gh。审计整个仓库中的工作流 文件 → 转交给负责该任务的审计技能，然后停止。不要为 sling 不支持的功能杜撰子命令；命令范围列出了完整命令清单。

此技能命令参考中的每一项信息都是从 sling 本身（v0.1.8）读取的，而非来自文档——已验证的各命令 JSON 结构请参阅references/command-reference.md。

预检：是否已安装并通过身份验证？

在每个会话中，首次运行 sling 命令前执行一次。

1. 是否在 PATH 中？ 运行 command -v sling。如果未找到，sling 可通过安装页面上发布的一行安装程序进行安装：https://docs.starsling.dev/sling-cli/installation——请将该页面提供给用户，让他们自行运行安装程序，不要凭记忆粘贴安装命令。它仅支持 Apple Silicon macOS 和 x64 glibc Linux；没有 Windows 版本，因此在 Windows 上请明确说明，并使用第 6 步中仅使用 gh 的方案。

2. 环境是否正常？ 运行 sling doctor --agent。它会在 stdout 上输出 {"checks": [{"key", "ok", "detail", ...}]}，并且在实际检查失败时退出码为 10（环境正常时为 0）。检查结果会指出问题所在。八项检查中有七项可采取措施——token、control_plane、clock_skew、git_remote、patch_tooling、version、org——因此应针对 ok: false 的检查采取措施，而不是猜测（第八项 agent_skill 仅供参考；见下文）。如果有多项检查为 ok: false，应先处理 control_plane：控制平面不可达会导致依赖它的 token 和 org 检查失败，而 token 检查仍会附带 fix_command: "sling login"——在服务中断时这会误导排查方向，因为设备授权流程也无法连接控制平面。先检查网络，绝不要先登录。"skipped": true 也可能表示“未检查”，原因正是如此——应查看 detail，而不只是标记。version 检查若为 warn: true，表示有升级提示，而非检查失败；它附带的任何 fix_command 都是安装程序的一行命令（一条 shell 管道），因此应告知用户，不要自行运行。如果无法进行版本比较（安装程序 URL 无法访问、服务提供的版本无法读取），version 会显示 ok: false, skipped: true——这表示“未检查”，而不是“版本过期”。 agent_skill 检查项同样仅供参考，绝不会导致 doctor 报告环境异常：只有当检查结果为 ok: false 且未标记 skipped 时，才算失败；而此检查项唯一的 ok: false 形式也会同时标记 skipped: true。它会报告此技能是否已为此机器上的编码 Agent 安装；即使你正在阅读此技能，它也可能显示“未安装”，因为它只会检查固定目录中的文件。因此，请连同详细信息一并报告该检查项，绝不要自行运行它的 fix_command——是否安装由用户决定（参见references/command-reference.md）。

3. 未通过身份验证（doctor 的 token 检查失败，或某命令以退出码 4 退出，且 stderr 中未指出组织）：请用户在自己的终端中运行 sling login，然后等待用户确认已完成。不要自行运行，也绝不要给它传入 --agent。 在处理退出码 4 之前，先查看 stderr。 You don't have access to org "<name>" 表示尚未安装应用，而不是凭据过期；这属于第 5 步，而不是这里的问题。即使如此，它最后仍会显示 Run \sling login`` ，因为通用装饰器会给每个 auth 类错误都附上这句话——所以错误信息和建议都指错了方向。再次登录虽能成功，却不会改变任何情况；在用户看来，这就像登录出了问题，而不是缺少应用安装。

   登录需要有人在浏览器前操作：sling login 会打印设备代码、打开 GitHub 授权页面，并一直等待有人批准。将它作为子进程启动，两方面都行不通——只有当命令已经结束或超时后，输出才会到达，因此代码在仍可使用时根本无法显示；而 --agent 会直接拒绝提示并以退出码 2 结束。这里没有自动化路径，假装有只会让会话一直挂起。

   凭据按用户保存在 ~/.config/sling/credentials，因此用户登录后，以该用户身份运行的 Agent 无需进一步设置即可通过身份验证。重新运行 sling doctor --agent 进行确认，然后继续。

4. 组织错误——你属于多个组织，但尚未选择一个。 doctor 的 org 检查列出多个 slug、关于组织歧义的退出码 2，或者某个 id 无法解析，但可能存在于你的其他组织中：运行 sling org switch <slug>，或在单条命令中传入 --org <slug>。

   大多数子命令接受 --org 和 --repo <owner/name>，但 sling logs 不接受；它会严格解析参数，并以退出码 2 拒绝这两个参数（Unknown flag "--org"）。路由表最常指向的就是这个命令，因此读取日志时，如果组织错误，应切换默认组织，而不是给调用添加标志。其他情况下，--repo 默认为当前目录的 git 远程地址，并且必须使用 owner/name 格式——只传仓库名会被拒绝，退出码为 2。

   如果你不属于任何组织，doctor 的 org 检查也会失败；情况看起来相似，但并非此处所说的问题。没有可切换到的 slug——那是第 5 步。

5. StarSling 门槛——应用未安装在你有权查看的任何位置。 sling 会报告由 StarSling GitHub App 收集的 CI 信息，因此有效登录在应用安装到 GitHub 组织之前看不到任何内容。两种情况，同一个原因，同一种解决办法：

   • 组织存在，但你看不到它——退出码 4，You don't have access to org "<name>"。先排除拼写错误。 对于根本不可能存在的 slug，返回的错误逐字相同，所以仅凭这条消息无法确认组织是否真实存在：sling org switch <slug> 会返回 Unknown org "<slug>" — your orgs: …，既能确认情况，也会列出组织。让别人把 GitHub App 安装到一个拼错名称的组织上，远不如什么也不说。下面的 URL 特例不适用于标志参数路径：通过 --repo/--org 传入第三方组织时，会在这里以退出码 4 结束（已验证：--repo vercel/skills），两者的处理不同——org switch 会列出你自己的组织；第三方组织则会转到第 6 步中的 gh 读取回退路径。错误信息最后会显示 Run \sling login``，但这行不可能解决问题：凭据从来都不是问题所在。通用装饰器会给每个 auth 类错误都附上这段后缀，因此在这种情况下应将其视为模板文字，而非建议。
   • 你完全不属于任何组织——退出码 2，You don't belong to any orgs yet.，并且 doctor 的 org 检查也会显示同样的信息。这是常见情况：有人安装 sling 并登录后，却还没有安装过应用；登录会成功，也不会提示缺少步骤。这里不要把退出码 2 当作标志错误，也不要让他们运行 sling org switch——没有组织可供切换。 沙盒化 Agent shell 自身也可能导致身份验证探测失败，因此请先在启用主机访问权限的情况下重试一次，再判断是否确实失败。

   无论哪种情况，都要停止并直截了当地告知用户——此技能给出的每个答案都来自 StarSling 对其运行记录的记录，因此在安装应用之前，没有可读取的运行数据，只能使用 gh 读取路径。请告知用户具体操作：在他们所询问的 CI 所属组织中，通过 https://github.com/apps/starslingdev 安装应用，或请组织所有者将他们添加进来。只有用户明确同意后，才继续使用仅限 gh 的路径；并在继续时说明哪些内容无法提供。

   用户粘贴的其他组织的 URL 不会进入此判断流程。 解析器只会搜索你所属的组织，因此，来自其他组织的 Actions URL 会以退出码 3（未找到）失败，而不是退出码 4——已通过 mastra-ai 的一个运行 URL 在线验证。应用安装的解决方案仅适用于用户所属的组织；对于第三方组织，正确的做法是使用第 6 步中的 gh 读取回退方案。

   仅限组织。 应用可以安装到个人仓库，但 StarSling 不会获取其中的作业，因此永远没有可报告的数据——应明确说明这一点，而不是报告空结果。

6. 如果完全无法安装或完成身份验证 sling，则对可实现的操作改用 gh 读取路径（gh run view、gh run view --log-failed），并直截了当地告知用户：没有 sling，就无法提供更深入的诊断——包括 sling why 的分类结果和 sling time 的阶段细分。不要悄悄降低功能。

   在承诺使用该路径之前，先执行下面的 gh 检查：如果两个 CLI 都不可用，就没有可用的回退方案；提前说明这一点，胜过逐个命令失败后才发现。

始终传入 --agent

--agent 是机器模式标志：将 JSON 输出到 stdout，不显示提示，不使用颜色。 每条数据命令都要传入该标志，并将 stdout 解析为 JSON。不要同时传入 --json——帮助页面会将两者一并显示（--json, --agent），具体表述因 命令而异。

**不要将它描述为一组较长标志的别名。**已发布的文档称它“与 --json --compact --no-input --no-color --yes 完全等效”，但在 v0.1.8 中，这个二进制文件根本没有 --compact 标志： 传入它不会产生任何变化，因为未知标志会被忽略，而不是因为它执行了什么操作。无论哪种情况，输出都是经过缩进的美化 JSON，因此应将 stdout 输入真正的 JSON 解析器，绝不要输入假设每行一个对象的面向行解析器。

**绝不要对 sling login 传入 --agent。**登录需要用户打开浏览器并批准设备代码，而 --agent 携带 --no-input，会拒绝提示，而不是显示提示——从而让唯一需要人工参与的命令以退出码 2 结束。 sling org switch 的情况也一样：在 --agent 模式下，它会拒绝选择器，因此请明确指定 slug（sling org switch acme --agent）。

• 根据退出码分支，绝不要根据 stdout 看起来是否为空来判断。只有在 stderr 是 TTY 时， 人类可见的附加信息（旋转指示器、摘要行、提示）才会输出到 stderr。6 和 10 是执行结果而非错误：它们会将完整 JSON 负载输出到 stdout，而 stderr 为空——不健康的 sling doctor --agent 会以 10 退出，但仍返回每项检查结果，这正是上文的预检要求你读取的内容。

  **非零退出码不代表 stdout 为空，格式正确的 JSON 正文也不代表成功。**如果某个任务没有存储日志，sling logs 会以 3 退出，但仍会输出 {"lines": [], "has_more": false, …}； 如果 ID 不明确，sling resolve 会以 2 退出，但仍会输出 {"candidates": […]}。因此，既要将 stdout 解析为 JSON，也要读取退出码；两者不一致时，以退出码为准。将空的 lines 数组报告为“日志中没有内容”，正是这项技能旨在防止的那种悄无声息的误报——原因在 stderr 中，即使 stdout 已成功解析，也仍值得读取。

• 在 --agent 模式下，每条数据命令都会返回 JSON，包括 sling logs （sling exit-codes 是帮助文本：退出码为 0，stdout 为空，说明文字在 stderr 中）。没有日志的任务会在负载中包含其自身的机器判别字段—— "local": {"empty": {"kind": "absent"}}——以及 "lines": []。

• 除 whoami 外，每条命令的 JSON 键名都采用 snake_case；whoami 会返回 camelCase 字段（userId、githubLogin、expiresAt）。请按命令配置解析器，而不是按本地与远程的规则配置。

这份约定中的陷阱汇总在 常见问题 下——首次解析前值得一读。

路由表

按顺序回答两个问题来决定。

**1. 请求会改变内容，还是只读取内容？**如果用户想要更改 CI 状态——重新运行任务、取消一次运行、触发工作流、启用或停用工作流、拉取工件——此版本的 sling 无法做到。请直接使用 gh；不要尝试用任何名称的 sling 子命令来完成这些操作。

**2. 如果请求只读取内容：它涉及某一次运行、某个任务或总体成本/用量，还是涉及整个仓库的 CI 配置？**某次运行、某个任务或支出归因 → 使用 sling。仓库的工作流 YAML、是否遵循最佳实践、安全态势或多次运行优化扫描 → 转交处理（见转交），不要自行读取 YAML。

用户询问……	使用	命令
某个作业为何失败	sling	sling why <run|job|attempt id|URL>
一次运行的墙钟时间花在了哪里（队列等待、配置、步骤还是拆除）	sling	sling time <run|job|attempt id|URL>
同上，但查看整个仓库的百分位数	sling	sling time --repo <owner/name> --window <n>d
最近的运行及其状态	sling	sling runs list [--branch --status --conclusion --trigger --workflow-path --label --window --limit]
某次运行的详情（其作业、尝试、运行器）	sling	sling runs show <run id|URL> [--wait] [--fail-fast]
某次运行中哪些作业失败，或整个仓库中的作业	sling	sling jobs list --run <id> / --repo <owner/name>
某个作业中哪个步骤失败，以及各步骤的耗时	sling	sling jobs show <job id|URL>
仅查看与故障相关的日志行	sling	sling logs <run|job|attempt id|URL> [--grep <re>] [--since <dur>] [--limit <n>]
将粘贴的 Actions URL 转换为运行、作业或尝试 ID	sling	sling resolve <id|URL> [--target run|job|attempt] — 覆盖多个作业的运行 ID 有歧义：退出码为 2，并在标准输出中返回 {"candidates": […]}。传入返回的候选 ID 之一（att_<jobid>.<n>）或 --target run；--target job/attempt 会再次指定类型，但仍返回相同的歧义结果
耗时或成本最高的项目	sling	sling top [--by workflow|job|label|repo|branch] [--metric ...]
按仓库／工作流／标签／日期统计的运行器分钟数和费用	sling	sling usage [--group-by <axis>] [--window <n>d]
本期应付金额或过往发票	sling	sling bill、sling bill history
可用的运行器标签／规格及其费用	sling	sling labels list
身份、组织、凭据、环境状态	sling	sling whoami、sling doctor、sling org switch — 以及由用户而非你运行的 sling login
重新运行一次运行或其失败的作业	gh	gh run rerun <run-id> [--failed]
取消正在进行的运行	gh	gh run cancel <run-id>
触发工作流（workflow_dispatch）	gh	gh workflow run <workflow> [-f key=value]
启用或禁用工作流	gh	gh workflow enable|disable <workflow>
下载制品	gh	gh run download <run-id>
删除一次运行	gh	gh run delete <run-id>
批准或拒绝待处理的部署	gh	gh api — 参见 references/gh-fallback.md
特定 PR 上的检查	gh	gh pr checks <pr> — 然后将失败的运行／作业 ID 带回 sling why / sling time
密钥或仓库／环境变量	gh	gh secret、gh variable
工作流文件的内容	两者都不使用	直接读取 .yml — 这是文件问题，不是 CLI 操作
整个仓库的评级、速度审查或安全扫描	两者都不使用	转交处理 — 参见转交审计技能

问题含糊不清时。 如果没有操作动词（重新运行／取消／触发／启用 ／禁用／下载），且问题涉及某次特定运行、作业或支出，则默认使用 sling：它用于读取数据，尝试起来没有成本。如果问题是只读的，但 sling 没有对应子命令——例如“这个 工作流的 on: 触发器包含什么”涉及 YAML 内容，而不是运行数据——应读取 文件，而不是强行通过任一 CLI 查询。

复合问题——“告诉我这次运行为什么失败，然后重新运行它”——需要按顺序分成两个 步骤：先执行 sling 部分（sling why），报告结果， 再将 gh 部分（gh run rerun）作为明确且单独说明的 操作执行；在承诺执行第二部分之前，先运行 gh 检查（见下文）：sling 能正常工作并不代表 gh 已登录。执行状态变更之前，务必告知用户将发生什么变化。

命令参考

各命令的完整标志以及每种响应经过验证的 JSON 格式： references/command-reference.md。所有现有命令的机器可读列表可在此查看，它能确保此技能不会凭空编造命令： references/command-surface.json。

简版，按 sling --help 中的分组方式排列：

• 身份验证与设置 — login、logout、whoami、doctor、org switch。
• 检查 CI — runs list、runs show、jobs list、jobs show、 logs、resolve。
• 诊断 — why（分类、证据、建议操作，以及可直接使用的 prompt 字段）、time（将总耗时细分为 queue_wait、provision、image_pull、cache_restore、checkout+patch、steps、cache_save、teardown）。
• 成本与容量 — usage、top、bill、bill history、 labels list。

值得养成的几个习惯：

• 对运行（ID 或 URL）执行 sling why，即使退出码为 0，也可能只会针对一个选定的作业给出答案 — 这一点已在一次包含三个作业的已取消运行中得到验证：它诊断了唯一失败的作业，完全没有提及另外两个作业或取消情况。在将该诊断报告为整个运行的根本原因之前，如果运行包含多个作业或未正常结束，请先确认运行中的作业集合（jobs list --run <id>）。
• 遇到失败时先从 why 入手，而不是从 logs 入手。why 在服务端进行分类，过程中不涉及大模型；其 suggested_actions[] 会提供准确的后续命令（通常是 sling logs --grep），无需你猜测匹配模式。其 prompt 字段专为 Agent 可直接执行而编写。
• **sling logs 是筛选工具，不是转储工具。**在获取完整日志之前，先使用 --grep 和 --limit；has_more 配合 --cursor 可分页获取剩余内容。

退出码

根据 $? 进行分支判断，并在命令执行后立即读取。仅凭输出推断会出错：成功结果可能为空，失败的命令也可能打印完整的 JSON 内容——logs 会以退出码 3 退出并返回 {"lines": []}，resolve 会以退出码 2 退出并返回 {"candidates": […]}；对仅包含多任务运行 ID 的命令，logs、why 和 time 也会如此，其中 why/time 完全不会向 stderr 输出内容。调用本身是有效的：从 stdout 读取候选项，并传入一个 ID（或 --target run），不要重新读取 --help，因为这里并没有用法错误。无论 stdout 为空还是可解析，都无法说明发生了什么；只有 $? 能说明。

代码	含义	处理方式
0	成功	—
1	意外的内部错误（崩溃）——或子命令不存在	先读取 stderr。unknown command "<name>" for "sling" 是路由错误，不是崩溃：二进制会列出实际支持的命令，因此应根据列表修正名称，而不是提交 bug 报告——下文 doctor 的 fix_command 注意事项就属于这种情况。stderr 中提到环境变量（SLING_HOST must be a valid https URL …）表示需要修正环境，而不是 bug。其他情况：不要盲目重试，并将 stderr 文本作为 bug 报告反馈
2	用法错误——标志无效、在 --agent 下拒绝提示词、组织存在歧义，或根本没有组织	先读取 stderr。You don't belong to any orgs yet. → 转到步骤 5，说明尚未安装应用；这绝不是标志问题。组织存在歧义 → 传入 --org 或运行 sling org switch。其他情况则根据 sling <cmd> --help 修正调用
3	未找到——在你可访问的任何组织中都没有对应的运行/任务/尝试，或者确实存在的任务没有保存日志	粘贴来自第三方组织的 URL 会导致此退出码，而不是退出码 4——解析器会搜索你的组织并报告未找到（No run/job/attempt matches that id in an org you can access）。对于用户不属于的组织，不要建议在该组织上安装应用：改用 gh 读取路径（公开仓库可正常响应），并说明无法使用更丰富的 sling 诊断。其他情况请尝试运行 sling resolve，确认组织，然后请用户确认 ID
4	身份验证错误——**或该组织未安装 StarSling，或通过标志指定了第三方组织。**采取操作前先读取 stderr 文本	You don't have access to org "<name>" → 该组织尚未安装应用（或用户不是其成员）；请引导用户访问 https://github.com/apps/starslingdev，不要重试登录。其他情况 → 请用户自行运行 sling login（需在浏览器中批准，绝不要使用 --agent），然后重试一次。如果重试后仍以退出码 4 退出，则立即停止并报告已核实的信息——绝不要要求用户再次登录
5	控制平面或 API 错误（5xx 或传输错误）	短暂等待（约 2 秒）后重试一次；如果再次失败，改用对应的 gh 读取方式，并说明无法访问 sling
6	部分结果——遥测数据不完整，但仍会生成结果（time、why）	不是错误。使用该结果，并告知用户结果不完整
7	请求过多（HTTP 429）	等待后重试一次。如果再次收到 429，则停止：改用对应的 gh 读取方式，并说明 sling 请求过多
10	远程操作结果失败——doctor 检查不健康，或 runs show --wait 检查的运行未成功	**不是 CLI 错误。**这就是需要报告的结果：说明哪项检查不健康，或报告运行失败

在 v0.1.8 中，sling exit-codes 只会打印 0–5；代码 6、7 和 10 都是真实存在且有文档说明的（而且 doctor --help 本身也列出了 10），因此应将该帮助文本视为精简版。对于本表未列出的任何非零代码，应将 stderr 告知用户，而不要猜测恢复方法。

注意事项

以下情况中，sling 的行为与其自身输出、--help 或文档所暗示的有所不同。这些情况都是通过运行二进制程序发现的；运行时不会主动提示。此处所有锁定版本的信息均已通过 sling v0.1.8 和 gh 2.93.0 验证——升级后请重新验证。

• doctor 的 fix_command 是建议，并非经过验证的命令。 在 0.1.2 中，它的 version 检查建议了一条不存在的命令——输出了 "fix_command": "sling update"，但所有版本中都没有 sling update（0.1.8 仍会将其识别为未知命令；现在该检查会输出安装程序单行命令）。其他检查会输出未填入占位符的模板：git_remote 会原样建议 git remote add origin <github-url>。切勿未经检查就运行 fix_command。这个一般性教训并不会随着原始错误修复而过时：工具打印出某个命令名称，并不能证明该工具支持它。
• 退出码 4 并不总是表示凭据已过期，而且在并非如此时，它给出的消息会误导用户。 如果组织从未安装过 StarSling，命令会失败并提示 You don't have access to org "<name>". Run \sling login``——这与会话过期时的消息格式相同，最后给出的建议也无法解决问题。采取行动前先阅读消息：如果消息中提到了组织，说明该组织尚未安装应用，而不是登录状态有问题。
• 空列表意味着覆盖盲区，绝不意味着已有结论。 无论仓库在该时间范围内确实没有运行记录，还是 StarSling 根本没有监控该仓库，sling runs list --repo <name> 都会返回 {"runs": []} 和退出码 0。从返回数据无法区分这两种情况，因此空结果意味着这项检查并未执行——应说明无法排除的原因，而不是把“你的仓库没有 CI 运行记录”当作事实报告。完全不存在的仓库在退出码 0 时也会返回相同的空数据格式（已在线验证），因此，如果答案很重要，可以通过简单的 gh 读取——gh repo view、gh run list——查明具体是哪一种情况。jobs list --repo（{"jobs": []}）、usage --repo（{"rows": []}）和 time --repo（{"phases": []}）也会返回同样无法区分这三种情况的空结果。time --repo 即使数据完整也会返回退出码 6，所以这里的“部分”没有任何指示作用；覆盖盲区在于空的阶段列表。
• 没有客户端超时机制。 如果控制平面连接被黑洞（数据包被丢弃，而非连接被拒绝），sling 会无限期挂起——已验证超过 45 秒——没有退出码，两个输出流也都没有内容。对耗时较长的调用设置超时；超时触发时，应报告超时本身：被终止的命令没有产生结果，而“没有结果”绝不等于“没有发现”。连接被拒绝时则会正常返回退出码 5。
• 未知标志会被忽略，而不会报错。 sling runs list --bogus 会以退出码 0 退出，并返回未经筛选的记录。因此，退出码 0 并不能证明筛选条件已生效——报告筛选后的结果前，请先检查返回的记录。
• --help 列出的标志并不完整。 runs list --help 未列出 --trigger、--workflow-path、--label 和时间窗口标志，但这些标志都能正常使用。--help 中没有列出某项，并不代表 CLI 不支持它；完整列表见 references/command-reference.md。
• 使用 --agent 时，sling logs 会返回 JSON——与所有其他数据命令一样，使用相同的结构化封装。（先前的一个修订版声称已发布文档与此不一致；其实并没有，文档正是这样说明的。真正较小的文档差异在于：文档称封装为每行一个对象，而实际返回的是带缩进的美化 JSON。）
• sling time 中阶段耗时为零，可能表示“未测量”。 在 v1 中，image_pull 和 cold_start 会合并到 provision 中，并以 0 报告，原因则记录在 meta.truncated 中。告知用户某个阶段耗时为零之前，请先查看该数组——把测量缺口报告成发现，会造成误报。
• 退出码 10 表示的是结果，而非失败。 doctor 检查未通过，以及 runs show --wait 遇到失败的运行时，都会以退出码 10 退出。请如实报告其内容。退出码 6 同样代表实际结果，只是被标记为部分结果。
• --agent 会悄无声息地包含 --yes。 由于 sling 目前是只读的，这并无影响，但不要把确认提示当作安全保障。
• sling runs show 不会提供 job_id——其中的 jobs[] 只包含 job_name 和 attempts[]。需要作业 ID 时，请使用 jobs list --run <id> 或 resolve。
• 当同一个键对应多个仓库时，sling top 可能会将仓库报告为 (multiple)。 不要将其直接作为仓库名称打印，而不解释它的含义。
• sling bill 有两个总额。 amount_due_usd 表示应付金额；amount_usd 表示抵扣前的金额。status: "open" 表示该周期仍在累计，因此这不是最终金额。

转交给审计技能

sling 读取实时运行数据，完全无法读取工作流配置，因此从结构上就无法审计、评分或扫描代码库。当对话转为“审计我的整个 CI 设置”“给我的 CI 打分”“为什么 CI 普遍很慢”或“这样安全吗”时，请停下来并指出合适的技能，不要反复对每次运行调用 sling：

需求	技能
配置最佳实践评分（“给我的 CI 打分”“CI 评分”）	ci-score
跨多次运行进行速度／运行器分钟数审计（“为什么 CI 很慢”）	ci-speedup
扫描工作流文件的安全性（“我的 CI 安全吗”）	ci-secure

每项技能都会读取本地检出，并运行各自的目录。指出相应技能，让用户自行运行；不要尝试根据运行数据模拟这些技能的结果。

只建议，不要自动串联调用。 如果 sling usage 或 sling top 显示出明显的成本异常值，或 sling time 多次显示某个阶段占主导，请在回答末尾建议使用 ci-speedup，从多次运行中查找根因并修复——sling 会显示这次运行很慢或成本很高；ci-speedup 会说明原因并提供修复方案。未经用户要求，绝不要调用其他技能。

gh 回退方案

此技能会调用的变更命令及其实际语法： references/gh-fallback.md。

在首次调用 gh 前进行 gh 检查。 如果未安装 gh，或 gh auth status 失败，gh 就无法执行任何操作——而且 gh 的身份验证与 sling 相互独立，因此 sling 可正常运行，并不能说明 gh 已登录。在沙盒 Agent Shell（Codex）中无法访问密钥环凭据：请先尝试启用主机访问权限后再判断失败原因，绝不要仅凭沙盒探测结果报告身份验证“已过期”。如果无法通过主机访问权限重试，请将 gh 的可用性报告为“未验证”，而不是“已过期”或“不可用”。然后停止，并明确告知用户其请求中的哪部分无法完成——通过 sling 仍可读取信息，但无法更改状态。提供路径（https://cli.github.com；然后运行 gh auth login），绝不要将未实际执行的操作报告为已完成。