Chapter 12: Long-Range Projects with Memory Systems#

What It Is#

Some projects are not one-session tasks. They span weeks or months, involve multiple phases, accumulate decisions and context, and require maintaining continuity across dozens of separate Claude Code sessions. This chapter covers the strategies, systems, and discipline needed to manage these long-range projects effectively.

This is where everything in the playbook comes together — working directory discipline, CLAUDE.md memory systems, plan mode for complex decisions, proper instruction quality, and the full plugin stack.

Why It Matters for Non-Technical Professionals#

Most significant professional work is long-range. A research report takes weeks. A website evolves over months. A content strategy spans quarters. A product launch involves dozens of workstreams over many sessions.

The challenge with AI tools is that they are inherently session-based. Every conversation starts fresh. Without deliberate systems for maintaining context, long-range projects with Claude Code devolve into frustration — you spend the first ten minutes of every session re-establishing context that Claude has forgotten.

The professionals who get the most value from Claude Code are those who master long-range project management. They build memory systems that persist. They structure their projects so context survives session boundaries. They use the right tools at each phase — plan mode for research, execution mode for action, compact for context management.

What You Need#

A dedicated project directory for every serious project. Not a subfolder of another project. A top-level folder that becomes the working directory for all sessions related to this project.

A comprehensive CLAUDE.md that evolves with the project (see Chapter 3).

A memory directory for supplementary context files.

Discipline around session management — starting sessions from the right directory, updating memory at the end of sessions, using /compact during long sessions.

The Framework: How Long-Range Projects Work#

Phase 1: Project Setup#

Before any work begins, establish the project structure:

In your terminal:

cd ~/Desktop
mkdir My-Research-Project
cd My-Research-Project
claude

First session instructions:

As a Claude prompt:

We are starting a new multi-week project: [describe the project].

Set up the following project structure:
1. Create a CLAUDE.md with:
   - Project overview and goals
   - Key stakeholders and their roles
   - Expected deliverables
   - Any constraints or rules
2. Create a /data/ folder for raw inputs
3. Create a /output/ folder for deliverables
4. Create a /memory/ folder for supplementary context files
5. Create a README.md documenting the project structure

Phase 2: Working Sessions#

Each working session follows a rhythm:

1. Start from the project directory: cd ~/Desktop/My-Research-Project && claude
2. Claude loads the CLAUDE.md automatically — it knows the project context
3. Give task instructions for this session’s work
4. Use /compact if the session runs long
5. Update CLAUDE.md at the end of the session if significant decisions were made

Phase 3: Context Preservation#

The key discipline: after any session that involves important decisions, update the memory system.

As a Claude prompt:

Update the CLAUDE.md with these changes:
- Decision: We are excluding [data subset] because [reason]
- Progress: Section 3 first draft is complete
- New rule: All data tables should include source citations

Or use the claude-md-management plugin:

Inside Claude Code:

/claude-md-management:revise-claude-md

This prompts Claude to review the current session’s work and suggest updates to the CLAUDE.md.

A Real Case Study: Multi-Month Survey Research Report#

The most extensive long-range project I have managed with Claude Code was a multi-month research report based on survey data from over 180 professionals across five executive personas.

The project scope: - 180+ survey respondents - Five executive personas (CEO, CTO, CMO, CPO, Other C-Suite) - Data cleaning, dashboard creation, and report writing - Multiple stakeholders providing feedback - Dozens of editorial decisions accumulated over time

How the memory system evolved:

Week 1: The CLAUDE.md was basic — project overview, respondent counts, initial data format notes.

Week 2: After data cleaning decisions (merging small persona groups, handling edge cases), the CLAUDE.md grew to include a “Key Decisions” section with specific choices and their rationale.

Week 3: After the first report sections were written, the CLAUDE.md added writing progress tracking, corrected data points (after finding and fixing errors in initial analysis), and workflow rules (like “always present insights for approval before writing final copy”).

Week 4 and beyond: The CLAUDE.md became the project’s institutional memory — over a hundred lines covering corrected statistics, editorial decisions per section, tone rules, data integrity protocols (after catching a data error), and a complete progress tracker.

The supplementary memory files: - session-context-detailed.md — Column mappings, file locations, data transformation steps - ceo-section-plan.md — Approved structure and data points for the CEO section - cto-section-plan.md — Same for CTO

