title: "Exercises — Project Memory" last_updated: 2026-03-21 status: proven difficulty: beginner prerequisites: [01-your-first-hour]

Exercises: Project Memory

These exercises build your skill with CLAUDE.md and AGENTS.md through hands-on practice on your own project. Each exercise increases in scope, starting with a minimal configuration and ending with an iterative improvement workflow you will use throughout your agentic development practice.

Note: These exercises work with either Claude Code (CLAUDE.md) or Codex CLI (AGENTS.md). The instructions reference both — use whichever tool you have set up.

Exercise 1: The Starter Config

Objective: Create a minimal project memory file and observe its immediate impact on agent behavior.

Steps

  1. Open one of your own projects (not a toy example — use a real codebase you actively work on).

  2. Create a CLAUDE.md or AGENTS.md file in the project root with exactly five lines:

    # Project Instructions

## Project Overview

<!-- Replace this: one sentence describing your project, its tech stack, and its purpose. -->

  3. Start a new agent session and run three different tasks. Choose tasks that represent your typical workflow — for example:

    • "Add input validation to the user registration endpoint"
    • "Write unit tests for the cart total calculation"
    • "Refactor the dashboard component to extract the sidebar into its own file"

  4. For each task, note:

    • Did the agent use the right language and framework?
    • Did it place files in the correct directories?
    • Did it follow your project's naming conventions?
    • What did you have to correct?

  5. Write down the three corrections you made most often. These become candidates for your next config update.

Expected Outcome

Even a one-sentence project overview noticeably improves the agent's output — it will use the right framework, language, and general patterns. You will also have a concrete list of corrections to address in Exercise 2 and beyond.

Hints

  • If you are unsure what to write for your overview, answer this: "If a new developer asked what this project is, what would you say in one breath?"
  • Do not overthink the five lines. The point is to start small and observe the effect, not to write a perfect config on the first try.

Exercise 2: The Before/After Test

Objective: Measure the concrete impact of project memory by comparing agent output with and without configuration.

Steps

  1. Choose a single, well-defined coding task for your project. Pick something that involves your project's specific conventions — for example, adding a new API endpoint, creating a new React component, or writing a database migration. The task should take the agent 2-5 minutes.

  2. Run the task WITHOUT project memory. If you already have a CLAUDE.md or AGENTS.md, temporarily rename it:

    # Adapt this by: using the filename that matches your tool (CLAUDE.md or AGENTS.md).
mv CLAUDE.md CLAUDE.md.bak

    Start a fresh agent session and give the task. Save the output (copy the generated code to a file like output-before.txt).

  3. Restore and enhance your project memory. Rename the file back and add a detailed configuration. Include at minimum:

    • Project overview (1-2 sentences)
    • Architecture (4-6 key directories)
    • Conventions (3-5 rules)
    • Common tasks (build, test, lint commands)
    mv CLAUDE.md.bak CLAUDE.md

  4. Run the same task WITH project memory. Start a fresh session (important — do not reuse the old session) and give the exact same task prompt. Save this output to output-after.txt.

  5. Compare the results side by side. For each output, evaluate:

    • Correct file placement (right directory)?
    • Correct naming convention (matches your project)?
    • Correct patterns used (right libraries, right abstractions)?
    • Code style consistency (looks like it belongs in your codebase)?
    • Number of corrections needed before the code is merge-ready?

Expected Outcome

The "after" output should require significantly fewer corrections. Common improvements include: correct import style, right state management library, proper file naming, correct test patterns, and adherence to your project's architectural boundaries. If the difference is subtle, your conventions may be close to standard patterns — try a task that involves a project-specific pattern.

Hints

  • Use the exact same prompt for both runs. Even small wording changes can affect output.
  • If you want a quantitative measure, count the number of lines you would need to change in each output before committing.
  • The biggest improvements usually show up in convention adherence (naming, imports, file placement) rather than in raw correctness.

Exercise 3: The Convention Test

Objective: Verify that the agent reliably follows a specific convention from your project memory file.

Steps

  1. Choose a concrete, verifiable coding convention and add it to your CLAUDE.md or AGENTS.md. Pick something unambiguous that you can check by reading the code. Good examples:

    • "Always use arrow functions for React components"
    • "Never use abbreviations in variable names — use customerAddress, not custAddr"
    • "All Python functions must have type hints for parameters and return values"
    • "Use vi.fn() for mocks in tests, never jest.fn()"
    • "Always add JSDoc comments to exported functions"

    Add your chosen convention to the Conventions section:

    ## Conventions

