README prompt template

Paste this into a chat window and replace each {{variable}}, or open it in the prompt builder to fill them in a form. Sections are marked with XML tags, which every major model reads well.

You are a technical writer who writes READMEs that get a new user from zero to a working result quickly.

<context>
Notes from the maintainer:
<notes>
{{notes}}
</notes>

Project files (package manifest, entry point, config):
<files>
{{files}}
</files>
</context>

<constraints>
- Open with one sentence on what the project does and who it is for.
- Only document commands, options and behaviour you can see in the files or notes. If something a reader needs is missing, add a line “TODO: …” rather than inventing it.
- The quick start must be copy-and-paste runnable, in order, starting from a clean machine.
- Prefer short sections and code blocks over paragraphs.
- Include a “Limitations” section if the notes mention any.
</constraints>

<output_format>
GitHub-flavoured Markdown. Sections in this order: title and one-line summary, Install, Quick start, Configuration, Limitations (if any), Contributing (one line), Licence.
</output_format>

<task>
Write the README for this project, aimed at {{reader}}.
</task>

You are a technical writer who writes READMEs that get a new user from zero to a working result quickly.

<constraints>
- Open with one sentence on what the project does and who it is for.
- Only document commands, options and behaviour you can see in the files or notes. If something a reader needs is missing, add a line “TODO: …” rather than inventing it.
- The quick start must be copy-and-paste runnable, in order, starting from a clean machine.
- Prefer short sections and code blocks over paragraphs.
- Include a “Limitations” section if the notes mention any.
</constraints>

<output_format>
GitHub-flavoured Markdown. Sections in this order: title and one-line summary, Install, Quick start, Configuration, Limitations (if any), Contributing (one line), Licence.
</output_format>

<context>
Notes from the maintainer:
<notes>
{{notes}}
</notes>

Project files (package manifest, entry point, config):
<files>
{{files}}
</files>
</context>

<task>
Write the README for this project, aimed at {{reader}}.
</task>

{{notes}}

What you know that the code doesn’t say: the purpose, who it is for, known limits, the licence.

{{files}}

The package manifest (package.json, pyproject.toml, Cargo.toml), the CLI or entry point, and any config schema or example config. These define the real commands and options.

{{reader}}

Who installs it, such as “Python developers who have never used our API”.

{{notes}}

A CLI that checks a folder of Markdown files for broken links. For docs teams. MIT licence. Doesn’t check links that need a login.

{{files}}

package.json:
{ "name": "linkcheck-md", "version": "0.3.0", "bin": { "linkcheck-md": "dist/cli.js" },
  "engines": { "node": ">=20" } }

src/cli.ts (options):
--dir <path>       folder to scan (default ".")
--timeout <ms>     per-link timeout (default 5000)
--ignore <glob>    skip matching files

{{reader}}

technical writers comfortable with a terminal but not with Node.js

What to look for. A good result tells the reader to install Node 20 or later first (the engines field), uses npx linkcheck-md --dir docs in the quick start, lists the three options in a table, and puts “links that need a login aren’t checked” under Limitations. Anything about CI integration should be a TODO.

You are a technical writer who writes READMEs that get a new user from zero to a working result quickly.

<context>
Notes from the maintainer:
<notes>
A CLI that checks a folder of Markdown files for broken links. For docs teams. MIT licence. Doesn’t check links that need a login.
</notes>

Project files (package manifest, entry point, config):
<files>
package.json:
{ "name": "linkcheck-md", "version": "0.3.0", "bin": { "linkcheck-md": "dist/cli.js" },
  "engines": { "node": ">=20" } }

src/cli.ts (options):
--dir <path>       folder to scan (default ".")
--timeout <ms>     per-link timeout (default 5000)
--ignore <glob>    skip matching files
</files>
</context>

<constraints>
- Open with one sentence on what the project does and who it is for.
- Only document commands, options and behaviour you can see in the files or notes. If something a reader needs is missing, add a line “TODO: …” rather than inventing it.
- The quick start must be copy-and-paste runnable, in order, starting from a clean machine.
- Prefer short sections and code blocks over paragraphs.
- Include a “Limitations” section if the notes mention any.
</constraints>

<output_format>
GitHub-flavoured Markdown. Sections in this order: title and one-line summary, Install, Quick start, Configuration, Limitations (if any), Contributing (one line), Licence.
</output_format>

<task>
Write the README for this project, aimed at technical writers comfortable with a terminal but not with Node.js.
</task>

• All models

  Paste the real --help output if your CLI has one. It is the most accurate list of options you can give the model.

• Claude

  Anthropic suggests putting long inputs above the instructions. If you paste many files, keep them in the context section (which comes first) and wrap each in its own tag with the file name.

• Gemini

  Google’s guide says to choose one delimiter style and use it consistently in a prompt. If you add more files, keep using the same XML tags rather than mixing in Markdown fences.

• Write docstrings and code commentsDocstrings in your project’s style covering parameters, returns, errors and the non-obvious why.
• Release notes from commitsTurn a list of commits or PRs into user-facing release notes, breaking changes first.
• Explain codeA plain-English walkthrough of unfamiliar code at the reader’s level: purpose, flow, side effects and traps.

Building this into an app that sends the same instructions with every request? Start from a system prompt instead; each comes with design notes, failure modes and a monthly cost. In the system prompt library: Technical writer for developer docs.

Edited the template? Compare your version with this one in the prompt diff, and count it for your model with the token counter. Browse all 29 prompt templates.