Coding Prompt Builder

14: API doc, Changelog, Code comment, Code review, Commit message, Dockerfile, GitHub Copilot, Refactor, Regex, Release notes, SQL explain, Tech spec, Technical doc, Unit test. Pick one at the top of the tool; the page link updates (for example ?v=api-doc) so you can bookmark or share that exact view.

Five things: a one-sentence purpose, every parameter with location, type, required flag and example, a realistic request and success response with the correct status code, the error cases with their status codes, and a note on idempotency and retry behaviour. The generated prompt demands all five for every endpoint in your list.

Semantic Versioning 2.0.0 is explicit: increment MAJOR for backwards-incompatible API changes, MINOR for backwards-compatible new functionality, and PATCH for backwards-compatible bug fixes. One breaking change anywhere in the set forces MAJOR, no matter how many small fixes ship with it.

JSDoc puts the type in braces — @param {string} name - description — while TSDoc omits types entirely, writing @param name - description, because the TypeScript signature already declares them. TSDoc is the standard consumed by Microsoft's API Extractor; JSDoc 3 is the older JavaScript convention that doubles as a type source for plain JS.

About 200 to 400 lines per review session. SmartBear's study of peer code review at Cisco found defect-discovery effectiveness drops sharply beyond roughly 400 lines, and recommends reviewing no faster than about 500 lines per hour. This tool computes the number of passes a larger change needs and writes that instruction into the prompt.

A commit header of the form type(scope)!: description — for example feat(parser): add array support — followed by an optional body and footers, as defined by the Conventional Commits v1.0.0 specification. feat maps to a SemVer MINOR release, fix to PATCH, and a ! or BREAKING CHANGE footer to MAJOR.

State the runtime and version, the exact dependency manifest to copy first, the install/build/start commands, the port, and the hardening you require (multi-stage, non-root, pinned tags). This tool assembles all of that into one structured prompt; vague prompts like 'write a Dockerfile for my app' are what produce bloated single-stage images running as root.

State the goal in one sentence, then the inputs, the expected output, any constraints, and finish with a concrete input → output example — all as comments directly above your cursor. GitHub's guidance summarises it as: provide context, keep it to a single task, and show an example rather than describing one.

Refactoring changes a program's internal structure without changing its observable behaviour — same outputs, side effects and error behaviour for every input — while a rewrite may change behaviour. The generated prompt states this definition up front and instructs the model to skip any change it cannot prove behaviour-safe.

Give it concrete examples, not just a description: strings the pattern must match, strings it must not, the exact flavour, and a requirement to verify the pattern against every example in a test table before answering. This tool assembles precisely that prompt — descriptions alone routinely produce patterns that fail on real input.

A changelog is the complete, chronological record of every change, written for people who want the detail. Release notes are the announcement for one release, written for people who just want to know what changed for them. The changelog is generated from commits; the release notes are edited by a human from that list.