Context Is the Product

Prompt-craft is retyping your situation every session and hoping you phrase it well; context engineering is writing it down once and letting the machine reread it forever. This is the unit where the track clicks, because once the setup lives in a file, every session starts from your actual project instead of from zero. The file is boring. The compounding is not.

• Write a project context file that a terminal agent reads automatically every session.
• Build a reusable persona with persistent instructions and explain what it saves you.
• Ground a conversation in a corpus you own, and state what grounding does and does not prevent.
• Explain why a 1M-token context window changes what you can ask in a single conversation.

• @Drive — type it in any Gemini conversation and the model can search and pull from any file you own. Drive becomes queryable context rather than storage.
• A 1M+ token context window — enough to put an entire semester's reading into one conversation.
• Workspace extensions — @Gmail (summarise threads, extract action items, draft replies), @Drive (query PDFs, papers, datasets), @Docs / @Sheets (generate drafts, analyse data, build trackers).
• Gems — saved personas with persistent instructions. A "Stats Assistant" that always reaches for pandas and scikit-learn. A "Thesis Reviewer" that critiques writing for clarity and citation gaps.
• GEMINI.md — a file in your project root that gemini-cli reads every session: what libraries you use, your coding style, how your data is structured.

Context engineering is deciding what the model sees, when, and in what order, and it is a discipline, not a trick. The prompt evaporates when the session ends; the file is versioned, reviewable, and still working next month, which is why the file is the artifact.

The curriculum covers this across §2.3 (Structured Markdown: the format coding agents read best), §2.4 (Context engineering, the missing discipline), and §2.6 (The Claude Code playbook). The CLAUDE.md template at /templates/claude-md is the same artifact as a GEMINI.md — read it as the worked example.

Grounding is not the same as retrieval. /stacks/rag-knowledge-app shows what it looks like when you build the retrieval layer yourself, and why chunking and embeddings start to matter at corpus scale.

1. Create one Drive folder for a single research topic. Not a catch-all — one topic.
2. Drop in the papers, notes, and datasets for that topic.
3. Start a Gemini session with @Drive and the folder name, then ask: "Summarise the methodologies across these papers and identify gaps." Read the answer against a paper you already know well and note where it is thin.
4. Build a Gem. Give it standing instructions — for example, a "Thesis Reviewer" that critiques for clarity and citation gaps and never rewrites your argument for you.
5. In a project directory, write a GEMINI.md covering: what the project is, which libraries and versions, how the data is shaped, and what conventions you want followed.
6. Open a fresh session and confirm the agent behaves as if it already knows all of that. If it does not, the file is not specific enough.

A project GEMINI.md that survives a fresh session without you re-explaining anything, and one working Gem you would actually use again.

• What is the difference between a Gem's instructions and a context file, and when does each one apply?
• @Drive grounding means the model reads your files. Which files should never be in that folder?
• Your context file is 4,000 tokens. What did that cost you, and what did it buy?
• Grounding reduces one failure mode and leaves another intact. Which is which?