spec tracking

Know what's actually done before the demo.

Upload the spec for a feature or a client project. CodeReviewer breaks it into requirements, checks every pull request against them, and keeps a live scorecard with evidence for each one.

Start free trial Talk to sales

Billing revamp

spec/billing.md · 9 requirements

7/9

✓Invoices download as CSV PR #412
✓Refunds show on statements PR #418
✓Tax lines per country PR #421
•Bulk export for accountants half-done
•Yearly plan proration forgotten

Must · should · maypriority kept from your spec

Per requirementevidence linked to real pull requests

the problem

“Are we done?” shouldn't need a meeting.

Specs live in one place and code in another, so progress is whatever someone remembers in stand-up.

The missing requirement is usually discovered in the demo, or by the client.

Status reports take hours to assemble and are out of date the moment they're sent.

how it works

From trigger to result.

Upload the spec

Drop in a Markdown document. A feature brief, a statement of work, a PRD.

Requirements are extracted

The spec is split into individual requirements, each marked must, should or may.

Every PR is matched

As pull requests land, CodeReviewer links them to the requirements they satisfy.

The scorecard stays current

See what's shipped, half-done or untouched, with the evidence behind each status.

capabilities

What you get.

Requirement extraction

A Markdown spec becomes a checklist of must, should and may requirements.

Automatic PR matching

Pull requests are linked to the requirements they address, without anyone tagging tickets by hand.

Evidence per requirement

Each status points at the pull requests behind it, so "done" is something you can show.

Gap view

See at a glance what's missing or half-built, before it becomes a surprise.

Spec findings in review

When a pull request contradicts the spec (say, "exports must include refunds"), the review says so.

Spec-gated merging

Optionally require a pull request to match a requirement before it can merge on its own.

From document to scorecard

A spec is written for humans: paragraphs, bullet points, the odd table. CodeReviewer reads it the way a careful lead would, pulls out each requirement and keeps the priority the author gave it: must, should or may. What you get is a checklist of what your team agreed to build.

Evidence, not status updates

Traditional progress tracking depends on people moving cards. Spec tracking works from the code. When a pull request implements a requirement, the link comes from the change itself. So the scorecard is only as optimistic as the code allows, and you can click any “done” through to the work behind it.

faq

Questions, answered.

What format does the spec need to be in?

Markdown. Most feature briefs, PRDs and statements of work can be pasted into Markdown with little or no change.

Do we have to tag pull requests with requirement IDs?

No. CodeReviewer reads each pull request and matches it to the requirements it satisfies on its own.

Can we have more than one spec per project?

Yes. Track separate specs for separate features or releases within the same project, each with its own scorecard.

Is this useful for agencies?

Very. Spec tracking turns "is the statement of work delivered?" into a scorecard with evidence you can walk a client through.

What if the spec changes?

Upload the new version and pull requests are tracked against the updated plan.

Give every PR the review it deserves.

Start your 15-day free trial. We onboard a few teams every week.