Productizer vs Lightsprint

The cleanest way to read this page: Productizer decides what should be true before the work; Lightsprint scores what actually happened around a pull request. One holds a standing agreement with permanent ids that predates the change and outlives it; the other reads CI runs, reviews, deployments and bot comments off GitHub and turns them into a readiness verdict. They sit at different layers, and on the row that matters most to a reviewer — what the gate is anchored to — Lightsprint still wins. Their readiness verdict is computed from observed GitHub evidence and their approval workflow is the thing that blocks. Productizer’s blocking gate is still the Check stage and the PreToolUse hooks, and both are anchored to declarations: a committed checks.yaml and the spec. v4.2.0 added an evidence layer beside it — scripts/signals.sh does read pull-request, review, comment and CI-check records off GitHub through gh — but the skill’s own reference file states the limit plainly: “It is not a gate.” Nothing blocks on that score, and it runs when you run it. Where the two converge is more interesting than where they differ: both refuse to render an unmeasured value as zero, arrived at independently, and that is still the honest headline of this comparison.

The convergence worth reading first

Two independent designs reached the same principle about missing data, and that is the most interesting thing on this page. Productizer holds it as a discipline — a value that could not be measured is never rendered as zero, and the contradiction checker’s passing verdict is worded as a non-decision rather than a clearance. Lightsprint encodes it in the wire format: when there is nothing to judge, the readiness score is null, not 0, and the payload says “No signals found. Link a PR and wait for CI/reviews first.” Theirs was the stronger implementation of the two, because a type-level null cannot be quietly averaged into a dashboard the way a convention can — and v4.2.0 closed that gap by taking the same route: in Productizer’s scoring path the number cannot be written at the top level at all, only nested beside the signals hash and the signal count, and the emitter refuses to write that object when the count is zero. Same refusal, arrived at from two directions, and now enforced by two wire formats rather than one plus a discipline. Neither team took the idea from the other. When two projects with nothing in common independently refuse to let absence masquerade as a measurement, the principle is probably right.

Where Lightsprint is genuinely ahead

Their gate is anchored to reality; ours is anchored to declarations. This is the row they win most clearly. review-hub signals pulls objective evidence from GitHub as typed records — a category of ci, review, deployment, bot_comment, human_comment or custom, a status of success, failure, pending, running, neutral or warning, plus diff stats — and review-hub scores runs judgment strictly on top of that, returning a readinessScore 0–100 with a label, section summaries, change callouts, suggested actions and which review comments were addressed. Their own invariant is the right one: “Check signals before checking scores — signals are what the AI readiness analysis is based on.” Productizer v4.2.0 now collects observed GitHub records too — signals.sh reads the pull request, its reviews, its comments and the CI check rollup through gh, and names the absence when there is no gh, no remote, no pull request or no CI — but the thing that blocks is unchanged. The Check stage and the deploy and publish hooks still read a committed checks.yaml and the spec, and the skill’s own reference file is blunt about the score: “It is not a gate.” Lightsprint’s evidence feeds the thing that stops the merge. Ours feeds a report you asked for.

Caching judgment against a hash of the signals was the best idea on this page, and Productizer took it. The Lightsprint server keys the analysis to the evidence it was computed from and re-runs when that evidence changes, so a verdict can never outlive the facts underneath it. That is a small mechanism with a large consequence, and it only shows up once you have decided the evidence layer is separate from the judgment layer in the first place. scripts/score.sh now does the same and states the rule as its reason for existing — a score cannot outlive the evidence it was computed from. One difference of temperament survives: theirs re-runs the analysis when the hash moves; ours refuses the stale cache and hands the decision back rather than quietly producing a fresh number. Credit where it is due — they had it first, and we are second here.

Their approval model binds people ours cannot reach. Roles are Builder — “Cannot approve or ship” — Approver and Admin, with approval rules configurable per role, and “Every change goes through the approval workflow your team configures. There is no bypass.” Their honest differentiator over plain GitHub review is that “the gate exists regardless of whether they know what a PR is”: it binds a non-engineer dispatching an agent from a web workspace. Productizer’s PreToolUse hooks bind a developer at a terminal, which is the easier case by some distance.

They measured their own agent friction and published the number. An audit of “~550 CLI invocations across ~80 Claude Code sessions… Overall error rate: ~8%”, with each failure catalogued by instance count, severity and whether the agent self-recovered — and their biggest finding was that their own help text lied about positional arguments. That is an uncomfortable thing to publish about your own tool, and it is exactly the kind of measurement Productizer has no equivalent of. Add a real team surface: a shared workspace where PMs, designers and engineers align on one visual plan before parallel sandboxed agents are dispatched. Productizer has nothing multiplayer at all.

The blocking gate they shipped and then deleted

