Why this page exists
In Session 1 you learned that AI answers are markdown rendered by the chat window. That was a fun fact. Now it's leverage: the same syntax that formats an answer coming OUT can structure your prompt going IN - and it can configure whole AI coding tools through plain .md files. Your Session 1-2 skills transfer directly; nothing new to memorize.
Your AI chats are already markdown 5 min read
When a model answers with clean headings, bullet lists, a comparison table, and a grey code box, it isn't using a secret rich-text mode. It writes # headings - lists | tables | ``` fences as plain text, and the chat window renders them - the exact pipeline from Session 1's first diagram.
Self-studyReading answers structurally3 min▶
Once you know the elements, an AI answer stops being a wall of text and becomes a document with a skeleton you can scan:
- Headings mark the answer's sections - scan them first and you know the shape of the whole reply before reading a word of body text.
- Lists mean "parallel items" - options, steps, reasons. If the model numbered them, order matters; if it bulleted them, it doesn't.
- Tables mean "compare across dimensions" - and you can copy them straight into your own markdown files, because they already ARE markdown.
- Code fences mean "use this exactly as written" - commands, code, config. The fence is the model telling you where copy-paste territory begins and ends.
The copy-paste superpower: ask an AI for a comparison of three tools, click the copy button, and paste the answer into your profile README draft. The headings, list, and table arrive as valid markdown and render perfectly on GitHub - because there was never any conversion step at all. One syntax, end to end.
Self-studyFrom blob to blueprint: your first structured prompt4 min▶
Most prompts are one breathless blob: "rewrite this email to be formal but short also keep the friday date hi team the launch moved to friday thanks". Where does the instruction end and the email begin? The model has to guess. Structure removes the guessing:
Rewrite the email below to be more formal.
- Keep it under 50 words
- Keep the Friday date
hi team the launch moved to friday thanks
- Same request, zero ambiguity. The task, the rules, and the raw material each live under their own heading - nothing gets mistaken for anything else.
- Every character is Session 1-2 material: # headings, a - list, a ``` fence. You already knew how to write this.
Structure makes prompts better 5 min read
Three structural moves cover most prompt problems. Each one maps to an element you already own.
Self-studyHeadings: separate instructions from data2 min▶
- The core move: give the task, the constraints, and the input material each their own # or ## heading. Long prompts become skimmable for you AND unambiguous for the model.
- A reusable skeleton: # Task → ## Constraints → ## Input → ## Output format. Adapt the names; keep the separation.
- Bonus: when you come back to a good prompt next month, the headings make it instantly reusable - prompts with structure become templates for free.
Self-studyFences: quote text exactly2 min▶
- The rule: anything you paste for the model to work ON - an email, code, an error message, meeting notes - goes inside a ``` fence. The fence draws a hard boundary: "this is data to process, not instructions to follow."
- Why it matters: unfenced, a pasted email that happens to contain the words "ignore the deadline" reads like part of your instructions. Fenced, it's clearly just the material.
- Exact means exact: fences also stop the chat from rendering the pasted text's own formatting, so the model receives every character as you pasted it - the Session 2 "show markdown without triggering it" trick, promoted to a safety habit.
Self-studyTables and lists: structured input in, structured output back2 min▶
- Lists for constraints: five rules in one paragraph get partially ignored; five rules as - bullets each get their own weight. Numbered lists when order or priority matters.
- Tables for records: feeding the model several items with the same fields (name, role, start date)? A Session 2 pipe table beats prose - every value sits in a labeled column.
- Ask for structure back: end with "answer as a markdown table with columns X, Y, Z" and the reply arrives ready to paste into your README, your notes, your docs.
That's the whole trick: the seven everyday elements from Session 1, plus fences and tables from Session 2. Prompting well is largely markdown applied with intent.
Instruction files: a README for your AI 5 min read
AI coding tools read a plain markdown file from your project - commonly named CLAUDE.md or AGENTS.md depending on the tool - and treat it as standing instructions. A README tells humans how the project works; an instruction file tells the AI. Same skill, new reader.
Self-studyWhat's inside one3 min▶
No schema, no special syntax - just markdown a machine happens to read. Headings group topics, bullets state rules:
The AI tool reads this file at the start of every session in the project. It now knows what the project is and follows your three rules without you repeating them in every prompt - standing instructions, written once.
- Short beats long: the best instruction files read like a good README section - a few headings, tight bullets, concrete rules. Walls of prose get skimmed by AIs too.
- It's version-controlled prose: the file lives in the repo, so your whole team (and their AI tools) share one set of rules, with history.
Self-studyThe pattern travels; the filename varies2 min▶
- Vendor-neutral core: different tools look for different filenames and support different extras, but every one of them reads plain markdown - headings, lists, links. Learn the pattern once and each tool's docs are a five-minute read.
- Check the docs, not your memory: filenames and lookup rules are tool-specific and change over time. When you adopt a tool, its official docs are the source of truth for what to name the file and where to put it.
- The bigger idea - docs as context: well-structured markdown docs (your README included) are exactly what AI tools digest best. Every clearly-headed, well-listed page you write is now documentation for humans AND context for machines. Structure pays twice.
Restructure one real prompt ◐ 10 min hands-on
Find a real prompt you actually sent an AI recently - ideally a long, blobby one that got a mediocre answer. Chat history is full of candidates.
Rewrite it with the skeleton: # Task for what you want, ## Constraints as a - list, and any pasted material inside a ``` fence under its own heading.
Send both versions in fresh chats and compare the answers side by side. Notice what the structured version got right that the blob missed - usually the constraints.
Keep the winner: save the structured version as a template in a notes file called prompts.md. You've just started a prompt library - in markdown, naturally.
Three questions before you go 🎯 ◐ 90 seconds
1 · Why wrap pasted text in a ``` fence inside a prompt?
The fence draws a hard line between your instructions and your data - and delivers the pasted text exactly, character for character.
2 · What is a CLAUDE.md or AGENTS.md file?
Just markdown - headings and bullets in a file the tool reads automatically. A README for humans, an instruction file for the AI.
3 · Why do AI chat answers appear with headings, lists, and code boxes?
Session 1's pipeline, running in every chat: text with markers in, processor converts, formatted page out.
What this page is based on
Honest label: unlike the four sessions, this page doesn't track one official syllabus - there isn't one for "markdown in AI work" yet. It's working practice built on the course's verified element set, plus the instruction-file pattern documented across AI coding tools' own docs, kept deliberately vendor-neutral.