AltZTraining for Every AltZ Venture
Working with AI: The Prerequisites
beginner12 min

Markdown for Prompting

Plain-text structure that models parse reliably — and why it changes your results.

Markdown is a way of adding structure to plain text using punctuation. It was invented for writing web pages without HTML, and it has quietly become the native formatting language of AI tools — models are trained on enormous amounts of it, they emit it by default, and they follow it more reliably than they follow prose describing the same structure.

That last point is the one worth internalizing. "Give me three sections" is a request the model may or may not honor. Three Markdown headings in your prompt is a structure it tends to mirror.

Headings

One to six # characters, then a space. The number of hashes sets the level.

# Document title

## A major section

### A subsection

The space after the hashes is required. #Heading is literal text with a hash in front of it, not a heading — this is the single most common Markdown mistake.

Headings do double duty in prompting: they organize what you send, and they give the model an obvious pattern to follow in what it returns.

Lists

Unordered lists use - (hyphens are conventional; * and + also work, but pick one and stay consistent):

- Context window
- Token
- System prompt

Ordered lists use a number, a period, and a space:

1. Draft the system prompt
2. Test on three real inputs
3. Adjust and repeat

A detail that surprises people: the numbers you type don't have to be correct. Markdown renumbers automatically, so a list written entirely as 1. renders as 1, 2, 3. Handy when you are reordering steps by hand.

Nested lists are indented by two spaces:

- Beginner
  - The Lexicon
  - Markdown
- Advanced
  - JSON Schema

Emphasis

_italic_ or _italic_ **bold** or **bold** _**bold italic**_ `inline code`

Use **bold** for the term a reader must not miss, and backticks for anything literal — a filename, a field name, a value. Backticks are the more useful of the two in prompting: they mark a string as exactly this text rather than a word to be interpreted.

Compare:

Set the status to done.

Set status to "done".

The second leaves no room for the model to decide that "Done" or "completed" is close enough.

Code blocks

Three backticks, an optional language name, your content, three backticks:

```json
{ "status": "done" }
```

Always name the language. It costs you four characters and it tells the model unambiguously what kind of content it is looking at — which changes how it reads the block and how it formats anything similar it returns.

Tables

| Term    | Meaning                           |
| ------- | --------------------------------- |
| Token   | A ~4-character chunk of text      |
| Context | Everything the model sees at once |

The dashed row under the header is required. Tables are excellent for giving a model a small reference dataset inline, and they are much cheaper in tokens than the equivalent prose.

Putting it together

Here is the same request written two ways. The first is what most people type:

I need you to look at this support ticket and tell me how urgent it is and
what team should get it and summarize it, and please be brief.

The second uses structure:

# Task

Triage the support ticket below.

# Output

- **Urgency**: one of `low`, `medium`, `high`
- **Team**: one of `billing`, `technical`, `account`
- **Summary**: one sentence, maximum 20 words

# Ticket

Customer says their invoice shows a charge they don't recognize from March.

Both convey the same intent. The second gets you the same shape of answer every time, uses backticks to pin the allowed values, and is far easier to edit when the requirements change — which is the actual goal.

Check yourself

  • Why does #Heading fail to render as a heading?
  • When would you use backticks rather than bold?
  • Rewrite "give me the answer with a title, three bullet points, and a closing line" as Markdown structure.

Next: forcing strict JSON output — a hands-on lab in the live workspace.