Context Engineering

Moderate · Technical & Agentic track · ~35 min hands-on + readings and quiz

← Back to the Technical & Agentic track

The quiet skill behind good AI output: structuring what the model sees.

What you’ll be able to do

  • Structure system prompts, instructions, and reference files
  • Decide what context to include — and what to leave out
  • Diagnose failures as context problems, not model problems

Overview

When AI drifts, the fix is usually better context, not a bigger model. Context engineering is choosing what the model sees: the role, the standing instructions, the reference files, the examples — and what to leave out so the signal isn’t buried.

More context is not always better. Too much dilutes attention; the skill is picking the few things that matter for the task.

Practice activities

Activity 1 · Moderate — Fix a drift with better context

Time ~15 min · Tools ChatGPT Edu or Claude

Goal. Improve output by improving context, not by writing a longer prompt.

Setup. You will experience the problem firsthand, then fix it with one example.

The scenario: You need to write monthly progress updates for an NIH R01 grant. They should be brief, factual, and structured — but when you prompt generically, the AI produces something bloated and off-tone.

Steps.

  1. Run the weak prompt and watch it drift:

    Write a monthly progress update for my NIH-funded study on pedestrian safety in Philadelphia.

    You’ll likely get something long, vague, and overly enthusiastic (“We are thrilled to report exciting progress…”) with no specific data and a structure that doesn’t match how you actually report.

  2. Now add a role, standing rules, and one concrete example:

    You are a research coordinator writing terse monthly updates for a PI. Rules: (1) No adjectives like “exciting” or “significant” — just state what happened. (2) Use past tense. (3) Under 120 words. (4) Three sections only: Completed, In Progress, Next Month.

    Example of the output I want:

    Completed: Geocoded 2,400 crash records from PennDOT 2022 file; linked to road-segment data. Submitted IRB continuing review (approved 6/28).
    In Progress: Missing speed-limit imputation — 31% of segments lack PennDOT values. Testing two approaches (nearest-neighbor vs. OSM).
    Next Month: Finalize speed-limit variable. Begin multilevel models for KSI outcome. Draft abstract for APHA.

    Now write July’s update. This month we finished the speed-limit imputation using nearest-neighbor, started the multilevel models, and learned that the 2023 PennDOT file has a new format that breaks our ingestion script.

  3. Compare the two outputs. The second should closely match your example’s tone, structure, and length. Notice that the single example — not extra paragraphs of instruction — carried the weight.

Expected result. The first output drifts (too long, wrong tone, vague). The second matches your example’s format and style. This is the core lesson: one sharp example beats paragraphs of description.

Check your work. Remove the example and re-run with only the rules — quality should drop, confirming the example was doing the work.

Common pitfalls. More text isn’t better context; instructions alone often aren’t enough. The example is the anchor.

Stretch (optional). Turn the working context (role + rules + example) into a reusable custom GPT or Claude skill for monthly updates.

Activity 2 · Moderate — Trim the context

Time ~12 min · Tools ChatGPT Edu or Claude

Goal. Cut noise so the signal lands.

Setup. A prompt with a lot of background.

Steps.

  1. Remove everything non-essential; keep only what the task needs.

  2. Re-run and confirm quality held or improved.

  3. Diagnose:

    What in my context is actually doing work here, and what’s noise?

Expected result. A leaner prompt with equal or better output.

Check your work. If cutting something degrades the output, it was signal — put it back.

Common pitfalls. Over-trimming removes needed constraints; iterate one cut at a time.

Stretch (optional). Build a minimal reusable context template for this task type.

Activity 3 · Moderate — Make context persistent with a CLAUDE.md file

Time ~20 min · Tools Claude Code (Low Risk Data only — not Drexel-supported; use fabricated details as in Activity 1)

Goal. Move the working context from Activity 1 out of the chat window and into a file that Claude reads automatically every session — no re-pasting.

Setup. In Activity 1, the role, rules, and example fixed the drift — but you had to paste them into every new chat. Claude Code reads a CLAUDE.md file in your project folder at the start of every session, so the same context can live in one place, permanently. Reminder: Claude Code is approved for Low Risk Data only; keep using the fabricated pedestrian-safety scenario.

Steps.

  1. Create a project folder (e.g., progress-updates) and inside it a file named CLAUDE.md containing the exact context from Activity 1:

    You are a research coordinator writing terse monthly updates for a PI. Rules: (1) No adjectives like “exciting” or “significant.” (2) Past tense. (3) Under 120 words. (4) Three sections only: Completed, In Progress, Next Month.

    Example: Completed: Geocoded 2,400 crash records… In Progress: Missing speed-limit imputation… Next Month: Finalize speed-limit variable…

  2. Open a terminal in that folder, start Claude Code, and give it only the new facts — no role, no rules:

    Write August’s update. [new fabricated facts]

    The output should match the tone, structure, and length from Activity 1, even though you pasted nothing.

  3. Quit, then start a fresh Claude Code session in the same folder and try September’s update with different fabricated facts. Same result — the standing context is applied automatically each time.

  4. Now run the drift test. Temporarily rename the file (e.g., CLAUDE.md → CLAUDE.md.bak), start another fresh session, and ask for October’s update. Watch it drift back toward the long, vague, enthusiastic output from Activity 1’s weak prompt.

  5. Rename the file back and confirm the next session snaps back into shape.

Expected result. With the file present, every new session produces on-spec updates with zero re-explaining; with it removed, the same request drifts generic.

Check your work. Delete just the example from CLAUDE.md, keep the rules, and re-run — quality should drop, exactly as in Activity 1’s check.

Common pitfalls. The file must be named CLAUDE.md and sit in the folder where you launch Claude Code — a session started elsewhere won’t see it. And persistence doesn’t change the classification: Low Risk Data only.

Stretch (optional). Add a second standing rule to the file (e.g., a required final line naming the reporting month) and verify it appears in every new session without being asked.

Check your readiness

Answer these, then check — your score suggests whether to dive in or skim the readings first.

Useful resources