What I learned:

1. CLAUDE.md is the project’s source of truth. Every important decision goes in the CLAUDE.md. If it is not in the CLAUDE.md, it does not persist.

2. Data errors require hard rules. After Claude once fabricated a data point from memory (after a long session where context had degraded), I added a hard rule to the CLAUDE.md: “NEVER reconstruct numbers from memory. Always re-read source data.” This rule prevented the same mistake from happening again.

3. Section-by-section approval prevents compounding errors. By having Claude present each insight for approval before writing final copy, I caught framing issues early instead of discovering them in a completed section.

4. Guidelines files complement the CLAUDE.md. For complex writing projects, a separate GUIDELINES.md with detailed writing rules (tone, formatting, style, citation practices) keeps the CLAUDE.md focused on project status while the guidelines handle craft.

Multi-Session Discipline#

Naming sessions: While Claude Code does not have explicit session naming, you can start each session with a brief orienting instruction: “We are continuing work on the CTO section of the research report. Last session we completed the data analysis. Today we write the section.” This helps Claude orient within the project even beyond what the CLAUDE.md provides.

Using /compact proactively: Do not wait until Claude starts forgetting things. If you have been working for thirty-plus exchanges, use /compact. The critical context is preserved in your CLAUDE.md and memory files; the conversation details can be compressed.

Ending sessions cleanly: Before closing a session, ask: “Is there anything from this session that should be added to our CLAUDE.md or memory files?” This simple habit ensures context accumulates rather than evaporates.

Pro Tips#

Tip 1: One project, one directory, one CLAUDE.md. Never try to manage two long-range projects from the same working directory. The CLAUDE.md contexts will conflict and Claude will confuse the projects.

Tip 2: Update CLAUDE.md immediately after important decisions. Do not plan to do it later. The best time to capture a decision is the moment it is made, when the full context is fresh.

Tip 3: Use the Research-Plan-Execute framework for each phase. When moving from one major phase to another (e.g., from data analysis to report writing), do not just jump into execution. Apply the Research-Plan-Execute framework from Chapter 4: have Claude update the RESEARCH.md with findings from the completed phase, create a phase-specific PLAN.md with checkboxes, annotate it with your corrections, and only then execute. For long-range projects, this discipline at each phase transition is what prevents drift — the slow accumulation of small misalignments that compound into major rework.

Tip 4: Keep corrected data points in CLAUDE.md. If Claude ever gets a number wrong and you correct it, add the correct number to the CLAUDE.md. This prevents the same error from recurring in future sessions.

Tip 5: Regular CLAUDE.md reviews. Every few sessions, read through your CLAUDE.md and remove outdated information. A lean, accurate CLAUDE.md is more useful than a long, partially stale one.

Tip 6: Compaction documents for context continuity. When a conversation is about to auto-compact (you will see a warning that context is getting full), or when you are about to end a session during complex work, create a “compaction document” — a detailed snapshot of what has been done, what is pending, what decisions were made, and what the next steps are. Save it to your project directory. In your next session, Claude can read this document and resume exactly where you left off with full context.

Here is a template for a compaction document:

Example session handoff document:

# Session Handoff Document — [Date]

## What Was Done
- [List of completed tasks with specific details]

## Decisions Made
- [Each decision and its rationale]

## Current State
- [Files created or modified]
- [Any data or analysis results]

## Pending Tasks
- [What still needs to be done, in priority order]

## Gaps and Open Questions
- [Things that need clarification or further research]

## Key File References
- [File paths to important project files]

## Next Steps
1. [Specific next action]
2. [Second action]

This is a technique I discovered after working on a 25,000+ word writing project that required multiple sessions. The compaction document became the bridge between sessions, ensuring that nothing was lost when context was compressed or when I returned the next day.

When Projects Span Multiple Months#

For projects that run longer than a few weeks, additional strategies become important:

Version your CLAUDE.md. Periodically copy your CLAUDE.md to a timestamped backup (CLAUDE-2025-12-15.md). This creates a history of how your project evolved, and if the current CLAUDE.md ever gets corrupted or needs rollback, you have snapshots.

Use a CHECKLIST.md for multi-deliverable projects. When a project has many distinct outputs (a report with 8 sections, a website with 12 pages), create a separate CHECKLIST.md that tracks the status of each deliverable. The CLAUDE.md handles context and rules; the CHECKLIST.md handles progress.

