Stewie Reflect reads a read-only snapshot of your GitHub repo and generates an Owner's Manual for the product inside it: what the code does, where the evidence ends, and which decisions only you can make. Every claim is tied back to the file or function that supports it, with plain-language diagrams so the manual is readable, not just technical. Pick a repo and branch to get a free preview — a full chapter plus a map — then unlock the full manual and Markdown export for a $19 beta price.
What's great
Stewie Reflect writes the manual your code would write. Every codebase has two descriptions: what was intended and what is actually there. Documentation written by humans describes the first and drifts further from the truth with every commit. Reflect generates the second, and because it is built on PBC Spec, the result is audited against the code rather than someone's memory of it.
Two things surprised me. First, the output is genuinely visually appealing, which matters more for a manual than people admit, because a manual nobody wants to open is a manual nobody reads. Second, Reflect delivers a template rather than a finished artifact. The final product is still yours, but you start from an accurate roadmap of what your codebase really is instead of a blank page.
For a beta release it is remarkably polished and was immediately useful. Here is a real manual it produced for one of my own systems:
https://bulkheadtau.com/bulkhead-tau/reflect/operator-control-plane.html
What needs improvement
The initial manual has a mechanical feel to the language. It's pretty easy to smooth out as you are making your revisions, but this could possibly be streamlined in the future.
vs Alternatives
I didn't choose Reflect over alternatives. I chose it because it provided functionality available nowhere else.
PBC Spec filled a real need for me. It gives my system an upper boundary, a spec that is bound to the code instead of floating beside it. Without that, you are really developing 2 systems, the software and a separate description of the software, and keeping them in sync by hand. That's just too much for me, at least.
Stewie Reflect leverages PBC Spec in a way nobody else is positioned to match, since the open-source repo at the core of the product is the company's own.
EDIT: I forgot to mention the first time around that LangChain entered this space about two weeks ago with an open-source repo called OpenWiki — an exciting move from an open-source powerhouse. It has a similar purpose: build the manual from what the code is, rather than from what's wanted from the code. I'm excited about this one too, since it can fill gaps Reflect doesn't cover: namely, simpler repos with less surface area to analyze.
I've since made several PRs against OpenWiki. Where did the ideas come from? From Stewie Reflect's own manual of OpenWiki. That's the power of this approach: it compounds.
Ratings
Ease of use
Reliability
Value for money
Customization
Report
12 views
Thank you for the thoughtful review, Erik — really appreciate you testing Reflect deeply and sharing such specific feedback.
Report
oh this is a good one. half the designers using Maker end up with working code they couldn't really explain out loud, so this anxiety is dead on. does it document what's already there or does it want to ride along from the start?
@sunnyjoshi Thanks! That was exactly the problem I built it for.
Right now it documents what’s already there. You point it at a repo snapshot, it reconstructs what the product actually does from the code and generates an evidence-backed owner’s manual.
Having it ride along during development is something I’m actively thinking about, but I wanted to solve the “I already shipped this—now help me understand it” problem first.
Curious how it handles monorepos with multiple services, does it try to summarize everything together or let me pick which subfolder gets its own manual?
@agaoglumet30725 Good question. Today Reflect lets you pick the repo and branch, and you can also narrow the run to a subfolder before generating the manual.
So for monorepos, you don’t have to summarize the whole thing as one giant product. You can point it at a specific app, service, or package and get a manual for that slice.
It still keeps the repo boundary honest: if that service depends on shared packages or config visible in the repo, the manual can reference that evidence, but it won’t pretend to fully understand unrelated services outside the selected scope.
Longer term, I’d like monorepos to support linked manuals — one per service plus a system-level map — but scoped manuals first is the safer path.
how does it handle monorepos with multiple services sharing one repo, does the manual get split per package or stay as one big doc
@hmeyrahasm8vrn Today it depends on the scope you choose.
For a monorepo, you can narrow the run to a specific subfolder, package, or service, so the manual is generated for that slice instead of forcing everything into one huge doc.
If you run it against the whole repo, Reflect will try to describe the repo as one system. But for real monorepos, I usually recommend scoped manuals first: one manual per service/package, with shared packages or config called out when they show up as evidence.
Longer term, I’d like to support linked monorepo manuals: service-level manuals plus a higher-level system map.
the traceability thing is really well done, every claim links straight back to the file it came from so you can actually trust what the manual is telling you instead of taking it on faith.
@kayratanmaipup Thanks Kayra — that’s exactly the part I care about most.
A repo summary is only useful up to the point where you have to trust it blindly. I wanted every important claim to have an evidence trail back to the code, so the owner can verify what’s true instead of just accepting a confident explanation.
If you'd like to see what the output actually looks like before trying it, here's a public sample manual generated from a real AI bookkeeping app:
https://reflect.stewie.sh/#/manual
No signup required.