April 21, 2026
Agent skills are already little programs written in markdown, especially the ones with a specific sequence of steps. The agent reads the skill file and follows it. No code, just instructions.
Skills today are usually small workflows: a handful of steps the agent threads through. That got me wondering how far the pattern goes. What if a whole application lived in markdown, not just a workflow? And what if state lived there too, not just the instructions? The agent reads and writes files, and that's the whole runtime.
And if the app is markdown, the dev setup can be too. How it evolves, its test suite, all of it.
I tried this on something concrete: markdown-adventure, a text adventure game you play through Claude Code. It's the old Unix adventure, except the world is invented on the fly, you type in freeform English instead of VERB NOUN, and the runtime is markdown instead of C.
You open the folder and say "start a noir adventure" or "continue rust-hollow". The agent invents the world, you type what your character does in freeform English, and every turn writes to files under sessions/<name>/. No save button. Every turn persists.
The game rules, including the I/O (which files the agent reads at the start of a turn and what it writes at the end), live in rules.md. AGENTS.md sits above that and routes the user's first message. If you say "start a noir game" or "continue rust-hollow", it enters play mode and runs the turn loop from rules.md. If you say "edit the tone contract" or "add a QA test", it enters dev mode, which follows a different set of rules for modifying the game itself and leaves session data alone.
The part I most wanted to get right was continuity. On-disk state after any turn has to be enough for a fresh agent to pick up seamlessly. state.md is rewritten every turn, canon.md collects world truths append-only, journal.md keeps the last five turns verbatim and compresses older ones into prose, and named entities get promoted to files under world/ as they're mentioned twice or interacted with. You can stop mid-turn and come back tomorrow. The same files work in Codex or Gemini CLI, but Claude Code is where I've mainly used it and where it runs best.
The dev setup is markdown too. dev/rules.md governs changes to the rules. One of its principles is that "if you find yourself reaching for code, the design has drifted." dev/qa.md describes a QA harness that spawns the game agent as a subprocess, drives it through scenarios under dev/qa/scenarios/, and checks structural (file shape) and behavioral (tone, fourth wall) assertions.
This is an experiment, not a pattern to copy. For most apps you want determinism. It's a little less crazy to drop it here, because the narration is non-deterministic, and so are the contents and shape of the state files the agent writes.
I tested it in Claude Code on Opus 4.6 with extended thinking disabled (MAX_THINKING_TOKENS=0) to stretch tokens across the Max plan's 5-hour window. The rules file itself went through several passes. QA kept surfacing spots where the agent drifted from the tone contract or bent an invariant, and I tightened the rules in response.