README
Writes a README from your manifest, code and tests: what it does, a quick start of five steps or fewer, real usage examples and licence.
When to use itUse it for a new repository or a README that has drifted from the code. Include tests or example scripts so the usage section shows real behaviour; the model cannot run the quick start, so try it once before publishing.
- Type
- Playbook
- Inputs it asks for
- 05
- Sections it returns
- 07
- Quality checks
- 07
On this page5 sections
Asks for
What you hand it before it runs. Required ones are marked.
- 01Source materialLong textRequired
Package manifest (package.json, pyproject.toml, Cargo.toml, go.mod), entry points, CLI --help output, tests or example scripts, config files, LICENSE, and any existing README or notes.
- 02Tested againstText
Version or commit, and the date the quick start was last run, e.g. 0.8.2, run on 2026-10-10. Left blank, the README flags it.
- 03Project nameText
Left blank, taken from the manifest.
- 04AudienceSelect
Public READMEs leave out internal hosts, team names and internal links; internal ones can keep them.
- 05Contributing and licenceLong text
How changes are proposed, tested and reviewed, and the licence if the source has no LICENSE file.
Method
The instruction the model follows, word for word as it ships in the SKILL.md.
You write a README from the Source material. The Technical Documentation Writer rules apply throughout (source only, [VERIFY] flags and the To verify list, show then explain, action plus expected result, ALL_CAPS placeholders, labelled shell syntax, precise verbs). This method adds only what is specific to READMEs.
The README succeeds when a reader can tell from the first screen what the project does and whether it fits their need, then reach a first working result through the quick start.
Structure:
- H1: the project name, from Project name or the manifest. Under it, one sentence saying what the project is, then one line: "Tested against: " followed by the Tested against value. If Tested against is blank, write "Tested against:
[VERIFY: version and date last run]". - What it does: two or three sentences on what the project does and its main limits, based on what the code does. Leave out feature claims, performance figures, badges, compatibility promises and comparisons the source does not support.
- Quick start: five steps or fewer from a clean machine to a first working result, numbered, each with its code block and an Expected result line. Link to a fuller setup guide only if the source mentions one.
- Usage: two or three common tasks, each as an H3 with a complete code block and its output. Take them from tests, example scripts, CLI help or docstrings in the source; a test case shows real behaviour, so prefer it to a call you compose.
- Configuration: a table with the columns Name, Required, Default, Description for options the source defines. If there are none, write "No configuration options."
- Contributing: the process from Contributing and licence or the source (branching, tests to run, review). If neither covers it, write "Contribution process not documented yet." and flag it.
- Licence: the licence named in the LICENSE file, the manifest or the Contributing and licence field. If none is shown, write "
[VERIFY: licence]". Never assume one. - To verify: the numbered list of every
[VERIFY]flag, each with its section and what would settle it.
For a Public audience, leave out internal hostnames, team names, internal ticket links and anything resembling a credential found in the source, and list under To verify anything you removed that a reader may still need.
Length: 300 to 900 words of prose, excluding code. If the source shows no way to install or run the project, ask up to three specific questions instead of writing.
Returns
Every reply comes back in this shape, in this order.
- 01What it does
- 02Quick start
- 03Usage
- 04Configuration
- 05Contributing
- 06Licence
- 07To verify
Quality checks
Read the reply against these before you use it. Tick them off as you go; nothing is saved.
0 of 7 checked
SKILL.md
The whole playbook as one skill file, for Claude, Codex or any tool that reads SKILL.md.
---name: "readme"description: "Writes a README from your manifest, code and tests: what it does, a quick start of five steps or fewer, real usage examples and licence."--- # README You write a README from the Source material. The Technical Documentation Writer rules apply throughout (source only, [VERIFY] flags and the To verify list, show then explain, action plus expected result, ALL_CAPS placeholders, labelled shell syntax, precise verbs). This method adds only what is specific to READMEs. The README succeeds when a reader can tell from the first screen what the project does and whether it fits their need, then reach a first working result through the quick start. Structure:- H1: the project name, from Project name or the manifest. Under it, one sentence saying what the project is, then one line: "Tested against: " followed by the Tested against value. If Tested against is blank, write "Tested against: [VERIFY: version and date last run]".- What it does: two or three sentences on what the project does and its main limits, based on what the code does. Leave out feature claims, performance figures, badges, compatibility promises and comparisons the source does not support.- Quick start: five steps or fewer from a clean machine to a first working result, numbered, each with its code block and an Expected result line. Link to a fuller setup guide only if the source mentions one.- Usage: two or three common tasks, each as an H3 with a complete code block and its output. Take them from tests, example scripts, CLI help or docstrings in the source; a test case shows real behaviour, so prefer it to a call you compose.- Configuration: a table with the columns Name, Required, Default, Description for options the source defines. If there are none, write "No configuration options."- Contributing: the process from Contributing and licence or the source (branching, tests to run, review). If neither covers it, write "Contribution process not documented yet." and flag it.Used together with
- 01Technical Documentation WriterWrites setup guides, API references, READMEs and runbooks from your source material, and flags anything it cannot confirm.Operator
- 02API Endpoint ReferenceTurns route code, schemas or captured requests into endpoint reference docs with parameter tables, full examples and error fixes.Playbook
- 03Setup GuideTurns code, config files and install logs into a setup guide where every step shows the command and the result to expect.Playbook
Free to use and adapt under CC BY 4.0. Credit MyPromptVerse.
Built in MyPromptVerse. Follow the build →