Home

The Complete Guide to Giving Claude a Persistent Identity

Stop re-explaining yourself. Build a workspace that gets sharper every week.

Claude starts every session from zero. A small set of markdown files, wired in the right place, fixes that.

This guide combines two sources: Sean Filiatrault’s UX Collective article on the “identity layer” idea, and a detailed Cowork setup playbook that covers the practical mechanics. I’ve retold both in my own words, reconciled where they differ, and added templates, prompts, and troubleshooting.

How to use this guide

Contents

  1. The problem: the re-explaining tax
  2. The idea: an identity layer
  3. The workspace layout
  4. Setup, step by step
  5. Templates for every file
  6. How to run the setup with Claude
  7. Wiring identity into projects and testing it
  8. Keeping it alive: maintenance and self-improvement
  9. Optional extras: Playbooks, Templates, Reference, sync
  10. Common gotchas
  11. Adapting this beyond Cowork and beyond design
  12. Final checklist

1. The problem: the re-explaining tax

You open a new chat and spend the first few minutes on the same preamble as always: who you are, how you like feedback delivered, what your writing sounds like, which mistakes to avoid.

Filiatrault calls this a tax. He had switched to Claude and found the sessions better, but for the first month or so he kept paying it at the start of every conversation. He had already done the sensible thing: one Cowork project per design stream, each with product context, team context, and expectations for Claude as a collaborator.

That helped with the project but not with him. His voice, his principles, how he runs a critique, feedback he’d already given last week: none of it carried over. A decision worked out in one project never reached another. A clarification that cost ten minutes in one session vanished by the next.

His first response was the one most of us have: tighten the instructions. Then tighten them again. The result was marginally better, and the correction loop never went away.

The realization that matters:

The problem wasn’t the prompting. It was structural.

Why better prompts can’t fix it

Every session, Claude starts with a blank slate apart from whatever is placed in front of it. Project instructions describe the work. Nothing in that setup describes you.

The gap is small at first and widens with use, and it widens fastest for people who treat AI as a thinking partner rather than a search box. Prompts are written per task. What’s missing is something written per person that loads everywhere automatically.

So the question changes from “how do I prompt better?” to:

What if I explained myself once, and Claude showed up already knowing? Not for one session. Every session.

2. The idea: an identity layer

An identity layer is a small set of plain markdown files that describe who you are and how you work. Claude reads them before substantive responses, whichever project you’re in. You write them once. Every session starts with them available.

The design decision that makes it work is where they live: at the workspace level, above any single project. That’s what lets them follow you into every project, every design session, every critique.

The four layers

Layer What lives here How often it changes
Session The task at hand (design, prototypes, requirements, research) Every time
Project Project instructions (what this is, its stage, how to show up), plus connectors, playbooks, templates, skills Per project
Workspace A baseline CLAUDE.md that directs Claude to load your identity into every session Rarely
Foundation Four identity files: about-me.md, principles.md, anti-patterns.md, voice-samples.md Slowly, and increasingly on its own

Each layer inherits from the one beneath it. The foundation flows up through the workspace and project layers so the session starts with full context.

The four files at a glance

File Job Think of it as
about-me.md Sets the context. Role, current focus, how you work, how you want to be helped A working brief for a new collaborator (not a LinkedIn bio)
principles.md Biases the reasoning. How you actually operate, drawn from real decisions The framework Claude should reason from
anti-patterns.md Catches the failure modes. Writing rules, thinking failures, domain mistakes Constraints, applied to a collaborator
voice-samples.md Makes output sound like you. 5-8 annotated passages you stand behind Show, don’t tell

The order matters when you build them (about-me, then voice-samples, then principles, then anti-patterns) and I’ll explain why in Part 4.

3. The workspace layout

A single folder hosts everything Cowork-related. ~/Documents/Claude/ is a sensible default, but ~/Claude/, ~/Cowork/, or an iCloud-synced folder works equally well. Pick one and use it consistently, because the path gets referenced in several places.

