Your team's GitHub, answered in plain words

Connect GitHub read-only and ask what you would otherwise piece together from pull request lists: who shipped what last month, where reviews stall, how much of the work is fixes, and how much of it AI wrote. Answers land in your spreadsheet, your investor deck or Slack, and refresh every night.

Most founders know how the team is doing from standups and a feeling. The numbers exist, spread across hundreds of pull requests, reviews and commits, but turning them into "fix work doubled after the October release" or "reviews are waiting two days" means an afternoon in GitHub and a spreadsheet. Quiriz reads your repositories every night, labels each change, and answers the question in the place you need it.

How it works

1. Install the Quiriz GitHub App. Pick all repositories or only some. Access is read-only, and you can change the selection or uninstall in GitHub at any time.
2. Quiriz reads the last 13 months of pull requests, reviews and main-branch commits, then refreshes every night.
3. Ask in plain words, in the Quiriz app or from Excel, Google Sheets, PowerPoint, Google Slides, Word, Google Docs or Slack.

What Quiriz knows about each change

• Who and when. Author, the person who merged it, reviews and their timing, time to first review, time to merge.
• What kind of work. Feature, fix, refactor, tests, docs, dependencies or chore, taken from your labels and "feat:" or "fix:" title prefixes, and read from the title and file paths when there are neither.
• Which part of the code. Frontend, backend, infrastructure, tests or docs, from the folders a change touched, plus the top-level folder itself so you can group by your own layout.
• How big. Lines changed, with lockfiles and generated files left out so a dependency bump does not look like a week of work.
• Whether AI made it. AI agent, AI-assisted, or no AI marker, from agent accounts and the co-author lines tools such as Claude Code, Codex, Cursor and Aider write into commits.
• Whether it was reviewed. Commits pushed straight to the main branch are counted on their own, and pull requests that only promote one long-lived branch into another are kept out of the measures.

Real questions founders ask, and where the answer goes

The monthly investor or board update

"Pull requests merged by month this year, split into features and fixes." Put it on the engineering slide of the PowerPoint or Google Slides update as a chart. Next month, one click refreshes it instead of rebuilding it, and the slide shows the same definition every time, so a jump is a real jump.

Finding where work waits

"Who waited longest for a first review last month?" and "Average hours from opening a pull request to merging it, by developer, this quarter." When a feature slips, the cause is often a pull request that sat for three days, not slow coding. Seeing the waiting time per person shows whether you need a review rotation, smaller pull requests, or a second reviewer on one area of the code.

Is the team building or firefighting?

"Share of merged pull requests that were fixes, by month." A rising fix share after a release is an early warning that quality slipped or the release went out too fast. Pair it with "Which pull requests were sent back for changes or reverted, by developer?" to see whether rework is concentrated in one area of the code or spread evenly.

AI adoption, measured instead of guessed

"What share of each developer's pull requests were AI-assisted last month?" If you pay for Copilot, Claude Code or Cursor seats, this shows who uses them on real work and how the share changes month to month. Put it next to time to merge and rework rate to see what changed when AI use went up. The share counts only AI that marks its work, so read it as a minimum.

Work that skipped review

"How many commits went straight to main without a pull request, by developer, this month?" Useful when you are tightening process before a security review or a customer's due diligence, and for checking that a new branch rule is being followed.

The same data answers "Which areas of the code changed most this quarter, and who changed them?" before a planning meeting, "Rank developers by reviews given last quarter" for one-to-ones (one measure at a time, no single score), and "Features shipped per month" beside Stripe revenue or PostHog sign-ups, which connect the same way.

The engineering slide, the weekly sheet, the Slack check

Engineering reporting at a small company is usually three things: one or two slides in the monthly investor or board update, a sheet the engineering lead checks each week, and questions that come up in the team channel. Each one starts with an afternoon in GitHub. With GitHub connected, each one is a question that refreshes every night.

• The weekly sheet, in Excel or Google Sheets. =QUIRIZ.ASK("pull requests merged and average hours to merge by developer last week", "table") spills one row per developer, bots left out, and answers against the nightly refresh each time the sheet recalculates.
• The investor update, in PowerPoint or Google Slides. Build the engineering slides from a description, then refresh them next month instead of rebuilding them, with the same definition every time so a jump is a real jump. Two prompts are below.
• The written update, in Word or Google Docs. In Word, "merged 42 pull requests, a third of them fixes" can be a sentence whose figures stay live on refresh. In Docs, type the question where the chart belongs and press Chart.
• The team channel, in Slack. "Who is waiting longest for a review right now?" answered in a thread, as of last night's refresh. Slack is included from the Plus plan.

Make a deck: two prompts to try

Quiriz plans the slides first, so any title or question can be edited before it builds. In PowerPoint each chart and table carries two to four takeaways written from that slide's own figures; Slides closes with an executive summary.

What it is for, and what it is not

These are activity measures. They show where work goes, where it waits and how it changes over time; they do not judge whether the code is good, and a ranking on its own is a starting point for a conversation, not a performance review. Data refreshes nightly and covers the last 13 months. The AI-assisted share counts only AI that marks its work. Bots and outside contributors stay in the data with a label but are left out of the measures. Quiriz reads GitHub.com repositories; GitHub Enterprise Server, GitLab and Bitbucket are not supported yet.

What stays private

Quiriz never stores your code, diffs, pull request descriptions, commit messages or email addresses, and never changes anything in GitHub. To label the kind of work, it sends its AI provider pull request titles, the first line of commits pushed straight to the main branch, and file paths, and nothing else. Your data is never used to train AI models. Uninstall the app in GitHub or disconnect in Quiriz to stop access at any time. Privacy policy →

Pricing

Connectors, including GitHub, are included on paid plans, along with scheduled refresh and scheduled reports. See pricing →