Mark the unstated purpose as still needed
The source only says “helps teams organise documents”. That stays, with an explicit note that target users and typical scenarios must still be supplied.
Turn project notes, feature lists, and scattered explanations into a README: purpose, installation, usage, limits, and contributing. No invented capabilities, dependencies, commands, licences, performance figures, or compatibility claims; gaps become placeholders listed for verification.
We write purpose and limits first, then installation and usage, leave placeholders for what is missing, and list every fact you need to confirm.
SAMPLE OUTPUT
This is the complete output for the source text in the demo above: a completeness score, itemised revision notes, what became a placeholder or an item to verify and why, and the drafted README. It is a demonstration, not a customer case.
The source only says “helps teams organise documents”. That stays, with an explicit note that target users and typical scenarios must still be supplied.
“Install the dependencies and it runs” is not an installation section. It becomes a placeholder listing the package manager, commands, and environment requirements still missing.
“All kinds of formats” and “fast” have no list and no measurements. They move into the supported scope and performance sections as items to verify.
# Project name [to be filled] ## What this is A tool that helps teams organise documents. The specific problem it solves and its audience are still to be supplied. TODO: the source does not name the target users or typical use cases ## Installation [to be filled: installation steps] TODO: the source only says “install the dependencies and it runs”; no package manager, command, or environment requirement is given ## Usage [to be filled: basic usage example] TODO: no command, configuration, or call example in the source ## Supported scope To verify: the source says “all kinds of formats” without listing them ## Limits - To be supplied: capabilities not currently supported and known constraints ## Performance To verify: the source says “fast” with no measurements ## Licence Unspecified: the source does not mention a licence; the maintainer must decide ## Contributing Pull requests are welcome. TODO: add the contribution process, code style, and review requirements
WHAT DRAFTING DOES
The first screen answers “what is this and who is it for”. Readers will not dig to paragraph three to find the purpose.
A plausible command that fails is worse than a visible gap that says it needs filling.
Writing down what is unsupported or unfinished makes a project easier to trust and to adopt.
WHY IT IS WORTH DOING
If the first step fails, most people do not try twice and do not tell you what went wrong.
Users go looking for a capability you wrote down; when it is missing they file it as a bug.
The licence decides whether others may use the code at all. When it is unknown, say unspecified and let the maintainer choose.
Note: common practice for READMEs is to lead with purpose and audience, follow with installation and usage, and close with limits and how to contribute. Communities differ on section order and depth. This site drafts documents only; it reads no repository code and offers no legal opinion or compatibility guarantee.
DRAFTING DEMO
We built a project that helps teams organise documents. It is very easy to use and fast, and supports all kinds of formats. Install the dependencies and it runs, how exactly depends. Anyone interested can join in, PRs are welcome.
# Project name [to be filled] ## What this is A tool that helps teams organise documents. The specific problem it solves and its audience are still to be supplied. TODO: the source does not name the target users or typical use cases ## Installation [to be filled: installation steps] TODO: the source only says “install the dependencies and it runs”; no package manager, command, or environment requirement is given ## Usage [to be filled: basic usage example] TODO: no command, configuration, or call example in the source ## Supported scope To verify: the source says “all kinds of formats” without listing them ## Limits - To be supplied: capabilities not currently supported and known constraints ## Performance To verify: the source says “fast” with no measurements ## Licence Unspecified: the source does not mention a licence; the maintainer must decide ## Contributing Pull requests are welcome. TODO: add the contribution process, code style, and review requirements
Demo sample: “all kinds of formats” and “fast” become items to verify, missing install and usage steps stay as placeholders instead of invented commands, and the licence reads as unspecified. Paste your project info to get your version (sign-in required; one credit per run).
WHY YOU CAN TRUST IT
Capabilities, dependencies, and commands absent from your notes become placeholders rather than filler that makes the document look finished.
When no licence is mentioned, it reads as unspecified and goes on the verification list. Only the maintainer can decide it.
Speed claims, compatibility statements, and support promises without measurements are withheld and listed as things to confirm.
Submitted text is used for this single AI request and is not intentionally persisted. See the Privacy Policy.
FAQ
No. Install commands, dependencies, and environment requirements become placeholders and go on the verification list. A command that fails is more harmful than a gap that says so.
It reads as unspecified and is listed for verification. The licence decides whether others can use the code, so only the maintainer can choose it.
They are kept out of the body text. Each becomes an item to verify, noting that a format list or measurements are needed before it can go into a README.
One credit per run, usually done in seconds, returning the README, revision notes, and items to verify.
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.
A first README for a new project, notes prepared before open-sourcing an internal tool, a repository with only a feature list, a verbal project introduction — any project information that needs to become a real README.
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.