1.9 KiB
Findings
Date: YYYY-MM-DD
Path inspected: <path>
Summary
<path> is a .
The repo is trying to prove or build
.Verdict in one sentence: <works as X, does not yet read as Y>.
What It Contains
<path/to/file-or-dir>-<path/to/file-or-dir>-<path/to/file-or-dir>-<path/to/file-or-dir>-
Review
State the main architectural idea plainly.
Say what the repo gets right.
Say what still looks early, brittle, overcomplicated, missing, or high-risk.
Call out the main constraint directly: <build glue / unstable deps / missing tests / wrapper burden / runtime complexity / unclear ownership / etc.>
Keep this section short and judgmental in the useful sense. Write like a reviewer, not a tour guide.
Pros
Cons
Status
Current status: <working prototype / partial implementation / mature subsystem / etc.>
State what is already proven.
State what would still need work before repeated reuse or production use.
End with a short reviewer verdict: <promising experiment / solid foundation / not ready to trust / etc.>
Optional Sections
Add only if they help:
## Ecosystem Maturity## Calling Direction## Toolchain Recommendation## Practical Read On <Project>## Risks## Next Problems
Writing Rules
- Use Title Case for headings.
- Keep the tone direct and critical.
- Prefer short paragraphs over long walkthroughs.
- Do not write like an assistant explaining itself.
- Avoid filler such as "it appears" unless the point is genuinely uncertain.
- Prefer verdicts over summaries when the evidence is already clear.
- If something is fragile, say it is fragile.
- If something is promising but early, say that plainly.