Create a GUIDELINES.md for craft-heavy projects. For writing projects, design projects, or any project where quality standards matter, a separate GUIDELINES.md with detailed rules (tone, formatting, style, citation practices, design principles) keeps craft guidance separated from project logistics. Claude reads both files and applies both sets of rules.

Build a living reference in your memory directory. As a project progresses, save analysis outputs, approved plans, and intermediate research to your /memory/ directory. Name files descriptively (ceo-section-approved-plan.md, data-analysis-output-q4.md). These files become the authoritative references that Claude consults when it needs specific data or context for the current task.

The Third Memory Layer: Memory That Writes Itself#

Notice the ladder this chapter has been climbing. CLAUDE.md is memory you curate — you decide what goes in it. Handoff and compaction documents are memory you write at the end of a session — a deliberate snapshot before you close. There is a third layer, and it asks nothing of you: memory that writes itself.

The claude-mem plugin quietly observes your sessions, compresses what happened into searchable observations, and injects the relevant pieces into future sessions automatically. You do not summarize anything — it watches, remembers, and hands the context back when it is useful. You can also search it directly (“did we already solve this?”) and get an answer from work you did weeks ago.

I run it. It has already saved me the “wait, we solved this last month” hunt more than once.

Be honest about what it is: heavier than a single skill. It installs hooks and a small database, so it is doing real work in the background. The beginner move is to install it and forget it — let it compound quietly rather than fiddle with it.

Inside Claude Code:

/plugin marketplace add thedotmack/claude-mem
/plugin install claude-mem

Then restart Claude Code. Context from previous sessions starts appearing automatically — you will notice it before you think to look for it.

Case Study 2: From Idea to Viral Product — The Indian Rishta Standards Calculator#

The survey research project above is a story of long-range depth. This second case study is a story of long-range breadth — taking a single idea from initial research through design, development, deployment, viral distribution features, analytics infrastructure, user data analysis, and ongoing iteration across over a hundred interactions.

The origin: I discovered a dating compatibility calculator by a US platform called Keeper, which used US Census Bureau and CDC data to estimate what percentage of the population matches a user’s partner preferences. It had gone viral. I wanted to build an India-specific equivalent — same concept, different data sources, different cultural context.

Phase 1 — Research and Data Foundation (Sessions 1–2)

The first step was not building — it was understanding. I had Claude research the original calculator thoroughly: how it works, what data sources it uses, how it handles probability calculations, and why it went viral. Then I shifted to finding equivalent Indian data sources.

As a Claude prompt:

Research this calculator by the US dating platform Keeper:
https://www.keeper.ai/calc

Understand how it works — data sources, calculation methodology,
design patterns, viral distribution features. Then identify
equivalent Indian data sources for: age distribution, height
distribution, income brackets, religion demographics, education
levels, dietary preferences, marital status.

Save your findings to research files in the project directory.

Claude identified sources from the Indian Census, the National Family Health Survey (NFHS), and other government datasets. The research phase produced structured markdown files that became the reference for all subsequent development.

Phase 2 — Design and Initial Build (Sessions 3–5)

With the data foundation in place, I used the frontend-design plugin to design the calculator. The design direction was intentional: “funky and joyful” — this was a playful tool, not a serious demographic analyzer.

As a Claude prompt:

Use the frontend-design skill to design the calculator. We should
not have caste or hair/eye color filters — those do not apply to
the Indian context. Give it a catchy title.

Design direction: playful, joyful color scheme. Not corporate.
The website should feel like something you would share with
friends. All filter inputs and the result should fit in one
desktop viewport without scrolling.

The iteration on design was extensive. Over the first few sessions, I went through multiple color scheme explorations (the first version looked too much like the original Keeper, so I asked for something distinct), filter panel layouts (checkboxes vs dropdowns, single-column vs two-column), and result card designs.

Phase 3 — Viral Distribution Features (Sessions 6–10)

This is where the project transitioned from “personal experiment” to “product thinking.” Every feature added in this phase was designed for sharing.

