How to write a vibe coding prompt
Five lines that every prompt on the shelf shares: stack, data, safety, access and the one edge case, checked against the prompting guides GitHub and Google publish.
Written by the editors with AI assistance. The example prompt has not been run against a named assistant. Sources checked 2026-10-15.
- 1 Stack Say the language and what not to use: plain JavaScript, no dependencies.
- 2 Data Name the shape of the data, including where it came from.
- 3 Safety Name the safe API for anything user-supplied, such as textContent.
What are the five lines?
A coding prompt is a short specification. The assistant fills every gap you leave with a default, and the defaults are where copied code has always gone wrong: an extra library, markup built from strings, a widget that only works with a mouse. The prompts on the CodeLifter shelf close those gaps with the same five lines.
Stack: the language, the framework if any, and what to avoid, for example plain JavaScript with no dependencies and no build step. Data: the shape of what goes in and out, with an example value, and where it comes from. Safety: the API to use for anything a visitor or another system can supply, for example textContent rather than innerHTML. Access: keyboard use, screen reader output and the reduced-motion setting. Behaviour: the one edge case that matters most, such as never repeating the same quote twice in a row.
The five lines are the editors’ checklist, drawn from what went wrong in the scripts restored on this site. They are not a standard, and you can add lines your project needs.
What do the assistant makers’ own guides say?
GitHub’s guide to prompt engineering for GitHub Copilot Chat gives the same order of work: start with a broad description of the goal, then list the specific requirements. It also advises giving examples of input data and output, breaking a complex task into small tasks, avoiding ambiguous words such as “this”, and naming the library you want to use. If the answer is not what you wanted, it suggests iterating on the prompt and keeping the chat history relevant.
Google’s prompt design strategies for the Gemini API make three points that map onto the five lines. Give clear and specific instructions. Specify constraints, since “you can tell the model what to do and not to do”. Include examples: the guide says “we recommend to always include few-shot examples in your prompts”, and that a consistent format across examples shows the model the format you want back. It also suggests adding the context the model needs rather than assuming it has it, and breaking complex prompts into simpler components.
Neither guide is about security. The safety line comes from the platform documentation instead: MDN’s page on innerHTML notes that textContent should be used when user-provided content should be plain text, because that prevents it being parsed as HTML.
What does a weak prompt look like next to a strong one?
Here is a weak prompt and the same request with the five lines added. The prompt was written by the editors to illustrate the pattern. It has not been run against a named assistant, so this page makes no claim about what any tool returns for it.
Where should the lines you repeat in every prompt go?
Lines you would repeat in every prompt, such as no innerHTML or keyboard support for every control, belong in a rules file the assistant reads on its own. GitHub’s documentation on repository custom instructions describes a .github/copilot-instructions.md file for instructions that apply to every request in a repository, and AGENTS.md files for agents, where the nearest AGENTS.md in the directory tree takes precedence.
The AGENTS.md project describes the file as a simple, open format for guiding coding agents, a README for agents, and lists build and test commands, code style and security considerations among the sections people usually include. Keep the file short and specific; it is a prompt too.
The coding agents directory on CodeLifter lists which file each tool reads.
Then read the code
A good prompt reduces mistakes; it does not remove them. Read what comes back before it reaches users: check that it uses the API you named, that it works from the keyboard, and that it handles the edge case you asked for. Then record what was generated and by what, in the commit or in a comment, so the next person knows where the code came from.
If the answer misses one of the five lines, say which line it missed and ask again, rather than patching the code by hand and losing the record of what the assistant produced. Both vendor guides treat a second, narrower prompt as normal practice.
How this page was checked
The editors opened each source below on 2026-10-15 and checked every statement attributed to it. The five lines are the editors’ own checklist, not a finding from either guide. No prompt on this page was tested against an assistant.
Prompt engineering for GitHub Copilot Chat, GitHub Docs: https://docs.github.com/en/copilot/concepts/prompting/prompt-engineering
Prompt design strategies, Gemini API, Google AI for Developers: https://ai.google.dev/gemini-api/docs/prompting-strategies
Adding repository custom instructions for GitHub Copilot, GitHub Docs: https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions
AGENTS.md: https://agents.md/
Element: innerHTML property, MDN: https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML
Questions and answers
How do you write a good prompt for coding?
State five things: the stack and what to avoid, the shape of the data, the safe API for anything user-supplied, keyboard and screen reader access, and the one edge case that matters most. GitHub and Google both advise a clear goal, specific requirements and examples.
Should I tell the assistant what not to do?
Yes. Google's prompt design guide says you can tell the model what to do and not to do, and constraints such as no dependencies or textContent rather than innerHTML close the gaps where copied code usually goes wrong.
Where should rules I repeat in every prompt go?
In the instruction file your tool reads for the whole repository, such as AGENTS.md or GitHub's repository custom instructions, so you do not have to restate them. Keep the task-specific lines in the prompt itself.