diagnosing-ci-and-merge-bottlenecks

Call the workflow-health tool over two adjacent windows, such as the last 14 days versus the prior 14 days, and compare p50_seconds and p95_seconds per workflow. Report median and p95 separately since they move independently, and guard against null values when a window has no qualifying runs.

Query the pull-requests tool and keep rows where ci.failing or ci.pending is greater than zero. Treat pending counts as unsettled or potentially stale rather than settled failures, since the CI source syncs on a watermark.

Aggregate ready_to_merge_seconds over merged, non-bot, non-draft rows from pull-requests, using median and p95 rather than a mean. Fall back to open_to_merge_seconds only with a coarse label, since it fuses draft and review time.

No, it covers aggregate pipeline health only. For a verdict on one specific CI failure, such as whose fault it was or which commit broke it, use the investigating-ci-failures skill instead.

The flaky-tests queue only covers the main Backend pytest and Frontend Jest suites, and confirmed_flake status requires proof of nondeterminism via a same-commit recovery in the same matrix job. Counts are absolute signals, never rates, because passing runs are mostly not emitted.

The tool returns a capped page of 1000 rows, newest first, with a truncated flag when the cap is hit. Narrow the query with author, source_id, repo, or a shorter date_from window until the full result set fits.