~/Documents/Claude/
├── CLAUDE.md                 ← workspace baseline, auto-loads in every session
├── Identity/                 ← who you are (always-load)
│   ├── about-me.md
│   ├── voice-samples.md
│   ├── principles.md
│   ├── anti-patterns.md
│   └── README.md
├── Playbooks/                ← runtime guides for recurring tasks
├── Templates/                ← reusable starting files
├── Reference/                ← setup briefs and historical docs
├── Projects/                 ← active work, one folder per Cowork project
├── Scheduled/                ← recurring scheduled tasks
└── Artifacts/                ← live HTML widgets

Every Cowork project in this workspace picks up CLAUDE.md, which in turn directs Claude to read the Identity/ files before it responds.

Why not put identity inside a project? Because then it only loads in that project. Root-level placement is the whole point.

4. Setup, step by step

Budget a few hours to do it well; a working v1 takes 30-45 minutes.

Step 1: Choose and mount the workspace folder

Decide where the folder lives before writing anything. That path will appear in CLAUDE.md, in identity-load directives inside project skills, in project instructions, and in scheduled-task prompts. Changing your mind later means updating all of them.

Then mount the folder in Cowork so every project can reach it.

Step 2: Build the identity files, in this order

Gather raw material first. You are not writing from a blank page. You are synthesizing what already exists: an about page, a LinkedIn bio, case studies, performance reviews, Slack threads that show how you think, articles you’ve published, past project docs. Existing artifacts are higher signal than fresh introspection.

Then build in order, because each file feeds the next:

  1. about-me.md (~500 words). The priors that bias every response.

    • Role and current chapter (this is the section that goes stale fastest)
    • How you work: decision style, defaults, what you actually do day to day
    • What you want from Claude: push back, be specific, synthesize, don’t fabricate, ask before acting
    • How you write: register and conventions, polished for human-facing output, casual for chat
    • What you value: priors that bias judgment calls

    Transform external-pitch register (“accomplished leader with 10 years of…”) into operator-brief register (“I decide fast on reversible things and slowly on irreversible ones”).

  2. voice-samples.md (5-8 passages). Real writing you stand behind: case study excerpts, doc intros, critique you’ve given, Slack threads with substance. Annotate each with what’s working: the sentence length, the specific move, the register cues.

    Samples beat rules. “Be direct and concise” gets Claude’s own interpretation. Three paragraphs you’re proud of, plus a note on the move each makes, teaches what direct and concise mean for you.

  3. principles.md (6-10 principles, ~30-50 words each). Drawn from decisions you’ve actually made, not aspirations. Group them: how you think about your role, how you treat customers or users, how you make strategic calls, how you want Claude to help. These aren’t commands. They bias Claude’s judgment so it reasons from your framework.

  4. anti-patterns.md (three sections):

    • In writing for me: banned openers, punctuation habits, generic-abstract language, register expectations
    • In thinking and helping me: fabrication, filling gaps with plausible detail, agreeing when wrong, burning through tool calls, defaulting to a browser when a connector exists
    • Domain-specific failure modes: whatever is specific to your field (in design: feature-first framing, optimizing for the demo, treating staged research as bureaucracy)

    Negative instructions are often more precise than positive ones, and writing this file forces you to articulate failure modes you’d only noticed implicitly.

Step 3: Write the workspace CLAUDE.md

A short file at the workspace root that:

It auto-loads in every session in the workspace, so it’s the universal scaffolding. Template in Part 5.

Step 4: Wire identity into each project

See Part 7.

Step 5: Smoke test

See Part 7.

Step 6 (optional): Playbooks, Templates, Reference

See Part 9.

Step 7 (optional): Schedule maintenance

See Part 8.

Step 8 (optional): Multi-machine sync

See Part 9.

5. Templates for every file

Copy, then replace every bracketed line with something real. If you can’t fill a section, leave it out rather than padding it.

Identity/about-me.md

# About me
<!-- Target: ~500 words. Past ~600, move detail into conditional reference files. -->

