AI Learning Series · Lesson 2 of 4
The gap between a vague ask and a well-formed one is often bigger than the gap between two models. A prompt isn't a wish — it's a spec: a goal, the context it depends on, the constraints it must respect, and the check it has to pass.
Status: outline. The on-screen walkthrough hasn't been recorded yet — this post is the plan it will follow, and it gets the real walkthrough once the lesson airs.
| Lesson | Focus | Question it answers |
|---|---|---|
| 1 — Model Usage | Model tier, context, tokens | Which model does this task need? |
| 2 — Prompting, Project, and Context | Prompt structure, standing context | What goes in front of the model? |
| 3 — Documentation, Rules, and Skills | Repository structure | How does a repo stay consistent across sessions? |
| 4 — Cutting Cost | Measurement, levers, guardrails | How do you spend less without losing quality? |
What You'll Be Able to Do
- Turn a vague request into a prompt that holds up
- State how the result will be checked, so the model can check itself
- Set up a project so every session starts already knowing the work — no re-explaining
Builds on lesson 1: which model, how much context, and roughly what it costs. This lesson decides what goes into that context.
Out of scope here: rules files, skills, and repository documentation structure (lesson 3), and cutting spend (lesson 4). "Project" in this lesson means the standing context you hand a model, not a full repository setup.
The Prompt
Same Model, Two Prompts — The Baseline
- One real task from this project runs through two prompts on the same model, side by side
- The point isn't that prompting is magic — it's that the prompt is often the bigger variable
Prompt Anatomy — Five Parts
- Goal — what you want, in one sentence
- Context — the files or sections it depends on, quoted rather than paraphrased from memory
- Constraints — what must not change, and which conventions apply
- Output — format, length, and where it goes
- Done when — the check the result must pass
▶ show code▼ hide code
# Vague
Hide the lesson posts from the homepage.
# Structured
Goal: Hide posts marked `homepageExcluded: true` from the homepage
list, but keep them on /blog.
Context: src/lib/blog.ts — getListedPosts() and getHomepagePosts()
Constraints: Don't change getAllPosts(). `unlisted: true` still hides a
post from both lists.
Output: A minimal diff, no unrelated refactors.
Done when: Tests pass, and the homepage no longer lists the lessons
while /blog still does.
Acceptance Criteria — Say How It'll Be Checked
- Criteria and examples give the model something to verify its own output against
- The same task runs with and without stated criteria — and each output gets checked against them
Iterate on the Prompt, Not the Output
- When a run fails, the instinct is to patch the output by hand — resist it
- Diagnose why the prompt missed, fix the prompt, and rerun
- Know when to abandon a conversation and start fresh instead of correcting it turn after turn
The Project
Standing Context vs. Single Prompt
| Put it in… | When it's true | Example |
|---|---|---|
| Standing project context | Every session | Stack, conventions, "never edit src/components/ui/" |
| A single prompt | This task only | The goal, the files involved, the acceptance check |
- On screen: a project gets set up, and one instruction moves out of a prompt and into standing context — then the difference gets shown
Context — Deliberate, Not Exhaustive
- Send the relevant files, not everything
- Quote the actual source instead of describing it from memory
- On screen: a long file pasted whole vs. only the relevant section, compared on output and token cost
The Prompt Checklist
▶ show code▼ hide code
# Prompt Checklist — before you send
1. Goal stated in one sentence?
2. Context quoted from source, not paraphrased?
3. Constraints: what must not change?
4. Output format and destination stated?
5. "Done when" — a check the result can actually fail?
6. Anything here true for every session? Move it to project context.
7. Run failed? Fix the prompt, then rerun — don't hand-patch the output.
Verify Before You Rely On It
This lesson names no specific product features, limits, or prices. Before it records, each of these gets checked against current provider documentation:
- What the demonstrated tool calls its standing-context feature, and what it can hold
- Size limits on attached files or project knowledge in that tool
- Whether the model behaves differently with extended reasoning on or off
- Whether anything here contradicts the provider's own current prompting guide
Common Questions
"Isn't a longer prompt always better?" No. A longer prompt with the wrong context is worse than a short one with the right context. Structure beats length.
"When should I start a new conversation?" When you've corrected the same misunderstanding twice. Fix the prompt, then start clean.
"What belongs in project context?" Anything true in every session — the stack, the conventions, the don'ts. Anything true for one task stays in the prompt.
Next: Lesson 3
A project with good standing context works — until the unit of work is a whole repository. Lesson 3 splits that context into documentation, rules, and skills, so an AI assistant stops drifting from its own conventions every fresh session.