Understand a project’s direction from the work behind it
PRA reads a project’s public GitHub history for a calendar month
and writes a readable engineering review: what changed, what those
changes mean for the project and its users, and what remains unfinished or
unverified. Every finding carries the pull requests and commits
it rests on.
The scope is deterministic: one calendar month, and
every change that landed inside that window, whether it arrived through a
pull request or was pushed straight to the branch. What a report covers follows from the rule, not from what a model
happened to notice — which is the part a general-purpose agent gets wrong
without saying so.
Written for anyone who needs to know what an engineering team actually
shipped: investors and operators following a company, the team itself, or
the developer who has to write the monthly update and would rather not
reconstruct the month out of the commit log — a draft with every change
already accounted for and linked is faster to correct than a blank page.
PRA currently focuses on open-source projects. In the case of a private
repository, the scope of access, confidentiality, and data processing
procedures are agreed upon with each company before any materials from that
repository are read. Each report adds context between founder updates
without asking anyone to prepare another document, and is reviewed by a
person before being sent by email.
scope: one repo, one monthwindow: fixed rule, no samplingsource: public GitHubreview: humandelivery: email
[ 01 / what PRA does ]
pra.readmeproject-level context
Understand the change, not just the activity.
A new capability, a fix to an existing feature and the removal of
unused code tell different stories. PRA connects related changes
and explains what was there before, what is different now, and
which conclusions the evidence supports.
The report brings the main developments into focus. The companion
technical review documents the implementation, available tests and
coverage, with unfinished work kept separate. You can read for
context or follow an individual finding back to its sources.
Nothing is left out quietly. Every change that entered the branch
during the month appears somewhere — in a theme, or in a line of its
own — so the report being short is a choice about what matters, not a
consequence of what fit in one pass.
How the project started
PRA began as an experiment in reporting on a public open-source project.
The original task was to make a busy stream of engineering work readable.
That led to a broader question: how can the same evidence help people
follow a project's direction over time?
[ 02 / a real report ]
A shortened version of the review for
typesense/typesense, the
open-source search engine. Follow a finding to the pull request or commit
behind it, or open the technical review for implementation details, tests
and work still on a branch. October is the primary report; September
remains available and is linked wherever earlier work continues.
Open-source search engine, C++ · v31 branch · 1–31 October 2026 (UTC)
The month went into keeping a node up under concurrent load and into
access control. Four ways to stall or crash a server were closed, API
keys gained a policy for the collections they join, and three September
branches reached v31.
01 / An API key now says what it may read through a join
A key can carry a joins object naming each collection it
may read through a reference, with the allowed and denied fields for
each. Until this change a key described the collections it could act
on and nothing about joins, so a key restricted to one collection
could read any field of any collection that one referenced.
A turnstile makes searches that arrive after a pending write queue
behind it for a bounded share of the time, tuned by the new
write-priority-max-percentage setting. Before it, a
collection’s lock admitted readers while a writer waited, so a
steady stream of searches could keep a write out indefinitely.
Sources: direct commits
5def5b4 ·
f15f778
— no pull request, and no public review
03 / A crash no longer leaves a process answering health checks
A background task read request state the search threads were free to
change, so under enough load it crashed — and the crash handler then
waited on a lock the dead task still held. Every search blocked, the
replication loop stalled, and /health went on answering
ok. The task now builds its log line on the request’s own thread,
and an alarm ends a crash handler that hangs anyway.
Selected findings from seven October themes.
The technical review accounts for all 87 commits that entered
v31 that month — 20 integrating a pull request, 67 pushed
directly. Work still on a branch is listed separately. Tests were read
in the diffs, not run.
Independent demo based on public GitHub data. PRA is not affiliated with or endorsed by Typesense, Inc.
[ 03 / how a report takes shape ]
PRA reads a repository the way a reviewer would — the metadata around a
change, the diff underneath it, and the history that shows where it landed.
That gives every report a basis in the work itself, not in the titles
written about it. Losing nothing on the way is the part we deliberately
went to trouble over: the month is split up, read in pieces and checked
back against the branch history.
PRA generates the report from the collected evidence, connecting related
changes and explaining their context. Each report then goes through a
human quality review for accuracy, coverage and clarity before delivery.
report.pipelinecurrent workflow
Public history
Gather the available GitHub data in depth —
pull requests, commits, diffs and repository history — while keeping
unfinished work separate.
input / GitHub
AI-generated report
PRA’s AI pipeline connects related
changes and writes a clear, readable report with links to sources.
automated / PRA
Human review
Check the generated report
for accuracy, coverage and clarity before delivery.
quality check / human
Email delivery
A concise report, with a technical review
for the details.
output / report
Ask a general-purpose agent the same question and it answers from what
fits in one pass: the loudest pull requests, the titles, whatever the
search returned. What it dropped is invisible, because the answer reads
the same either way. PRA breaks the period into parts, groups related
work, and checks coverage against the branch history, so a gap shows up
as a gap instead of as a confident summary.
Run the same month twice and the same changes are in scope both times.
Determinism here is about coverage, not prose: the wording is drafted by a
model and edited by a person, but which work a report has to account for
is fixed before anything is written. That is what makes two months of the
same project, or two projects in the same month, comparable.
[ 04 / where we want to take it ]
The goal is to build a reliable history of how a project evolves. Each
report should show what changed since the previous period, which
developments continued, and whether new evidence supports or overturns
earlier conclusions.
nowin use
Reviewed reports by email
PRA collects and structures public GitHub data, then drafts a report.
Before delivery, a person checks the reporting period, coverage, facts
and wording against the sources. The final report and its technical
review are sent by email.
When earlier reports exist, PRA uses them as context to show which
developments continued, changed direction or stopped.
nextplanned
A continuous view across projects
Once the method has been validated across projects and reporting
periods, the remaining manual steps can be automated. Reports can then
live in one place, showing how each project changes over time and giving
a comparable view across a portfolio.
[ 05 / scope and limits ]
Evidence, not a company score
Public code shows engineering changes, not revenue, adoption or
private work. PRA complements founder updates. It does not replace
them or rank individual developers.
Clear boundaries around each finding
Reports distinguish between integrated work — merged or pushed
straight to the branch — released work, and work still unfinished.
They separate facts visible in the code from results reported by
contributors, including the conditions behind any measurements. Each
report also states its period and coverage.
[ 06 / start with one project ]
Would this help you follow a project?
Send one public repository and a line about what you want to
understand. We agree the month and the scope by email, then send the
report and its technical review as a sample. If it is useful, the same
report repeats every month.
The first report for a project is free while we are taking on the
first projects. After that, pricing is agreed per project and follows the
size of the month: a repository with a steady trickle of changes costs a
fraction of one that merges hundreds. We quote once we have seen the
history.