StackVitals

Before opening a pull request: what merged PRs touching these files usually include (tests, changelog, docs, size), what this change is missing, and what maintainers most often ask for in review there. repo: owner/name; paths: files the change touches; lines: lines added plus removed.

Before working in an unfamiliar repo: how changes get merged there, measured from its history (things its files don't say). Per folder: what merged PRs include, who reviews there and how fast, CODEOWNERS; CI jobs and tests known to be flaky (re-run before chasing a failure); how outside PRs fare against similar repos. Every number comes with its count. repo: owner/name.

Before adding or upgrading a dependency: how upgrades of this npm or PyPI package went across thousands of public repos, whether its maintainers still merge outside fixes, its source repo, advisories and malware records, and a verdict (use / monitor / investigate, or none when evidence is thin) with the counts behind it. name: "requests" or "pypi:requests"; ecosystem: "npm" or "pypi" (optional).

Every package a lockfile pins, the ones that need a look first, each with its verdict and main reason. Reads package-lock.json, npm-shrinkwrap.json, requirements*.txt, uv.lock, poetry.lock and Pipfile.lock. path: the lockfile on this machine.

Up to 3 people who should review an open pull request: who wrote and reviewed the same areas, code owners, how many reviews each already has open and how fast they usually answer. repo: owner/name; pr: its number.

Open pull requests and who has to act next on each (reviewers, the author or maintainers), since when, and whether that is longer than usual for this repo. repo: owner/name.

A repo's CI health: flaky jobs and tests (failed, then passed with no code change), jobs that keep failing, jobs that got slower, line coverage with each pull request's patch coverage when CI uploads a coverage report, pushes green on the first try with their likely ranges, and this week against the four before (only changes beyond noise are flagged; steady ones say how big a change they could have shown). repo: owner/name.

Before fixing a failing test or job, check whether it is a known flake in this repo. name: part of the test or job name (e.g. "test_upload" or "e2e").

Explain a failed CI run: each failure is called known flaky (it flaked before and its log shows a flake's sign: check the error, then re-run it), maybe yours (it flaked before, but its error names a file the pull request changed), flaked before (it has flaked, but rarely, in another step or with no flake's sign: check the change first), already failing on the default branch (the same error), outside failure (a registry, network or runner), maybe flaky (it failed the way flaky checks do: re-run once to tell), PR details (a check on the PR's title, description or labels: fix the PR, not the code), or new (likely from the change). run: the run's URL.

What to fix first, across modules, and the findings that join CI and pull requests. findings: each a sentence with its number, n, evidence links and the action, ranked by hours of waiting or outage at stake (flaky jobs and tests by the PR-hours they cost, reviews asked for and not started, incidents after deployments, dependency updates with failing checks, the outside-contributor review gap). red_ci: how long merged PRs sat ready for review with a failing check on their newest commit, each wait traced to the run that started it and what ended it, with counts and ranges. repo: owner/name; days: history to read (max 90).

A repo's delivery: DORA's keys with DevLake's counting and tiers (deployment frequency, lead time for changes, change failure rate, recovery) plus deployment rework rate, where deployments came from, cycle time P50/P75, sizes, stuck PRs, coding agents' PRs and people's AI-marked PRs each compared like with like (the same author's other PRs, or people's PRs of the same month and size) on reverts, CI failures, failed deploys and merges, with ranges, matched shares and the gap each could detect, merge-queue health, where the work went by month (feature, fix, maintenance, security, docs, with how each PR was sorted), and with Jira or Linear connected, issue lead and cycle time by type and the last sprints. Each DORA key carries its likely range and, when the range crosses a tier line, both tiers; `this_week` checks the latest week against the four before and flags only changes beyond noise.