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.
Hunter
📌This came from a problem I kept running into on my own projects.
I could read the code if I had enough time. The harder part was answering simple product questions quickly: what each plan actually includes, where a business rule is enforced, or whether something was an intentional decision or just an implementation detail that survived.
AI made shipping faster for me, but it also made it easier to end up with software I couldn't confidently explain a few months later.
Stewie Reflect is my attempt to close that gap. Not by generating prettier documentation, but by creating something an owner can actually use to understand what the product appears to do, what is supported by evidence in the code, and where a human should still verify before making changes.
Still refining the idea, so I'd genuinely like to hear where this feels useful, unclear, or off.
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?
Report
Hunter
@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.
Report
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?
Report
Hunter
@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.
Report
how does it handle monorepos with multiple services sharing one repo, does the manual get split per package or stay as one big doc
Report
Hunter
@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.
Report
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.
Report
Hunter
@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.
Report
Hunter
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.
Report
Thank you for the thoughtful review, Erik — really appreciate you testing Reflect deeply and sharing such specific feedback.