This is relevant because Productizer’s gates are the same shape. Lightsprint’s git history shows a PermissionRequest hook on ExitPlanMode with a "timeout": 345600 — four days — that uploaded the plan, opened a browser and blocked the agent until a human ruled. It was removed in commit 0a5bcec on 13 July 2026, “Remove plan-mode (ExitPlanMode) review flow”, 21 files changed, 26 insertions, 1776 deletions. The commit gives no reason, so why they removed it is not stated — it is not evidence that the mechanism failed, and this page does not claim it was. It is reported because a four-day human block on an agent is precisely the mechanism Productizer relies on for deploy and publish, and anyone evaluating that design should know it was built, shipped and then taken out by a team that had it running.

One design difference is worth stating neutrally, without gloating. The deleted hook’s own header read “Error handling: ANY failure outputs allow decision and exits 0” — it failed open, so a broken gate let work through. Productizer’s hollow-check rule fails closed: a check that exits clean having examined less than it declared blocks. Both are defensible choices with different costs — failing open protects velocity, failing closed protects the invariant — and Productizer is not borrowing this one.

Where Productizer differs structurally

A standing agreement, not a per-change verdict. Productizer keeps one living spec per product with permanent requirement ids that are never reused or renumbered, a constitution of P-numbered principles above them, supersession that preserves the original text, and a classification of every new intent against the entire spec before anything is built — where a contradiction halts the work until a human rules. Lightsprint’s manifesto talks about spec-driven delivery, but the published method has no file format, no numbering and no conflict handling. A readiness score on a pull request is an excellent answer to “is this change ready?” and cannot answer “does this change contradict something we decided four months ago?”, because there is no standing decision to compare against.

Nothing hosted, nothing closed, nothing to buy. Productizer runs locally in your repository with no account, no server, no control plane and no telemetry, and the entire method is readable in the open repository. Lightsprint’s public plugin is where their best engineering is visible, but the main repo SprintsAI/lightsprint is private, and the workspace is hosted. That is a normal shape for a funded company and is stated as fact, not as an accusation.

Where Productizer is weak — plainly

The only accuracy figure we have covers the symbolic cross-check that runs alongside the model classifier: 1.00 precision and 0.70 recall on a corpus of 21 cases we wrote ourselves — 7 true positives, 3 false negatives, 0 false positives, 10 true negatives and 1 undecided, with all three misses semantic. A harder 26-case corpus scores the same checker at 0.67 precision and 0.12 recall, so the figure tracks the corpus more than the checker. That sample is small and self-authored, and the end-to-end system’s recall is unmeasured. Productizer is Claude Code only. Its lifecycle has not yet been exercised end to end through CI, where Lightsprint’s agents open real pull requests today. Its eval corpus has never been graded — 26 cases load and both ablation arms configure, but claude plugin eval is early-access gated and no case has been scored by a model. And while v4.2.0 shipped three measurement instruments, no result from any of them has been published, so there is still no measurement of whether the process makes anything faster or better — and the repository’s own measurement notes say plainly that none of the three closes the recall question either. On the marketing side, Lightsprint’s site is thin — a manifesto with no file format, an unsourced “2–4 weeks becomes 2–4 hours” claim and a skills page still carrying placeholder copy — but that is worth noting only alongside the fact that Productizer publishes no efficacy numbers either. Neither side has earned a velocity claim.

The verdict — different layers, same principle. Choose Lightsprint if the gap you feel is that your coding agents run solo while the team falls out of sync: you want PMs and designers dispatching agents behind a role-scoped approval workflow with no bypass, parallel sandboxed agents opening real pull requests, and a readiness verdict computed from CI runs, reviews, deployments and bot comments actually observed on GitHub, cached against a hash of that evidence. Choose Productizer if what you are missing is a standing agreement — permanent requirement ids, a constitution above them, supersession that keeps the original text, and a classifier that stops the work when today’s intent contradicts a decision already taken — held locally in your own repository with nothing hosted and nothing closed. One decides what should be true before the work; the other scores what actually happened around the pull request. Neither rules out the other, and both refuse to call an unmeasured thing zero.

Lightsprint capabilities are read from lightsprint.ai and Lightsprint’s public plugin repository and its git history as of 2026; quoted phrases are theirs, reproduced verbatim. The commit details — 0a5bcec, 13 July 2026, 21 files changed, 26 insertions, 1776 deletions — are reported as facts from that history, and the commit states no reason for the removal; nothing here should be read as a claim that the mechanism failed. Lightsprint’s velocity figures are unsourced marketing claims and are not treated as evidence on this page — Productizer publishes no efficacy numbers either. Readiness-score quality has no published eval or calibration data, and Productizer’s end-to-end contradiction detection is equally unmeasured; that row is a draw. Productizer marks reflect shipped capability in github.com/gitayg/productizer; the 0.70 recall figure covers only the symbolic cross-check, on a 21-case corpus we authored. A harder 26-case corpus scores the same checker at 0.67 precision and 0.12 recall, so the figure tracks the corpus more than the checker. The unrelated lightsprint.com is a different product entirely and is not the subject of this page. Lightsprint is a trademark of its owner; this is an independent architecture-level comparison, and nothing here states or implies that Lightsprint endorses, partners with, or is affiliated with Productizer or glick.run. Both products evolve — verify specifics against current documentation.