The DSL Nobody Designed

This is part of the Prompt-as-DSL series, where the throughline is that prompts quietly became source code — and this post is the origin story of the language they’re written in.

No one approved it. No standards body voted on it. There’s no RFC, no spec document, no working group with a logo. And yet open up any serious AI tool in 2026 and you’ll find the same thing under the hood: a markdown file with headings, bullet lists, a code fence or two, maybe some YAML at the top. The same dialect, everywhere, by accident.

That’s a strange thing to happen. Standards are supposed to be hard. They take years, committees, fights over commas. This one showed up while everyone was busy doing something else.

Here’s how we got here.

It started with frontmatter

Long before anyone was prompting a model, static-site generators taught a generation of developers to put structured metadata at the top of a markdown file.

---
title: "My Post"
date: 2026-05-25
tags: ["a", "b"]
---

Body goes here.

Jekyll did it. Hugo did it. Astro — the thing rendering this very post — does it. The pattern was simple and it stuck: a fenced block of declarative key-value pairs, then human-readable content below. Machine-readable head, human-readable body, one file.

Nobody thought of that as a programming construct. It was just a convenient way to tell the build tool what the page was. But it planted the seed: markdown with a structured header is a normal, comfortable shape, and developers already had it in muscle memory.

That mattered more than anyone realized at the time.

Then system prompts needed structure

When LLM apps got serious, the system prompt stopped being a sentence and became a document. “You are a helpful assistant” doesn’t survive contact with a real product. You need scope, constraints, output format, examples, hard rules.

So people reached for the tool they already knew. Headings to separate concerns. Bullet lists for rules. Tags like <example> to fence off a sample. It wasn’t designed — it was the path of least resistance. You needed to organize a wall of instructions, and markdown was sitting right there.

The model went along with it because it had been trained on a planet’s worth of markdown. Headings, bullets, and fenced code already carried meaning to it. Nobody had to teach the model the convention. It absorbed the convention the same way we did — by reading the whole internet, where that’s just how structured writing looks.

That’s the quiet hinge of this whole story. The format won because both ends already spoke it. Humans write markdown without thinking. Models read markdown without prompting. The handshake was free.

Then MCP published its instructions in it

When the Model Context Protocol arrived to standardize how AI tools connect to the outside world, it needed a way for a server to tell a model how to behave. Not a config schema for machines — guidance for a model to read.

It shipped that guidance as markdown. Plain instructions, sectioned with headings, treated as authoritative. A server publishes its instructions, the model reads them like a brief, and that’s the contract.

Read that back slowly. A protocol — the most “spec the format” moment you could ask for — chose prose-in-markdown as its instruction layer. Not JSON. Not a custom grammar. The same dialect the blog frontmatter was using a decade earlier, now load-bearing inside a wire protocol.

Then CLAUDE.md made it a file you commit

The next move was the one that made it undeniable. Coding agents started reading a project file on startup — CLAUDE.md and its cousins — to learn the rules of the repo before touching a line of code.

Look at what’s in one of those files and the grammar is fully formed:

• An identity block up top — who the assistant is in this project.
• A routing table — a literal markdown table mapping a task to where it should go.
• A “Hard Rules — Never Violate” section — constraints with teeth.
• Conventions, examples, scopes, all under headings.

This isn’t a prompt you type once. It’s a file. It sits in the repo. It goes into git. It gets diffed in pull requests, reviewed, reverted, argued over. The instructions to the machine became a versioned artifact that lives next to the code it governs — which is the exact definition of source.

And critically: nobody mandated the shape. There was no schema you had to satisfy. People wrote these files the way they’d write good documentation, and a consistent structure emerged because the same structure kept working.

Then skills and slash commands made them callable

The last piece snapped in when these markdown files got a calling convention.

A skill is a markdown file with frontmatter describing what it does and when to use it. A slash command is a markdown file you invoke by name. Same shape as the blog post at the top of this article — YAML header, prose body — except now it’s not rendered into a webpage. It’s loaded as behavior and called like a function.

---
name: deploy-check
description: Run before any production deploy.
---

## Steps
1. Confirm tests pass.
2. Check the changelog is updated.
3. Refuse if either fails.

Frontmatter declares the interface. The body is the implementation. You invoke it by name. If you squint, that’s a function signature and a function body — written in markdown, executed by a model.

The frontmatter-plus-prose pattern that static sites invented to describe a blog post is now describing a unit of executable behavior. Same syntax. Wildly different job. Nobody renamed it on the way over.

Nobody convened a committee — and that’s the point

Walk the lineage back and there’s no inventor to credit:

Era	Artifact	What carried over
Static sites	Post frontmatter	YAML head + markdown body
LLM apps	System prompts	Headings, bullets, tags for structure
Protocols	MCP instructions	Prose-in-markdown as authoritative guidance
Coding agents	CLAUDE.md	A versioned, committed instruction file
Tooling	Skills, slash commands	Frontmatter + body, called like functions

Each step borrowed the shape of the one before it because the shape already worked and both the humans and the models already understood it. That’s not how standards usually form. Usually someone writes the spec first and the tools follow. Here the tools moved first and the spec never got written, because it didn’t need to be. The convention was the standard.

This is what accidental standardization looks like. It doesn’t announce itself. There’s no version 1.0. One day you notice that five tools from five different teams all read a markdown file with a YAML header and a “Rules” section, and none of them coordinated, and all of them agree.

The committee never met. The RFC was never filed. And here we all are anyway, writing the same dialect, pretending it has no name.

It has a shape, even if it doesn’t have a name. And once you can see the shape, you can write it on purpose instead of stumbling into it — which is the whole reason this series exists.

---

We build AI systems on top of this format every day — the system prompts, the agent definitions, the project files that actually decide whether the thing works. If you’d rather have someone who understands this language fluently build your AI tooling instead of guessing at it, let’s talk about what you’re trying to automate.