You're Already Writing a DSL — You Just Call It a Prompt

A markdown document being read by a model — the new source code

// tools in this post

Claude Code

MCP

Astro

Markdown

Open any serious prompt in 2026 and you’ll see the same shape. Headings. Bullet lists. Tags like <example> or <thinking>. Maybe a routing table. Maybe a section called “Hard Rules — Never Violate.”

It looks like documentation. It reads like documentation. It is not documentation.

It’s source code for a new kind of machine, and the language it’s written in doesn’t have an official name yet. So most of the people writing it don’t realize they’re writing it.

What a DSL Actually Is

A domain-specific language is a small language built for one job. SQL is a DSL for asking databases questions. Regex is a DSL for matching text. CSS is a DSL for styling. They each have syntax, semantics, and a runtime that knows what to do with them.

A DSL doesn’t have to be invented in a lab. Most of them weren’t. They grow — a convention here, a shared shorthand there — until enough people use them the same way that the conventions become the language.

That’s where we are with prompting right now.

The Syntax You’re Already Using

Look at a well-structured prompt and the building blocks are obvious once you start naming them:

Headings declare scope. ## Goals, ## Constraints, ## Output Format — the model uses these to bucket what follows.
Bullet lists declare enumerable items. Three bullets reads as “these are siblings, treat them as a set.”
Bold and inline code mark emphasis and literals — “this exact string matters.”
XML-ish tags (<example>, <thinking>, <system-reminder>) scope blocks of content with a label. They’re not parsed as XML. They don’t have to be valid. They just have to be consistent.
Code fences declare “this is data, not instruction.”
Tables declare relational structure — “this column maps to that column.”

None of these are required. The model will read a sloppy paragraph. But the same way a database will accept a query without indexes, it’ll do the work — slower, less reliably, and with more surprises.

A Concrete Before-And-After

Here’s a prompt written the way most people write them:

Hey, can you help me clean up this CSV? It’s got some bad rows and the dates are formatted weird. Also I think there are duplicates. Just give me back something usable in Excel.

Here’s the same intent, written in the soft DSL:

## Task
Clean the CSV provided below.

## Rules
- Drop rows where `email` is empty or malformed
- Normalize `date` to ISO 8601 (YYYY-MM-DD)
- De-duplicate on `email` — keep the most recent row by `date`

## Output
Return a single CSV block. No commentary.

Same request. The second one is faster to execute, more predictable across runs, and — critically — editable. Six months from now you can tweak one rule without rewriting the whole thing. That’s not a writing improvement. That’s a code improvement.

Why This Is Quietly Everywhere

Once you see it, you see it everywhere:

CLAUDE.md files in every Claude Code project — structured instructions with routing tables, hard rules, and identity blocks.
System prompts for every production LLM app — sectioned, tagged, often longer than the actual user input.
MCP server instructions — published as markdown, read by models, treated as authoritative.
Slash commands and skills — markdown files with frontmatter, called like functions.
Agent definitions — name, description, tools, prompt, all in structured fields.

The frontmatter at the top of this blog post is a tiny DSL too. title, description, date, tags — declared in YAML, consumed by Astro, rendered into a page. We’ve had this pattern for a decade in static-site generators. We just didn’t notice when it crossed over into talking to models.

What Changes When You Notice

Two things shift the moment you start treating prompts as code:

You version them. Prompts go into git. Diffs become reviewable. You stop rewriting the same instructions in three different chats.
You compose them. A “rules” block from one prompt drops cleanly into another. You build a private library of reusable fragments — the same way you’d build a library of functions.

The people getting disproportionate value out of LLMs right now aren’t the ones with secret prompts. They’re the ones who figured out the prompts are software, and started treating them that way.

The Takeaway

You don’t need to learn a new language. You’re already writing it. You just need to know that you are — and start writing it on purpose.

Headings to declare scope. Bullets to declare sets. Tags to scope blocks. Code fences for literals. Tables for relations. The grammar is small. The leverage is not.

Welcome to the DSL nobody officially named. It’s been here the whole time.