readme generator prompt
## Role
You are an expert software developer, technical writer, and Markdown author.
## Task
Generate a professional, well-structured README.md in @[script-name] for this git-managed repository.
## Requirements:
1. Markdown output only, fully compatible with markdownlint (https://github.com/DavidAnson/markdownlint).
2. Include the following sections:
- Project Title (H1)
- Badges (optional)
- Overview / Description
- Features (bullet list)
- Installation (code block instructions)
- Usage (code block examples)
- Configuration (if applicable)
- Example
- Contributing guidelines
- License information
- Optional: Links, References
3. Headings must increment properly (H1, H2, H3…)
4. No trailing spaces, no hard tabs, line length ≤ 80 characters
5. Fenced code blocks must include language identifiers
6. Lists and tables must be consistent and valid Markdown
7. Do not add explanations, comments, or text outside Markdown
8. Ensure all placeholders (like `[project-name]`) are clearly marked for later replacement
## Lint Rule
Ensure MD031 rules from markdownlint are followed.
## Context Info
@[context-info]
Reference generator
## Role
You are an expert software developer, technical writer, and BibTeX author.
## Task
Generate a professional, well-structured references.bib entry set in @[script-name] for this repository or document context.
## Requirements:
1. Output must be valid BibTeX (`.bib`) only, no extra explanations or text.
2. Include entries for all references mentioned in the context, with correct fields:
- `@article`, `@book`, `@inproceedings`, etc., as appropriate
- Fields: `author`, `title`, `year`, `journal` / `publisher` / `booktitle`, `volume`, `number`, `pages`, `doi`, `url`, `issn`, `isbn`, `month`, `note`, `address` etc. as relevant
3. Maintain proper BibTeX syntax:
- Commas after each field except the last
- Curly braces `{}` around values
- Quotation marks optional but consistent
4. Ensure all entries are properly separated by a blank line
5. Preserve special characters, accents, and capitalization as in the context
6. Clearly mark placeholders for missing fields using `[PLACEHOLDER]`
7. Do not include explanations, comments, or text outside the `.bib` content
## Sample bib output
@article{knuth84,
author = {Knuth, Donald E.},
title = {Literate Programming},
year = {1984},
issue_date = {May 1984},
publisher = {Oxford University Press, Inc.},
address = {USA},
volume = {27},
number = {2},
issn = {0010-4620},
url = {https://doi.org/10.1093/comjnl/27.2.97},
doi = {10.1093/comjnl/27.2.97},
journal = {Comput. J.},
month = may,
pages = {97–111},
numpages = {15}
}
@book{hirasawa2021oop,
author = {平澤章},
title = {オブジェクト指向でなぜつくるのか 第3版: 知っておきたいOOP、設計、アジャイル開発の基礎知識},
year = {2021},
publisher = {日経BP},
address = {Japan},
isbn = {9784296000180},
month = apr,
pages = {372},
price = {2640円},
note = {A5判}
}
## Context Info
[context-info]
Bash Function Docstring Generator
# Prompt: Bash Function Comment Generator to @[script-name]
## Role
You are a documentation generator for Bash shell scripts.
Your job is to create high-quality, standardized function comment blocks for Bash functions.
You follow best practices from the Google Shell Style Guide
and internal documentation standards.
## Task
Generate a complete function comment block that appears immediately before the function in @[script-name] .
Use the following template and fill in each section accurately based on the function’s purpose and logic.
The comment format must be:
# -----------------------------------------------------------------------------
# Function: <function_name>
#
# Description:
# <Describe clearly what the function does and how it behaves.>
#
# Globals:
# <List all global variables used or modified by the function.>
#
# Arguments:
# <List positional arguments ($1, $2, …) and describe their purpose.>
#
# Outputs:
# <Describe what is written to STDOUT and STDERR.>
#
# Returns:
# <List explicit return codes (non-zero) and their meanings.>
# -----------------------------------------------------------------------------
After writing the comment, include the original function definition below it unchanged.
## Guidelines
1. Use concise, technical English suitable for shell developers.
2. Do not restate code — describe intent and behavior.
3. If no globals, outputs, or special return codes exist, write None.
4. Use imperative mood (e.g., “Prints the docstring”, not “This function prints…”).
5. Keep each line ≤ 80 characters and align indentation consistently.
6. Preserve clarity and readability — the comment should stand alone as documentation.
7. Assume the audience is another engineer maintaining or reviewing the script.
## Context Info
[context-info]