Add requirements and a quick start
The source jumped straight to install and usage with no environment stated. A requirements section is added and the example becomes a copyable quick-start block.
Version numbers, commands, and parameters are left untouched. We review structure, example consistency, and prerequisites, then return an actionable fix list and a revised draft — with interface details we cannot confirm marked for you.
We check structure, whether examples match the documented signatures, and whether prerequisites are stated, then list what needs confirming.
SAMPLE OUTPUT
This is the complete output for the source text in the demo above: a structure score, itemised fixes, interface details to confirm, and the revised documentation. It is a demonstration, not a customer case.
The source jumped straight to install and usage with no environment stated. A requirements section is added and the example becomes a copyable quick-start block.
The example passes `fuzzy`, which appears nowhere else in the document. It is marked TODO so you can document the option or remove it from the example.
The source documented neither common errors nor usage ceilings. Both sections are added, with the actual error type and result cap left as TODO.
# sdk
A Node.js SDK for the search API.
## Requirements
Node.js 18 or newer. TODO: confirm the minimum supported version.
## Install
```bash
npm install our-sdk
```
## Quick start
```js
import { Client } from "our-sdk";
const client = new Client({ key: process.env.SDK_KEY });
const result = await client.search({ q: "hello", limit: 10 });
```
TODO: the `fuzzy` option appears in the example but is documented nowhere in this file — confirm its values and default, then document it or remove it.
## Failure modes
- Constructing a Client without a key throws. TODO: confirm the actual error type.
## Limits
A single search returns at most TODO results.WHAT THE REVIEW DOES
Whether someone keeps using a library is usually decided in the first ten minutes. The minimal working example and install command have to be unambiguous.
An example using a parameter documented nowhere else is the most common and most damaging documentation bug.
What environment is needed, what is unsupported, and which error a reader hits first — if it is not written, they find out the hard way.
WHY IT IS WORTH DOING
Most developers drop a library because the first ten minutes failed, not because it lacked features.
Code ships, docs do not, and the example still passes a parameter that no longer exists. Only a line-by-line comparison catches it.
If unsupported cases are not documented, users hit them in production and write the review.
Note: there is no universal scoring standard for documentation quality. This site applies common practice: can a reader get started quickly, do examples match signatures, are prerequisites and failure modes stated. It is not a review of code correctness or API design.
REWRITE DEMO
# sdk A simple SDK for calling our API. ## Install npm install our-sdk ## Usage const client = new Client({ key: 'xxx' }) const result = await client.search({ q: 'hello', limit: 10, fuzzy: true }) See the docs site for more.
# sdk
A Node.js SDK for the search API.
## Requirements
Node.js 18 or newer. TODO: confirm the minimum supported version.
## Install
```bash
npm install our-sdk
```
## Quick start
```js
import { Client } from "our-sdk";
const client = new Client({ key: process.env.SDK_KEY });
const result = await client.search({ q: "hello", limit: 10 });
```
TODO: the `fuzzy` option appears in the example but is documented nowhere in this file — confirm its values and default, then document it or remove it.
## Failure modes
- Constructing a Client without a key throws. TODO: confirm the actual error type.
## Limits
A single search returns at most TODO results.Demo sample: requirements and a quick start are added, the example becomes a copyable code block, and the undocumented fuzzy option is flagged. Paste your documentation to get your version (sign-in required; one credit per run).
WHY YOU CAN TRUST IT
Node versions, dependency names, install commands, and parameter names stay verbatim. Anything uncertain becomes TODO rather than a guess.
Snippets are neither compiled nor executed. Whether the code actually runs remains your responsibility.
When an example uses an undocumented parameter, we surface it so you decide whether to document it or drop it.
Submitted text is used for this single AI request and is not intentionally persisted. See the Privacy Policy.
FAQ
No. Version numbers, dependency names, commands, parameter names, and code identifiers are kept verbatim. Uncertain items become TODO.
No. We neither compile nor execute snippets. We check documentation structure and whether examples match the documented signatures.
No. Output is a Markdown revision you decide how to merge into the repository.
One credit per run, usually done in seconds, returning the revision, the fix list, and items to confirm.
No. Credits never expire — whatever you do not use carries over to the next cycle instead of resetting.
Not yet. Each run processes one document and consumes one credit; there is no bulk upload or API today. Email us with your use case and we will assess it.
Not intentionally. Text is used for this single AI request only. See the Privacy Policy.
READMEs, quick starts, API references, SDK guides, internal tool docs — anything a reader should get working on the first attempt.
SIMPLE PRICING
For an occasional publishing cadence, with a focused monthly credit allocation.
For frequent publishers who iterate on content continuously.
Our largest monthly credit allocation, for the heaviest continuous usage.
Credits never expire: unused credits carry over instead of resetting. Credits apply to this site only and are not shared with other sites.
Prices shown are USD baselines; final currency, taxes, and discounts are determined by Paddle for the checkout location.