Build the project memory

Step 1: Read the project memory template

Open materials/project-memory-template.md. This is a format guide showing what good project memory entries look like versus vague ones.

The difference matters. A vague entry like "follow dbt best practices" gives AI nothing actionable. A specific entry like "staging models use stg_ prefix, e.g., stg_mill1_daily" constrains AI's output in exactly the right way.

The template covers two files:

• CLAUDE.md -- Claude Code's project memory. Loads automatically at session start. Supports ancestor hierarchy, path-scoped rules, and auto-memory.
• AGENTS.md -- the cross-platform standard. Any compliant agent can read it. What transfers when the tool changes.

Both files capture the same project constraints. CLAUDE.md uses tool-specific features. AGENTS.md captures the universal version. Writing both is not duplication -- it is infrastructure that works regardless of which tool you use.

Step 2: Write CLAUDE.md

Create a CLAUDE.md file in the project root. This is the project memory file that Claude Code reads at the start of every session.

Capture what you know so far:

• Project context. Kyaw Zin Oo, Golden Ayeyarwady Rice Mill, two mills in Pathein, 200 tonnes daily, morning reports needed.
• Data dictionary. Source field names from both mills with the mapping. Mill 1 uses farmer_name, paddy_weight_kg, moisture_pct, grade, price_mmk, mill_date. Mill 2 uses supplier_name, weight_kg, moisture_percent, harvest_quality, payment_amount, processing_date. Map them to unified names.
• dbt naming conventions. stg_ for staging, int_ for intermediate, fct_ for facts, dim_ for dimensions.
• Known quality issues. Corrections arrive as complete re-exports of a day's data. Advance payments have null weight and quality fields. The two mills use different formats (CSV vs JSON) and different field names.
• Schema decisions. Leave this section with placeholders -- it will grow as you make decisions in later units.

Be specific. Every entry should be something AI can act on directly. "Mill 1 farmer_name maps to Mill 2 supplier_name, unified as farmer_name" is useful. "Handle data from both mills" is not.

Step 3: Write AGENTS.md

Create AGENTS.md alongside CLAUDE.md. Same constraints, universal format.

The cross-platform standard does not have Claude Code's path-scoping or ancestor hierarchy. What it does have is portability. If you move to a different AI tool next month, AGENTS.md carries the project context forward.

Capture the same information: project context, data dictionary, naming conventions, known quality issues. The entries should be specific and testable in both files.

Step 4: Run the before/after contrast

This is the proof that project memory changes outcomes.

Start a fresh AI session without the project memory loaded. Ask AI to generate a staging model for Mill 1 data. Note what it produces -- the column names it invents, the naming convention it chooses, whether it has any awareness of the correction pattern.

Then start a session with the project memory loaded. Ask the same question. Compare the output.

The session without project memory will likely use generic column names, miss the correction re-export pattern entirely, and pick a model name that does not follow your conventions. The session with project memory will follow the naming conventions from CLAUDE.md, use the correct field names from the data dictionary, and reference the known quality issues.

The difference is not subtle. It is the difference between directing AI with infrastructure and directing AI cold.