/diagnosing-ci-and-merge-bottlenecks

name: diagnosing-ci-and-merge-bottlenecks
description: 'Diagnoses CI and pull request pipeline health for a GitHub repo with the engineering analytics MCP tools: pull-requests, workflow-health, pr-lifecycle, engineering-analytics-flaky-tests, engineering-analytics-team-ci-health, and the CI cost tools. Use when asked whether CI is getting faster or slower, which GitHub Actions workflow is slow or failing, how long PRs take from open to merge, which open PRs have failing or pending CI, where one pull request is stuck, what a failing test costs, which team owns the flakiest tests, or what CI costs for a PR or workflow. Triggers on "engineering analytics", "is CI getting slower", "slow workflow", "flaky CI", "time to merge", "cycle time", "PR throughput", "failing checks", "where is PR <n> stuck", "CI long pole", "CI cost". For a verdict on one CI failure use investigating-ci-failures. To save these numbers as insights use turning-engineering-analytics-into-insights.'

Diagnosing CI and merge bottlenecks

This skill finds where a pull request slows down between open and merge. You call named MCP tools and write no SQL. To take one failing test or one red run to a verdict, use the `investigating-ci-failures` skill.

Choosing a tool

| Question | Tool | How | | --------------------------------------------------------- | --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Is CI getting slower? Which workflow is slowest? | `workflow-health` | Call it over two adjacent windows, for example `date_from=-14d`, then `date_from=-28d` with `date_to=-14d`. Compare `p50_seconds` and `p95_seconds` per workflow. | | Which open PRs have failing or pending CI? | `pull-requests` | Keep rows where `ci.failing > 0` or `ci.pending > 0`. | | Which PRs are stuck open longest? | `pull-requests` | Keep open rows that are not drafts or bots. Sort by `created_at`, oldest first. | | How long do PRs take to merge? | `pull-requests` | Pass `state=merged`. Report the median and p95 of `ready_to_merge_seconds`. | | Where is PR N stuck? | `pr-lifecycle` | Find the largest gap between consecutive events. | | What does a failing test cost? What should we quarantine? | `engineering-analytics-flaky-tests` | Rows arrive ranked by master failures, then by distinct PRs hit. | | Which team owns the flakiest tests? | `engineering-analytics-team-ci-health` | Each count has a `_prior` twin for the previous window of equal length. | | What did CI cost for one PR? | `engineering-analytics-pr-cost` | A null cost means nothing was billable. It never means zero. | | Which runner tier drives a workflow's cost? | `engineering-analytics-workflow-runner-costs` | Rows arrive with the highest spend first. | | Where did one run spend its time and money? | `engineering-analytics-workflow-jobs` | Pass `ci_engine` with `run_id`. |

A common sequence is `workflow-health` to find the slow workflow, `pull-requests` to list affected PRs, then `pr-lifecycle` on one of them.

Picking the repo

`engineering-analytics-sources` lists one entry per repository a connected GitHub source syncs. With one entry, skip it, because the other tools default to that repo. With more than one, pass the chosen entry's `id` as `source_id` and its `repo` as `repo`. Passing only `source_id` reads the source's default repo, not the one you picked.

What the numbers mean

`pull-requests`

• `open_to_merge_seconds` is `merged_at` minus `created_at`, so it includes draft time. Call it "open to merge", never "cycle time" or "review time".
• `ready_to_merge_seconds` is the cycle time. It runs from the last ready-for-review transition to the merge, or from `created_at` for a PR that was never a draft.
• A null `ready_to_merge_seconds` means the tool did not observe the transition. It never means zero. Aggregate over non-null rows and say how many rows that covers.
• Report the median and the p95 together. Never report a mean.
• `ci` counts the latest run per workflow on the PR's current head SHA. Runs from earlier pushes are not in it.
• A run's conclusion arrives by webhook and can lag. Report `ci.pending` as unsettled, not as a failure.
• Rows include bots and drafts. Exclude `author.is_bot` and `is_draft` for throughput and merge-time questions.
• A page holds up to 1000 ro