Setting up your case folder

An AI session starts with no memory of your case. If it has no map, it grabs whichever file it finds first, and that may be an old draft. A clear folder and one instruction file fix this. They also keep your facts in one place, so your letters and filings never disagree with each other.

The shape of the folder

Here is a layout that works. Rename anything to suit you.

my-case/
  CLAUDE.md
  FACTS_OF_RECORD.md
  EVIDENCE_INDEX.md
  citation_log.md
  Their Production/
    _index/INDEX.md
    _extracted_verified/
  My Production/
  Recordings/
  Drafts/
    _archive/
  Correspondence/
  Case Law/
    verified/
      _MANIFEST.md

You do not need all of it on day one. Start with CLAUDE.md, FACTS_OF_RECORD.md, and citation_log.md. Add the rest as the case grows. The folder names here match the templates, so the prompts in Chapter 8 work without changes.

You do not have to create these files by hand. Start Claude Code in your case folder (Chapter 1) and ask it in plain words. For example, "Create CLAUDE.md, FACTS_OF_RECORD.md, and citation_log.md from these templates," then paste in the templates. Read each file it proposes before you approve it.

The instruction file and the read order

CLAUDE.md is a plain markdown file at the root of the folder. Claude Code loads it at the start of every session. Files load from the working directory and every parent directory, and they are combined, not overridden. You can use @path to import another file.

The docs make one caution. CLAUDE.md is context, not enforced configuration. The more specific and concise your instructions are, the more consistently Claude follows them. Type /context to see which files loaded. Type /memory to list your instruction files and open them.

Keep yours under about two pages. It should do six things.

1. Name the matter type, the forum, the claims, and the hearing window in a few lines.
2. Give a numbered read order, with one line of reason per item.
3. State which law governs and which courts to search first (Chapter 5).
4. State the citation rules.
5. List standing decisions as short headlines. Put the long reasoning in separate notes.
6. Describe the folder layout.

A sample read order looks like this.

1. FACTS_OF_RECORD.md. Read this first. It controls over every other file.
2. A folder map, if you keep one.
3. EVIDENCE_INDEX.md. Use it to find what proves a claim.
4. The other side's production index.
5. Working drafts. Mark these "not authoritative."

Mark every superseded file as superseded, both in the file and in the list. An old file that nobody labeled is how a settled mistake comes back.

A starter version is in the project instructions template. Copy it and fill it in. We do not repeat it here.

One facts file, and the rule that goes with it

FACTS_OF_RECORD.md holds every fact in your case. Number the paragraphs, so you can cite "Facts 3.2" in a draft. A good file covers the people, a dated chronology, an index of documents and recordings, a map from each claim to its evidence, your damages thinking, and a list of open contradictions.

The rule that makes it work is short. Update the facts file first. Then update everything that depends on it.

Here is how it plays out.

1. New evidence arrives, such as an email or a payroll record.
2. You add the fact to the facts file, with a pinpoint cite to the evidence.
3. Only then do you change the letter, the outline, or the brief that uses it.
4. You log the change at the bottom of the facts file with a date.

Without this rule, you end up with a chronology in a letter, a different one in a witness outline, and a third in a brief. They drift. The other side then quotes your own inconsistency back to you.

Add a "status of other files" table with three labels, such as current, research input only, and superseded. Any older data file should carry a header saying it must never be cited as a fact source. See the facts-of-record template for a starting point.

Tell the tool to stop and add a missing fact to the facts file before it uses that fact in a draft.

The evidence index

Build one table that ties each exhibit to its source file and to the claims it helps prove. Use at least four columns. An exhibit label, a source file, a claim tag, and a one-line description.

Keep the other side's production in its own folder (Their Production/). Give it a manifest that lists each document range, the type, and a short description. Store a verified text version of each produced document in one folder and treat it as the only citable text. If you later improve an extraction, move the old one to an archive folder and say in CLAUDE.md that it must not be cited.

This avoids two problems. You will not cite the wrong version of a document. You will also not quote from bad scanned text, where a garbled name ends up in a filing.

Before you tell the other side what you produced, check your production index. Do not infer it from the folder tree. The folder may hold more than you actually sent. The same habit applies to statements about what they did not produce. Search their whole production first, then write the narrowest true statement.

Pinpoint record cites

Every cite to a record document names the exact page. Never write a range such as "in the production."

Here is how to make that work.

• Make the extracted text carry a page marker line, so a search returns the page with the quote.
• Ask the tool to give the sentence and the page together in working drafts.
• Ask it to confirm the cited page says what your sentence claims, not just that the page exists nearby.

A range is fine only when a fact truly spans pages. Vague cites cost you time at the hearing, and they let a mischaracterization slip through.

Raw originals only

Use the raw original of a recording or transcript in anything you send. Never use a cleaned or edited version.

Keep cleaned files in a clearly named subfolder if you want them for convenience. Add one line to CLAUDE.md saying which version is citable and why. Then add a step to your drafting checklist that searches for the cleaned folder name. The mistake is easy to make. If a working file calls the cleaned version "authoritative," the error spreads into every outline built from it.

Keep only final versions

After a document is sent or filed, do this right away.

1. Save the as-sent text in Correspondence/.
2. Delete the working drafts.
3. Move drafts that were never used to Drafts/_archive/, and add a row to a small manifest there.

Parallel versions of the same paper cause errors. Quoting the wrong draft is a common one. If your folder is a local git repository, deleted drafts stay in history in case you need them.

The citation log

citation_log.md is the memory of which authorities are safe to use. The model forgets, and the file does not. Give it these sections.

• A verified list. Case name, cite, court, the exact pincites checked, the point it supports, the source used, a treatment verdict, and the date checked. Statutes and regulations get their own subsections, checked against the official text.
• A do-not-cite list, with a reason for each entry.
• An unverified list of leads from the web or from AI. Mark each "do not use."
• A hallucination log. Write down each time a fake or wrong cite was caught and how you caught it.

Make the rule absolute in CLAUDE.md. No case enters a draft unless it is on the verified list. Record verdicts with a date, because treatment changes over time. The citation log template has the full structure.

The verified-downloads folder and manifest

When you verify an opinion, save a copy of it. Put it in Case Law/verified/. Then add a row to _MANIFEST.md in the same folder.

1. Read the opinion and confirm the holding.
2. Save the text with a self-describing name. Use the short case name, the cite without spaces, the court and year, and the source.
3. Add one row to the manifest.
4. Search the saved file for the exact quote you plan to use, to confirm it is there.

The manifest columns are date retrieved, case name, cite, court, source and retrieval method, local filename, verified status, and the holding you use it for. Put this rule at the top. No case goes into a filing unless it is VERIFIED in this manifest with a saved copy.

A case is not done until it is saved and logged. Later, if anyone asks where a quote came from, you can show the file. See the download manifest template.

Chapter 6 walks through the full verification routine that fills this folder and the log.

Next: Chapter 4 covers skills, agents, and notes that carry these rules from session to session.