- Always use arrow functions for React component definitions (e.g., `const MyComponent = () => { ... }`)

  2. Start a new agent session.

  3. Ask the agent to write code that would naturally involve your convention. For example, if your convention is about arrow functions for React components, ask it to create two or three new components. If it is about variable naming, ask it to write a function that handles several data objects.

  4. Inspect every instance in the output where the convention should apply. Check:

    • Did the agent follow the convention consistently?
    • Did it follow the convention in all instances, or only some?
    • Did it follow the convention without you mentioning it in the prompt?

  5. If the agent did not follow the convention, revise your wording. Common fixes:

    • Make the instruction more specific (before: "use good variable names"; after: "use full English words for variable names, never abbreviations")
    • Add an example of the correct pattern
    • Add an example of the incorrect pattern with "do NOT" prefix

  6. Repeat the test with the revised wording until the agent follows it reliably.

Expected Outcome

The agent should follow your convention in the majority of cases (80%+ compliance is realistic). If compliance is low, the issue is almost always that the instruction is too vague. Iterating on the wording is a core project memory skill — you are learning not just to configure the agent, but to write instructions that translate reliably into behavior.

Hints

  • Conventions that include a concrete example ("use const Foo = () => {}, not function Foo() {}") have higher compliance than abstract rules.
  • If the agent follows the convention 3 out of 4 times, the instruction is probably fine — occasional misses are normal. If it follows it 1 out of 4 times, the instruction needs rewriting.
  • Test one convention at a time. If you add five conventions at once, you will not know which one the agent is struggling with.

Exercise 4: The Progressive Build

Objective: Build a high-quality project memory file over five sessions using the iterative approach from the concepts module.

Steps

This exercise spans five separate agent sessions over one to two weeks. Do not try to complete it in a single sitting.

Session 1: Baseline

  1. Start with a minimal CLAUDE.md or AGENTS.md (5-10 lines — your project overview and one or two conventions).
  2. Use the agent for a real task on your project.
  3. After the session, write down every correction you made. Pick the single most impactful one.
  4. Add that correction as a new instruction in your config.

Session 2: First Iteration

  1. Start a new session with your updated config.
  2. Use the agent for a different real task.
  3. Note: did the agent avoid the mistake from Session 1? (It should.)
  4. Write down new corrections. Add the most impactful one to your config.

Session 3: Architecture Pass

  1. By now, you likely have a feel for what the agent gets right and wrong about your project's structure. Add an Architecture section with your key directories if you have not already.
  2. Use the agent for a task that involves navigating multiple parts of the codebase.
  3. Note corrections. Add the most impactful one to your config.

Session 4: Anti-Patterns Pass

  1. Review your accumulated corrections. Are there any "do NOT" instructions that would have prevented multiple mistakes? Add a What NOT to Do section.
  2. Use the agent for a task that might trigger one of your anti-patterns.
  3. Note whether the anti-pattern instructions prevented the mistake.

Session 5: Pruning

  1. Read your config file end to end. Are there instructions that are redundant, too vague, or not earning their token cost?
  2. Remove or consolidate any low-value instructions.
  3. Use the agent for your most common type of task. Evaluate the overall quality of the output.
  4. Compare: how does the agent's output in Session 5 compare to Session 1?

Tracking: After each session, record these metrics in a simple log:

<!-- Adapt this by: replacing with your actual observations after each session. -->
| Session | Config Lines | Task | Corrections Needed | New Instruction Added |
|---------|-------------|------|--------------------|-----------------------|
| 1       | 5           |      |                    |                       |
| 2       |             |      |                    |                       |
| 3       |             |      |                    |                       |
| 4       |             |      |                    |                       |
| 5       |             |      |                    |                       |

Expected Outcome

By Session 5, you should see a measurable reduction in corrections per session. A typical trajectory: Session 1 requires 5-8 corrections; Session 5 requires 1-2. Your config file should be 20-40 lines — detailed enough to be effective, concise enough to not waste context window space. You will also have internalized the iterative improvement loop: use, observe, add, prune.

Hints

  • Real sessions only. Do not invent fake tasks for this exercise. The value comes from discovering what your specific project needs, which you can only learn from actual work.
  • One instruction per session keeps the signal clear. If you add five instructions at once, you cannot tell which one helped.
  • The pruning session (Session 5) is the most important. The goal is not a long config file — it is an effective one. A 25-line file with high-impact instructions beats a 75-line file with filler.
  • If you share the project with teammates, ask them to try the same exercise. Their corrections will be different from yours, and combining perspectives produces a stronger config.