Documentation
README
Review a design — is it sound, not just complete
The platform /open-knowledge skill still governs every markdown operation here (reads via exec, writes via write/edit, links as plain relative markdown, MCP owns in-scope .md); this skill layers design-review craft on top of it.
Three reviews are not the same review, and only one is this skill's job.
- Completeness review asks: is every section filled in? (Are Drawbacks and Alternatives non-empty?)
- Correctness review asks: are the individual claims true? (Does the benchmark really say 40ms? Is that API deprecated?)
- Soundness review asks: should this be built at all, and is this the design that follows from the stated goals and constraints?
This is the opening of the README. Read the full README on GitHub.