By the end of Foundations you could drive an agent. You built with it, put checkpoints under your work, and replayed a workflow someone else had saved. The building ran on your own product; the deep thinking ran on Tempo, the practice company, because practice material is safe to be wrong on.
This is where it becomes yours, in one sitting and three moves: a context file in your words, your own data within reach, and one routine saved as a skill. Together they are a marketing brain. I make the longer case for building it this way in the Build Log.
Write your context file
Yours follows the same four sections the context lesson taught: positioning, voice, customer, constraints. Under 40 lines, in your wording.
The agent is a decent interviewer when you tell it to be one. Open a session in the project folder from the course, the one holding your page and the tempo folder, or a fresh one if you are starting clean at work. Whichever you choose, that folder is where your file lives from now on. Hand it the job.
Assignment: let the agent interview you
Ten questions or fewer, one at a time. Push back when a summary is not quite you; the file comes out in your wording.
Create my context file. Use the filename your tool reads
automatically (CLAUDE.md for Claude Code, AGENTS.md for Codex,
GEMINI.md for Gemini, or the Cursor rules file). Interview me first,
one question at a time, ten questions or fewer, covering four
areas: what we sell, who buys it, how we sound, and the calls
we have already made that must not be reopened. Push for
specifics. When my answer is vague, ask for a real example.
Then write the file: under 40 lines, four sections titled
Positioning, Voice, Customer, Constraints, using my wording
wherever you can. Finish by listing what is still thin, so I
know what to add later.
Answer the way you would brief a freelancer you trust, with real answers, not aspirational ones. The interview is where the file gets its edge, and the skeleton is just where the answers land.
When it is written, read every line and delete anything you would not stand behind. The judgment in it has to be yours. The 40-line budget is for this first draft; it grows toward the context lesson’s 200-line ceiling as real work feeds it.
Wire in your data
The data lesson gave you the map; now walk one real road. Pick the single tool you would feel every week, your analytics, your CMS, or a sheet your team lives in, and connect that one first. One tool wired properly this sitting beats five planned.
Assignment: connect your first tool
Swap the bracket for your tool. Ask for read-only on purpose: a session gone sideways can then look at everything and touch nothing.
I want to connect [tool] so you can read from it. If this project has no .env yet, set one up first with a named placeholder for the key, and make sure .env is listed in .gitignore. Check whether an official connector exists for this tool and tell me if that is the better route. Otherwise, tell me exactly where in [tool] I create a key with read-only access and what to name it. I will paste it into .env myself. Once it is in, run one small read, last week’s headline numbers or the latest entries, and show me what you got.
The value went from the tool, through the file, into the call, and the chat only ever saw the name. Repeat the same move for the next tool the day a task actually needs it, rather than wiring the whole stack up front.
Save your first skill
Somewhere in your week is an instruction you have already given twice: the report you assemble every Monday, the brief you reformat for every launch. Turning it into a skill is the same file you read in the systems lesson, written in reverse.
Assignment: turn one of your own routines into a skill
Fill in the bracket with a job you repeat most weeks, then paste. Expect questions before any file gets written.
I keep doing this by hand: [describe the routine in your own words].
Turn it into a skill. First interview me: the exact steps, what a good
result looks like, and the mistakes you tend to make on this kind of
task. Then create a new skill folder and save it as, for example,
.claude/skills/weekly-report/SKILL.md for Claude Code or
.agents/skills/weekly-report/SKILL.md for Codex, with a clear
description of when to use it, and flag anything still thin so I
can fill it in.
Push back until it sounds like you. What comes out is a skill shaped to your workflow, the only shape that earns its place. When it misfires later, edit the instruction it ignored, or add the mistake to the file, and the fix holds for every run after.
Keep the brain honest
Whatever you wrote today is a first draft, and it is meant to be. The file earns its value in the weeks after, because real work keeps teaching you what belongs in it. The agent makes the same mistake twice, and the correction becomes a line. A draft comes back sounding off, and the voice section gains the rule that would have caught it. You take on a new kind of task, and a new constraint appears.
Every so often the agent sails past a rule that is sitting right there in the file. When that happens, move the line higher, make the wording blunter, or state the rule in two places.
Two habits keep the file true as it grows. Prune on sight: the day a line stops being true, or a call changes, the file changes with it. A stale constraint misleads with more authority than a missing one. And keep the bar high: if you would not repeat it to a capable freelancer in their first week, it does not belong in the always-loaded file.
The heavier files I run on client work are the same shell as the one you just wrote, months older and better fed. If I had to keep one piece of this setup, I would keep the file. I think it ends up the most valuable marketing document you own, because it is the only one that sharpens with use.
The setup is complete. What comes next: