Name: write-or-update-readme
Author: iloveitaly

Prompt file imported from iloveitaly/radar-mapping-api (.github/prompts/write-or-update-readme.prompt.md). Copyright stays with the author.

Write Or Update Readme

Write or update the @README.md:

First, think hard and investigate the source code in the repository to understand what it does
If the readme already exists, do not reword sections which feel complete or whose functionality has not changed.
- However, if specific rules below conflict with what is written, follow the rules below
Be concise, do not use too many adjectives
The title should be a short description of the project, not just the project name
Don't try to be too cute: no story telling and do not be overly salesly.
No emojis
Assume uv and omit pip examples
Include a single line at the end ## [MIT License](LICENSE.md) (above any template attribution)
When writing the overview and # header, be sure to:
- Think of what keywords another developer might search for.
- Include the primary goal of the project or primary problem solved in a short paragraph.
  - If you aren't sure what the primary goal of the project is, ask.
  - For the title, don't include just the name of the package. Instead make it a short description of the project. Just a handful of words, such as 'Manage Python Project Dependencies'
After a general overview, include the following sections: Installation, Usage, Features.
- When writing out a list of features, use a bullet list.
- Do not include "internal" features like * **Python 3.13+ with modern type parameter syntax**
Do not include every usage example varaint for a CLI or library. The goal is to give an overview so the user can figure out the rest on their own.
Do not remove badges or link to upstream template repo

Here's the writing style you should use:

Conversational and personal, often in first-person with enthusiastic, reflective tone on tech, startups, and health topics. Logical structure: hooks, breakdowns via subsections/lists, and practical steps. Vocabulary mixes everyday terms with technical jargon (e.g., tmux, Caddy, REPL). Short-to-medium sentences for clarity; semi-formal with casual asides and anecdotes

Update `pyproject.toml` metadata

Update the pyproject.toml keywords (maximum of 4) and description based on the contents of this repo. Do not use . in a keyword.

## Write Or Update Readme Write or update the @README.md: * First, think hard and investigate the source code in the repository to understand what it does * If the readme already exists, do not reword sections which feel complete or whose functionality has not changed. * However, if specific rules below conflict with what is written, follow the rules below * Be concise, do not use too many adjectives * The title should be a short description of the project, not just the project name * Don't try to be too cute: no story telling and do not be overly salesly. * No emojis * Assume `uv` and omit pip examples * Include a single line at the end `## [MIT License](LICENSE.md)` (above any template attribution) * When writing the overview and `#` header, be sure to: * Think of what keywords another developer might search for. * Include the primary goal of the project or primary problem solved in a short paragraph. * If you aren't sure what the primary goal of the project is, ask. * For the title, don't include just the name of the package. Instead make it a short description of the project. Just a handful of words, such as 'Manage Python Project Dependencies' * After a general overview, include the following sections: Installation, Usage, Features. * When writing out a list of features, use a bullet list. * Do not include "internal" features like ` * **Python 3.13+ with modern type parameter syntax**` * Do not include every usage example varaint for a CLI or library. The goal is to give an overview so the user can figure out the rest on their own. * Do not remove badges or link to upstream template repo Here's the writing style you should use: > Conversational and personal, often in first-person with enthusiastic, reflective tone on tech, startups, and health topics. Logical structure: hooks, breakdowns via subsections/lists, and practical steps. Vocabulary mixes everyday terms with technical jargon (e.g., tmux, Caddy, REPL). Short-to-medium sentences for clarity; semi-formal with casual asides and anecdotes ### Update `pyproject.toml` metadata Update the `pyproject.toml` keywords (maximum of 4) and description based on the contents of this repo. Do not use `.` in a keyword.

{ "prompt": "## Write Or Update Readme\n\nWrite or update the @README.md:\n\n* First, think hard and investigate the source code in the repository to understand what it does\n* If the readme already exists, do not reword sections which feel complete or whose functionality has not changed.\n * However, if specific rules below conflict with what is written, follow the rules below\n* Be concise, do not use too many adjectives\n* The title should be a short description of the project, not just the project name\n* Don't try to be too cute: no story telling and do not be overly salesly.\n* No emojis\n* Assume `uv` and omit pip examples\n* Include a single line at the end `## [MIT License](LICENSE.md)` (above any template attribution)\n* When writing the overview and `#` header, be sure to:\n * Think of what keywords another developer might search for.\n * Include the primary goal of the project or primary problem solved in a short paragraph.\n * If you aren't sure what the primary goal of the project is, ask.\n * For the title, don't include just the name of the package. Instead make it a short description of the project. Just a handful of words, such as 'Manage Python Project\n Dependencies'\n* After a general overview, include the following sections: Installation, Usage, Features.\n * When writing out a list of features, use a bullet list.\n * Do not include \"internal\" features like ` * **Python 3.13+ with modern type parameter syntax**`\n* Do not include every usage example varaint for a CLI or library. The goal is to give an overview so the user can figure out the rest on their own.\n* Do not remove badges or link to upstream template repo\n\nHere's the writing style you should use:\n\n> Conversational and personal, often in first-person with enthusiastic, reflective tone on tech, startups, and health topics. Logical structure: hooks, breakdowns via subsections/lists, and practical steps. Vocabulary mixes everyday terms with technical jargon (e.g., tmux, Caddy, REPL). Short-to-medium sentences for clarity; semi-formal with casual asides and anecdotes\n\n### Update `pyproject.toml` metadata\n\nUpdate the `pyproject.toml` keywords (maximum of 4) and description based on the contents of this repo. Do not use `.` in a keyword.", "variables": [], "notes": "Write or update the @README.md: Mode: agent.", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/iloveitaly/radar-mapping-api", "path": ".github/prompts/write-or-update-readme.prompt.md", "ref": "3086402733a417224c51d4fc32df810563053721", "url": "https://github.com/iloveitaly/radar-mapping-api/blob/3086402733a417224c51d4fc32df810563053721/.github/prompts/write-or-update-readme.prompt.md", "key": "iloveitaly/radar-mapping-api/.github/prompts/write-or-update-readme.prompt.md" } } }

write-or-update-readme

About