• Shareable URLs: Each result generates a unique URL that encodes the user’s selected filters. When shared, the recipient sees the same result without needing to re-enter criteria.
• WhatsApp sharing: A share button that generates a pre-formatted WhatsApp message with the result and a link. In India, WhatsApp is the primary sharing channel — this was critical.
• “How Rare Are You?” rarity score: After seeing their match percentage, users could discover how rare their specific combination of preferences is. This added a second viral loop — people wanted to share their rarity score as much as their match percentage.

As a Claude prompt:

Add shareable URL functionality. Encode the selected filters into
URL parameters so results can be shared directly. Implement a
WhatsApp sharing button — pre-format the message with the
percentage result and the absolute number of matching people.
Also add a "Copy Link" button labeled "Share Your Results."

Phase 4 — Analytics Infrastructure with Google Sheets (Sessions 11–15)

Here is a technique that deserves special attention: using Google Sheets as a free analytics backend.

The calculator runs entirely in the browser — there is no server, no database. But I wanted to track usage: what filters people select, what combinations are popular, where users come from. The solution: Google Apps Script as a lightweight API that writes to a Google Sheet.

As a Claude prompt:

I need analytics tracking for this calculator. The calculation
happens in the browser. Set up a system where each calculation
sends the selected filter values to a Google Sheet via Google
Apps Script. I want to capture: all filter selections, the
calculated result percentage, timestamp, and referrer source.

The Google Sheet becomes my analytics dashboard. Here is the
Apps Script endpoint URL: [endpoint URL]

Claude wrote the JavaScript to POST data to the Apps Script endpoint on each calculation. The Google Sheet captures every calculation — filter combinations, results, timestamps, whether the user arrived via a shared link, and their approximate location (from timezone, not GPS). No database costs, no server maintenance, no privacy concerns beyond what users voluntarily input.

I later added user demographic capture through an optional popup: before seeing their result, users could share their own age, city, and gender. This data, also flowing to Google Sheets, enabled the analysis in Phase 6.

Phase 5 — Mobile Optimization and Polish (Sessions 16–25)

Mobile was where most users would experience the calculator — shared via WhatsApp, opened on phones. The mobile optimization phase involved:

• Complete responsive redesign of the filter panel (vertical stacking on small screens, touch-friendly input sizes)
• “Start Over” button that scrolls to top of page (not middle)
• Auto-focus on the first critical question after page load (many users were accidentally skipping it)
• Adjusting font sizes, button sizes, and spacing for thumb-friendly interaction
• Adding a golden highlight to the “looking for” question to prevent users from accidentally selecting the wrong gender

Phase 6 — User Data Analysis (Sessions 26–30)

After a week of live usage, I had enough data in Google Sheets to analyze real user behavior. This is where the project came full circle — using Claude Code’s data analysis capabilities (Chapter 6) on data generated by a product I built with Claude Code.

As a Claude prompt:

Analyze the calculator usage data from this Google Sheet export.
I want to understand: what are the median requirements by age
group? Use these age brackets: 18-24, 25-30, 31-35, 36+. Present
income, education, height, and dietary preferences for each
group. Create clean summary tables.

The analysis revealed genuine demographic insights about Indian partner preferences by age group — what income level different age groups consider acceptable, how education preferences vary, how dietary requirements shift. These insights became content for social posts about the calculator itself.

The result: The Indian Rishta Standards Calculator has been used by over 8,000 people. It was built entirely through Claude Code — from research through design through deployment through analytics — across roughly a hundred interactions spanning several weeks. No code was written by hand. The total investment: my time giving instructions and making product decisions.

What this project teaches about long-range AI-assisted development:

1. Start with research, not building. The first two sessions were pure research. Understanding the original product and identifying Indian data sources saved enormous rework later.

2. Design for distribution from the start. The viral features (shareable URLs, WhatsApp sharing, rarity scores) were not afterthoughts — they were planned in the early sessions and integrated into the design language.

3. Google Sheets as a free backend is genuinely powerful. For any browser-based tool, calculator, or interactive page, Google Apps Script + Sheets provides analytics, user data capture, and basic CRM functionality at zero cost. This pattern is reusable for any project.

4. Mobile-first is not optional. For any consumer-facing product, expect 70%+ mobile traffic. Budget significant iteration time for mobile optimization.

5. Your AI-built product generates data for your AI-powered analysis. The full loop — build with Claude, collect data, analyze with Claude, create content with Claude about the analysis — is a self-reinforcing cycle.