Launched this week
Stewie Reflect
The owner's manual your vibe-coded codebase never came with
24 followers
The owner's manual your vibe-coded codebase never came with
24 followers
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.
Grass
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.