view-workflow（查看GitHubActions工作流程）：一句话问清 CI 到底卡在哪，让工作流状态、失败日志和作业耗时一次看全
- 一句话定位：在 AI 编程助手/命令行里用一条
/view-workflow指令，直接拉取某个 GitHub 仓库或 PR 的工作流程运行状态、各作业结果、失败日志与耗时，不用来回切浏览器。 - 核心能力：按仓库查看最近运行、按运行 ID 查看某次运行详情、按 PR 编号查看该 PR 的流水线状态，并自动归类「失败 / 通过 / 跳过」作业。
- 使用前提：GitHub MCP 服务器已安装并配置完成、OAuth 认证已完成、对目标仓库有访问权限（这是该技能能否跑起来的三道门槛）。
- 最适合谁：频繁提交代码、盯 PR 状态的开发者；需要快速定位 CI 失败原因的值班同学；以及负责合并 PR、判断「能否上线」的团队负责人。
- 差异点：它不只给一个「红/绿」结论，还会把失败作业的日志片段、作业耗时与时间戳、触发者信息一并呈现，并给出修复建议与后续可衔接的命令。
1. 该技能叫什么？如何下载安装 AI 技能提升开发效率？
基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | 查看GitHubActions工作流程Skill |
| 技能英文名 | view-workflow |
| 技能ID | 14054 |
| 命令形态 | /view-workflow [参数]，同时也以 github:view-workflow 的形式标注 |
| 官方概要 | 查看GitHub Actions工作流程运行和状态 |
它解决什么问题？
在真实开发流程里，代码推到 GitHub 之后，真正的「裁判」是 Actions 流水线：构建过不过、测试挂没挂、代码检查有没有告警、部署是不是被跳过。传统做法是打开浏览器 → 找到仓库 → 进入 Actions 标签 → 找到那次运行 → 点进每个作业 → 翻日志，一次排查要在多个页面之间跳好几回。view-workflow 把这个过程压缩成一句话：告诉它「哪个仓库、哪次运行」，它就把状态、作业、日志、耗时一起整理好返回。
安装与配置步骤（一键装好、立刻能用）
- 准备账号权限：确认你的 GitHub 账号对目标仓库有访问权限（私有仓库尤其要确认）。
- 安装 GitHub MCP 服务器：该技能依赖 GitHub MCP 服务器提供数据访问能力，需先在所用的 AI 客户端/开发环境中完成 MCP 服务器的安装与配置。具体的安装命令、配置文件路径与字段，请以官方说明为准。
- 完成 OAuth 认证：按官方指引完成 GitHub 的 OAuth 授权，这一步没做，技能会在取数据时被拦下。
- 载入技能：将
view-workflow技能加载到你的技能清单中（不同客户端的加载入口不同，以官方说明为准）。 - 验证是否生效：输入
/view-workflow 你的组织/你的仓库。如果返回「## 最近的工作流程运行」并列出运行编号、状态、分支、触发者与作业清单，说明安装成功；若返回认证错误或无权限提示，回到第 2、3 步检查 MCP 服务器与授权状态。
2. 该技能的主要功能和特点
- 按仓库看全局：只给「所有者/仓库」，就能拿到最近的工作流程运行列表，快速判断当前主干/分支是否健康。
- 按运行 ID 看细节：传入运行 ID，可查看该次运行的完整信息，适合深挖某一次失败。
- 按 PR 编号看状态：传入 PR 编号，直接查看这个拉取请求触发的流水线情况，是合并前判断「能不能合」的高效手段。
- 作业级拆分展示：把一次运行里的各个作业拆开呈现，明确哪个作业通过、哪个失败、哪个被跳过，并附带各自的耗时。
- 失败日志直接给出：失败作业会带回日志片段，例如测试断言的实际值与预期值差异，省去层层点开日志页面的动作。
- 状态、耗时、时间戳、触发信息一屏呈现：运行状态、总耗时、完成时间、触发者（如「由 @某人 推送」）、分支名都在输出里。
- 附带排障建议：对失败运行会给出可执行的建议，例如检查测试环境中的数据库连接、审查超时设置、修复后重跑。
- 命令间可衔接：与
/review-pr（完整 PR 审查，含工作流程状态）、/create-pr（创建会触发工作流的 PR）、/create-issue（为工作流失败创建问题）形成一条顺滑的操作链。
和普通工具比强在哪？ 相比「网页控制台 + 人眼扫日志」，它把「查询 + 汇总 + 归类 + 给建议」合并成一次对话；相比纯命令行工具，它不需要你记住复杂的子命令与参数组合，用自然语言式的参数表达就能拿到结构化结果。
3. 如何使用该技能？
基本语法
/view-workflow [所有者/仓库] [运行ID或PR编号]
参数说明：所有者/仓库 为必需项，格式是「所有者/仓库」；运行ID 与 PR编号 为可选项，用于聚焦到某一次运行或某个拉取请求。
操作步骤
- 确认当前想解决的问题：是「看仓库最近整体状态」，还是「查某次失败」「查某个 PR」。这决定你传不传第二个参数。
- 只查仓库最新状态：输入
/view-workflow 我的组织/我的仓库，输出会列出「## 最近的工作流程运行」，包括运行编号、工作流名称、状态（运行中/成功/失败）、分支、触发者、开始时间与各作业状态。 - 查指定运行：输入
/view-workflow 我的组织/我的仓库 1232，输出会聚焦到该次运行，展示状态、分支、总耗时，并按「失败 / 通过 / 跳过」对作业分类。 - 查指定 PR 的流水线：把第二个参数换成 PR 编号即可查看该 PR 的工作流程情况，用于合并前的准入判断。
- 读结果、定动作：先看失败作业的日志片段定位错误类型（测试失败 / 构建错误 / 超时），再按输出的建议处理，必要时用
/create-issue把失败沉淀为待办。 - 回归验证：修复并推送后，重新执行同一条命令确认状态转绿，并对比前后耗时。
输入输出示例（查看失败运行）
输入：/view-workflow 我的组织/我的仓库 1232
输出要点：运行 #1232「CI管道」状态为失败，分支「功能/新功能」，总耗时 2 分 45 秒；作业分组显示——失败：测试（2 分 15 秒），错误信息为「测试套件失败，有 3 个失败」，并给出 POST /login 期望 200、实际 500 的断言片段；通过：构建（1 分 18 秒）、代码检查（24 秒）；跳过：部署（因测试失败而跳过）。随后给出三条建议：检查测试环境数据库连接、审查测试超时设置、修复后重新运行。
使用提示
- 活跃开发期间用它盯工作流，比反复刷新网页更省注意力；
- 失败作业要「立即查」，越早看日志上下文越完整；
- 对比多次运行的耗时，能识别出哪些作业是瓶颈；
- 关注某条测试是否反复失败，据此判断是不是不稳定的测试；
- 用工作流程状态作为 PR 是否具备合并条件的重要依据。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| view-workflow（本技能） | 对话式 GitHub Actions 状态查询技能 | 按仓库/运行ID/PR 查询运行与作业状态、失败日志、耗时、触发信息，并给建议 | 需先装好 GitHub MCP 服务器并完成 OAuth 认证；之后一条命令即用 | 日常盯流水线、快速定位失败、PR 合并前检查 | 优势：一屏汇总 + 自动归类 + 带建议，可与 PR 相关命令串联；不足：强依赖 MCP 与授权环境，未配置前无法使用 |
| GitHub Actions 网页控制台 | 官方图形界面 | 运行历史、作业详情、完整日志、重跑与配置管理 | 零安装，浏览器登录即可 | 需要可视化配置工作流、查看超长日志 | 优势：官方全功能、可编辑配置；不足：多页面跳转、信息分散，逐条排查效率一般 |
| GitHub CLI（gh 系列命令） | 官方命令行工具 | 在终端查看运行列表、查看日志、重跑等 | 需安装 CLI 并登录授权 | 终端重度用户、脚本化批量操作 | 优势：轻量、可编排；不足：需要记命令与参数，输出偏原始，缺少面向「诊断」的归纳建议 |
| act（本地运行工作流） | 本地模拟执行工具 | 在本机运行 Actions 工作流做验证 | 需本地安装 Docker 等依赖 | 改工作流配置后的本地快速回归 | 优势：不消耗云端额度、调试快；不足：环境与真实 runner 存在差异，仍需云端结果做最终确认 |
怎么选？ 如果你已经在用 AI 助手 / MCP 环境工作，希望「问一句就有结论」，选本技能；需要编辑工作流 YAML 或看完整原始日志，回网页控制台；要在 CI/CD 脚本里做自动化，用 GitHub CLI 更合适；只想在推代码前本地先验一遍，配合 act 使用体验更好。
5. 该技能的典型应用场景与实际体验情况
场景一：后端开发者提交后想立刻知道「红了没」
角色：正在开发「用户认证」功能的工程师，刚 push 到功能分支。痛点：要确认构建、测试、代码检查三步是否都过。用法：/view-workflow 我的组织/我的仓库，输出里能看到运行正在进行中，构建已通过（1 分 23 秒）、测试仍在运行、代码检查与部署待处理。体验：不用切窗口就能判断「还要再等一会儿」，对正在进行的运行也有清晰进度感；注意运行中的作业耗时是动态的，别把「运行中」误读为卡死。
场景二：值班同学处理失败的 CI
角色：负责当天构建健康的值班开发者。痛点：PR 被打回，只看到一片红，不知道具体哪条断言挂了。用法：拿到运行 ID 后执行 /view-workflow 我的组织/我的仓库 1232。体验：技能直接把失败作业的日志片段和断言差异摆出来，并提示「部署因测试失败而跳过」，一下子就知道不是部署配置的问题；建议中的「检查测试环境数据库连接」也给了明确方向。注意：日志是片段式呈现，遇到超长堆栈仍需回官方日志页看全量。
场景三：技术负责人做 PR 合并决策
角色：需要合并代码的项目维护者。痛点：评审意见都通过了，但不确定流水线是否真的全绿。用法：用 PR 编号查询该 PR 的工作流程，或直接用 /review-pr 做包含工作流程状态的完整审查。体验：把「代码评审」和「流水线状态」放在同一条决策链上，减少「合了才发现红」的尴尬；注意要确认查询的是最新一次运行，而不是历史运行。
场景四：性能与稳定性观察 角色：关注交付效率的团队。痛点：说不清流水线到底慢在哪、哪些测试反复失败。用法：多次运行同一条命令，对比各作业耗时与失败分布。体验：作业级耗时和时间戳让瓶颈可见，反复失败的测试也很容易被识别出来；注意这只是观察手段，优化仍需改动工作流配置或测试代码。
整体上手难度偏低——只要前置的 MCP 与授权配好，第一次用基本就能看懂输出结构；真正的学习成本在于「读懂失败日志并判断根因」。
6. 该技能能为用户带来的价值
- 效率提升：把「打开网页 → 多层跳转 → 逐个作业点日志」的多步操作压缩为一条命令，尤其是排查失败时，信息获取从「找」变成「读」。
- 门槛降低：不需要记 GitHub CLI 的子命令与参数组合，也不必熟悉 Actions 页面的层级结构，用「所有者/仓库 + 运行ID/PR编号」就能定位。
- 决策更快：作业级状态与耗时、时间戳、触发者集中呈现，PR 是否能合并、是否需要重跑、是否需要拉人排查，判断路径更短。
- 协作更顺：失败运行可直接衔接
/create-issue沉淀问题，配合/review-pr、/create-pr形成「建 PR → 看流水线 → 评审 → 记录问题」的闭环。 - 长期价值：持续用同一套命令观察流水线，会自然积累出对「哪些作业慢、哪些测试不稳」的团队认知，为后续的 CI 优化提供事实依据。
7. 常见问题 FAQ
Q1：这个技能怎么安装？装完怎么确认能用？
先确保 GitHub MCP 服务器已安装并配置、OAuth 认证已完成，再把 view-workflow 技能加载到你的技能环境（具体命令与入口以官方说明为准）。验证方式很直接：执行 /view-workflow 你的组织/你的仓库，能返回最近的工作流程运行列表即表示生效。
Q2：它是免费的吗？会消耗什么？ 该技能本身是一个查询型技能，其可用性取决于你所用的 AI 客户端/MCP 环境以及 GitHub 账号的权限与配额策略，具体计费与限额以官方说明为准。它读取的是你已有权限的仓库数据，不会绕过 GitHub 的访问控制。
Q3：适合谁用？不适合谁？ 适合频繁提交代码、需要盯 PR 状态、经常排查 CI 失败的开发者与团队负责人。如果你主要工作是编辑工作流 YAML 配置，或需要查看未截断的超长日志，官方网页控制台仍是更合适的选择；如果你要做脚本化批量操作，GitHub CLI 更对路。
Q4：为什么查不到数据 / 报权限错误？ 按顺序排查：GitHub MCP 服务器是否安装并配置正确；OAuth 认证是否已完成且未过期；账号对目标仓库是否有访问权限（私有仓库尤其注意）；参数格式是否为「所有者/仓库」，运行ID或 PR 编号是否写对。
Q5：和 /review-pr、/create-issue 有什么区别，该怎么配合？
view-workflow 专注「看工作流运行和状态」，是诊断工具；/review-pr 是包含工作流程状态在内的完整 PR 审查；/create-issue 用于把工作流失败转成可跟踪的问题。日常用法是：先用 view-workflow 定位失败，再用 /create-issue 记录，合并前用 /review-pr 做整体确认。