## Role and current chapter
[What you do, for whom, and what you're focused on right now.]
<!-- Most perishable section. Review every quarter. -->

## How I work
[Decision style, defaults, day-to-day reality. Write it as an operator brief.]

## What I want from you
- Push back when I'm wrong; don't soften it into mush.
- Be specific. Prefer concrete examples over general advice.
- Ask before acting on anything hard to undo.
- Show a short plan before substantive work (about half your usual length).
- If you don't know, say so; never fill gaps with plausible detail.

## How I write
[Register for human-facing output vs. chat. Conventions. See voice-samples.md.]

## What I value
[Priors that should tip judgment calls: e.g. evidence over opinion,
reversible over irreversible, small bets before big ones.]

Identity/voice-samples.md

# Voice samples
Load only when drafting something another human will read.

## Sample 1: [context, e.g. "kickoff note to a new team"]
> [Paste the real passage, unedited.]

**What's working:** [The move being made. e.g. "Opens with the decision,
then the reasoning. Short sentences. One concrete example instead of an
abstract claim."]

## Sample 2: [context]
> [...]

**What's working:** [...]

Identity/principles.md

# Principles
Descriptive, not aspirational: how I actually operate.

## How I think about my role
- **[Principle in a phrase].** [30-50 words: what it means and the real
  situation that taught it.]

## How I treat customers / users / stakeholders
- **[...]**

## How I make strategic calls
- **[...]**

## How I want Claude to help
- **[...]**

## Keeping this file current
If I correct the same thing twice, or something important comes up that
isn't captured in these files, flag it and propose an edit to the right file.

Identity/anti-patterns.md

# Anti-patterns

## In writing for me
- Don't open with [banned opener].
- Avoid [punctuation habit / phrase family].
- No generic-abstract language; name the specific thing.

## In thinking and helping me
- Don't act without showing me a short plan first, even when confident.
- Don't fabricate stats or details when uncertain. Flag the gap instead.
- Don't delete anything without proposing the change and waiting.
- Don't agree with me just to be agreeable.
- Don't lead with conclusions before I've seen the evidence.
- Don't reach for the browser when a connector already covers it.

## Domain-specific failure modes
- [Mistakes common in your field that you keep having to catch.]

Identity/README.md

# Identity files
These four files describe who I am and how I work. They are read before
substantive responses in every project in this workspace.

- about-me.md: context and how to help me
- principles.md: how I reason and decide
- anti-patterns.md: what to avoid
- voice-samples.md: how I sound (load only when drafting for humans)

Last full review: [date]

CLAUDE.md (workspace root)

# Workspace baseline

I'm [name], [role]. This workspace lives at [~/Documents/Claude/].

## Before any substantive response
Read, in this order:
1. Identity/about-me.md
2. Identity/principles.md
3. Identity/anti-patterns.md
Also read Identity/voice-samples.md when drafting anything another human will read.

## Folder map
- Identity/: who I am (always-load)
- Playbooks/: process guides for recurring tasks
- Templates/: reusable starting files
- Reference/: setup briefs and historical docs
- Projects/: active work, one folder per project
- Scheduled/: recurring tasks
- Artifacts/: live HTML widgets

## Rules
- Reusable templates belong in Templates/, never in the active project folder.
- Show a brief plan before file writes, folder creation, or wiring changes.

## Sync (multi-machine only)
- Always: Identity/, CLAUDE.md, Reference/, Playbooks/README.md, Templates/README.md
- Case by case: individual playbooks and templates
- Never: Projects/, Scheduled/, Artifacts/

## Maintenance
Quarterly review of Identity/, especially the "current chapter" section.

6. How to run the setup with Claude

The setup is highly personal and biases every future conversation, so treat it as collaborative work, not a form to fill in. The playbook is written so that Claude can run it with you. These are the ground rules, and you can hand them to Claude verbatim.

Confirm the workspace path first. Nothing gets written until you’ve agreed where the workspace lives.

Interview; don’t draft from a blank page. For each file, Claude gathers raw material from your existing artifacts first, then transforms it into the right register.

One section at a time. No 20-question intake forms. Work through the files in order; for each, ask the smallest useful question, draft, show you, let you react and edit, move on.

Match the question style to the content.

Always offer a draft to react to. If you say “I don’t know what to put here,” Claude should produce a v0 from what it already knows. Reacting is easier than generating.

Annotate sources and confidence. Each drafted section should say where it came from (“pulled from your about page, high confidence” vs. “synthesized from your case study, medium confidence, please verify”) so you can focus review where errors are most likely.

Calibrate early and persist it. When Claude spots a preference about verbosity, planning style, register, or pushback tolerance, it should write it into about-me.md or anti-patterns.md right away.

Show the plan before substantive work. Brief enough to scan, detailed enough to redirect. Especially before writing files.

Don’t move faster than you can think. These files will bias every future conversation. Slow down at decision points.

Kickoff prompt

Upload your source material (bio, case studies, writing you’re proud of), then paste:

I want to set up a persistent identity layer for this workspace: four
markdown files (about-me.md, voice-samples.md, principles.md,
anti-patterns.md) plus a workspace-level CLAUDE.md that loads them.

Ground rules:
1. Before writing anything, confirm with me where the workspace folder
   lives, and use that exact path everywhere.
2. Mine the material I've shared before asking me new questions.
3. Work one file at a time, in this order: about-me, voice-samples,
   principles, anti-patterns.
4. For each file: show a draft with a source and confidence note per
   section, ask at most five targeted questions, then revise before moving on.
5. Use multiple choice for structural decisions and open questions for
   voice, values, and anti-patterns.
6. Show me a short plan before you create or edit any files.
7. Don't invent anything you can't ground in what I've shared or told you;
   flag gaps instead.
8. Keep each file tight. Accurate and short beats padded.

Expect roughly 30-45 minutes to a working v1. Some people build 30+ files with elaborate taxonomies. Filiatrault started with four files of a few hundred words each. Both approaches work; what matters is getting something in place and refining it.

7. Wiring identity into projects and testing it

Wire each project

For every Cowork project (an executive assistant, a design collaborator, a strategic initiative):

  1. Make the workspace reachable. If the project’s main folder is narrower (e.g. Projects/Executive Assistant/), add the workspace root as additional context so CLAUDE.md and Identity/ are reachable.
  2. Add a directive to the project’s SKILL.md, if it has one:

    Before any substantive response, read ~/Documents/Claude/Identity/about-me.md, principles.md, and anti-patterns.md.

  3. Paste the same directive into Cowork’s stored project instructions (the UI field, which is separate from files), along with any project-specific behavior rules.

Keep the split clean: about the work lives in the project, about you lives in the identity layer. Duplicating between them creates contradictions.

Smoke test

In a fresh session inside the project, ask something that requires identity context:

What are my anti-patterns?

If Claude reads the file and answers from it, the wiring works. If it has no idea, troubleshoot the folder mount first; that’s the most common cause.

Don’t ask “did you load my identity at startup?” That test misleads, because Claude reads files on demand rather than at startup. A substantive question that requires the content is the reliable check.

Then run a second test on behavior: ask for a small piece of writing and see whether the voice, plan-first habit, and anti-patterns show up.

8. Keeping it alive: maintenance and self-improvement

Why this part matters

If the files need constant manual upkeep, most people abandon them within a month. The value of the system is that it mostly maintains itself, so each correction you make becomes one fewer correction next time. The compounding is real and fairly quick: even a thin about-me.md visibly changes the first session, and after a few weeks the collaboration feels different in kind.

Three mechanisms

1. In-session flagging. Put an instruction in principles.md telling Claude to speak up when it notices a gap: you’re correcting the same mistake twice, or something important comes up that no file captures.

2. A weekly scan for patterns. Claude won’t catch everything mid-session. A scheduled pass over recent conversations can look for things you corrected or clarified repeatedly and propose additions to the identity files.

3. A quarterly review. Run a memory-consolidation pass against the Identity/ folder, paying special attention to the “current chapter” section of about-me.md, which goes stale fastest.

Reconciling automation with control

The article describes corrections being integrated back into the files; the setup playbook is more cautious and says the maintenance task should produce a report, not auto-modify files, so you review and approve each edit. My recommendation: start with report-and-approve. These files bias everything downstream, and a silent bad edit is hard to notice. Once you trust the scans, you can loosen the leash for low-risk additions (e.g. appending a new anti-pattern) while keeping approval for changes to existing lines.

A scheduled-task prompt you can adapt

Review my recent conversations and the files in Identity/. Produce a report
(do NOT edit any files) covering:
1. Corrections or clarifications I gave more than once.
2. Things I explained that aren't captured in any identity file.
3. Lines in the identity files that my behavior contradicts (possibly stale).
4. New voice-sample candidates: passages I wrote and seemed happy with.
For each item, propose the exact edit, name the target file, and give
your confidence and evidence. I will approve edits individually.

Habits that keep it healthy

9. Optional extras: Playbooks, Templates, Reference, sync

Once identity works, these three folders amplify it. Keep their roles distinct:

Folder Purpose Nature
Playbooks/ Process guides for recurring tasks: when to trigger, references, steps, gotchas, output format Process
Templates/ Reusable starting structures that get copied and adapted Starting points
Reference/ Setup briefs, historical docs, anything reusable across machines or time Read-only

A skeleton for a playbook

# [Task name]

## When to trigger
## What good looks like
## Inputs / references
## Process
## Common gotchas
## Output format

Multi-machine sync

If you work on more than one computer (say work and home), write the rules into CLAUDE.md:

AirDrop is the simple default. Have the quarterly maintenance report remind you to sync when Identity files changed.

Privacy note: identity files are read constantly and may travel with your workspace. Keep credentials, client-confidential material, and anything you wouldn’t want quoted in a draft out of them.

10. Common gotchas

Gotcha What happens Fix
Identity in the wrong place Files inside one project only load in that project Put Identity/ at the workspace root
Workspace not mounted CLAUDE.md and identity files don’t load; Cowork doesn’t auto-mount after an app restart Default projects to the workspace folder or add it as additional context
Bad smoke test “Did you load my identity?” gives a misleading answer Ask a question that needs the content, e.g. “What are my anti-patterns?”
Voice rules without samples “Write like me” yields generic output Add 5-8 annotated real passages
Aspirational principles Conflicting signals; output written for an idealized you Base every principle on a real decision
Length creep about-me.md past ~600 words dilutes attention Move long-form content to reference files that load conditionally
Templates saved in project folders Claude saves reusable templates in the active project Add an explicit rule to CLAUDE.md: templates go in Templates/
“Show your plan” ignored or bloated Full-length plans defeat the purpose Put the rule in about-me.md or anti-patterns.md with a verbosity calibration (“about half your usual length”)
Skipping voice-sample annotations Surface mimicry instead of understanding Add the one-line “what’s working” note to every sample
Duplicating project and identity content Contradictions between layers About the work lives in the project; about you lives in identity
Write-once mindset Files go stale; “current chapter” drifts Keep the maintenance cadence, automated or not

11. Adapting this beyond Cowork and beyond design

The mechanics above are Cowork-specific (workspace folders, mounts, project skills). The mental model is portable: a workspace baseline, an identity load, and project wiring. The content of each file changes by role; the structure doesn’t.

Other Claude surfaces. The same four files can be adapted to whatever persistent-context mechanism your tool offers: a standing project knowledge base, saved preferences, or a repo-level CLAUDE.md in a coding setup. Check your tool’s current documentation for how each one loads context, since details vary and change.

Other roles.

Sharing with colleagues. The playbook structure is shareable; the Identity files are not. Each person must write their own, because the content is personal and only works if it reflects how they operate. Copy the structure, not the substance.

A side effect worth mentioning. Building the layer sharpens you. Writing anti-patterns.md surfaces failure modes you only noticed implicitly. Writing principles.md sends you back through real decisions to ask what you were actually optimizing for. That clarity has value independent of anything Claude does with it.

12. Final checklist

Before you start

Identity files

Wiring

Upkeep

The payoff: the setup takes an afternoon, and after that the re-explaining tax mostly disappears. Every project, chat, and recurring task starts from a collaborator that already knows who you are.

Sources and credit: the identity-layer concept and four-file structure come from Sean Filiatrault’s article “How to stop re-explaining yourself to Claude” (UX Collective, June 2026). The workspace layout, interview protocol, wiring steps, gotchas, and maintenance guidance draw on the accompanying Cowork setup playbook. This guide is an adaptation and extension in my own words; go read the original article, and use the author’s shared scrubbed example files if you want to see real ones.

Tags: AiAi_agentPrompt_engineeringLlm