I’m involved in artificial intelligence development in various capacities, as I believe many of you are. Prompt engineering is maybe the most recurrent one, since nowadays all models require it: from basic searches to MCP requests. That’s why you should become a Markdown expert.
Markdown is more than 20 years old, but no one in 2004 thought it would become so important. Today, I think its main implementation is about prompt engineering: MD is perfect to handle them, because it combines the simplicity of plain text with the complexity of code.
John Gruber (and Aaron Swartz) maybe didn’t expect such success, but the flexibility of this markup language made it ideal for several purposes: in fact, I spent years using it just to write README files and stuff on GitHub with its GFM syntax. Now it’s time to level up.
I don’t think it’s hard to learn Markdown, but I also think that Markdown itself isn’t enough to achieve great results. Anyway, let’s start with the basics: below, I’ll share my daily habits in writing prompts. I hope you can find it useful to do the same for your projects.
Syntax
If you’re a DEV Community member, then you already know how to use Markdown, and writing articles isn’t that different—neither prompting requires further symbols. I’m not saying you can use them as prompts, even though they share the same syntax, but you don’t need to know more about.
# Heading
...
### Heading
_italics_
**bold**
[link](https://...)
- item
- item
1. item
2. item
> quote
`inline code`
```
code block
```
--- separator
Sometimes, you may want to escape characters, like I did above for code blocks, and MD let you do it in several ways: here I chose ~~~, for example, but it depends on the Markdown implementation you’re using. Think of it as a sum of dialects, rather than a single language.
Variants
I excluded some variants on purpose, since I think using a single asterisk * for italic text and unordered list items can be confusing, as well as using double underscores __ for bold text. Also tildes ~~~ can be useful here to help me format this article, but I wouldn’t use them in prompts.
XML
Some models, such as Claude by Anthropic, use XML tags in prompts to structure examples and/or separate chapters. In Markdown, you’re free to add them, including reserved HTML tags, if you need to: I don’t like it much, but I found situations where they were useful in the past, and I think I will in the future.
Variables
You can also specify variables or, better, placeholders that will accept values from an LLM response. I prefer to use double curly braces here {{...}}, because they’re popular among JavaScript frameworks: it’s up to you, once your choice is consistent, since they aren’t related to Markdown syntax.
Writing prompts is a matter of habits and conventions. The release of GPT-5 showed that what we considered right can be no longer so—using OpenAI models, at least. This doesn’t mean that Markdown will be replaced soon: I think it’s going to be even more important.
Yes, because it allow us to write prompts for all purposes. I didn’t mention it, but Markdown includes media embedding as well: you can add audio tracks, images, and videos to your prompt. I don’t know why you should, but you can, even falling back to HTML where needed.
Visual Studio Code
Mastering Markdown isn’t that hard, but VS Code provide a great integration that also let you preview your documents: this, to be honest, is more important working with README or other kinds of files. Anyway, I suggest you to have a look at its documentation to better understand how it works.
This is just my first approach to prompt engineering here, since I plan to share more best practices in the near future. I started with Markdown, because I don’t like Jupiter Notebook much, so I will mainly talk about MD: JavaScript and Python tools will follow.
Top comments (0)