Loading page
About this tool
Build precise AI prompts for code review, unit tests, refactoring, regex, SQL explain, Dockerfiles, commit messages, changelogs, API docs and tech specs.
Better prompts get better code. Pick a coding task and fill in the details the model needs, such as language, constraints and edge cases, then copy a prompt for ChatGPT, Claude or Copilot. This page brings together 14 separate coding prompt builder pages (API doc, Changelog, Code comment, Code review, Commit message, Dockerfile, GitHub Copilot, Refactor, Regex, Release notes, SQL explain, Tech spec, Technical doc, Unit test) so you can compare them without hunting for the right one.
Open Coding Prompt Builder on AltFTool — it loads instantly in your browser.
Choose your task at the top: API doc, Changelog, Code comment, Code review and 10 more. On a phone it is a drop-down list.
Fill in the coding prompt builder for that task; each of the 14 options keeps its own rules, data and defaults.
Read the result, then switch task to compare. The page link keeps your task (?v=api-doc), so you can bookmark or share it.
API doc, Changelog, Code comment and the rest sit behind one picker, so switching task takes a tap instead of a new search.
Every task keeps its own rules, numbers and defaults rather than one generic template.
The link remembers the task you picked, so a bookmark or a shared link opens straight on it.
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.