How Carl Set Up His Personal OS in Claude Code

And how you can too!

Today’s post is a guest post from Carl Vellotti. I’m a big fan of Carl’s efforts to build in the open and share open source educational content. Carl and I have been talking about sharing a hybrid post that combines the structure of the PersonalOS I’ve shared out, and his own approach. I love this because everyone’s personalOS is (and should be) slightly different. Carl shares what he modified, how it works and his thought process along the way.

If you’re curious about building your own PersonalOS, Tal and I are running a 2-day workshop on this later this week. As a subscriber, you get 15% off. We’ll also be sending a free mac mini to anyone who brings 2+ coworkers/friends to the workshop, and we just added a focused session on setting up OpenClaw for real work (first course to offer this!)

Now, on to the post!

Intro

The biggest question I get after people finish my Claude Code for PMs or for Everyone courses: “How should I set up my space?”

Claude Code is infinitely flexible. There’s no single right way to organize it, which is both liberating and paralyzing. Instead of trying to define how YOU should use it, I’ll show you how I use it and why I made the choices I made.

This setup is battle-tested across content creation, product work, and running a small business. But it’s not gospel. Try things, break things, and see what actually works for your workflow. Making your setup work for you is the fun part.

You can download this structure and see a complete example here: https://github.com/carlvellotti/carls-product-os (hint: This is super similar to the starter template Aman shared here)

The Structure at a Glance

Quick overview:

• CLAUDE.md - Entry point. Claude reads this automatically.

• GOALS.md - Who you are, what you own, what you’re working toward. All in one file.

• Tasks/ - Backlog → active → archive. Dead simple.

• Projects/ - Bigger chunks of work with their own context and outputs.

• Workflows/ - Repeatable stuff. Mini-workspaces you use over and over.

• Meetings/ - Notes by type.

• Knowledge/ - Reference material that lives across projects.

• Templates/ - Document structures.

• .claude/skills/ - Slash commands.

• Tools/ - Scripts you build.

• _temp/ - Dump stuff here.

CLAUDE.md

Claude reads this automatically at the start of every conversation. I use it to explain how my system works so Claude can navigate it. Point to key files rather than duplicating info.

Examples of what I put in mine:

• “My goals are in GOALS.md”

• “Active projects are in Projects/”

• “When I say /standup, use the skill in .claude/skills/”

Keep it short. Brief description of who you are, how your folders work, key commands. NOT detailed content—just pointers.

A few principles I’ve landed on:

• Pointers, not content. Link to GOALS.md — don’t paste your goals into CLAUDE.md. It tells Claude where to look. The actual substance lives in the files it points to.

• Update it when your system changes, not when your work changes. New major folder? Update CLAUDE.md. New project within a folder? Don’t touch it.

• Keep it under 100 lines. If it’s getting long, you’re putting content here that belongs somewhere else.

One question I get a lot: when do you use Claude Code vs Cursor? I use Claude Code for anything that spans multiple files and needs broad context — planning, writing, research synthesis, stakeholder updates. Cursor when I’m heads-down building inside a specific codebase. This OS is designed for Claude Code.

GOALS.md

I keep my identity, ownership areas, and current goals all in one place. Claude references this to understand what I care about. I update it quarterly for goals, and whenever my ownership changes.

Mine has stuff like:

• “I’m a PM at [Company] working on [Product]”

• “I own: TA experience, grading consistency, adoption metrics”

• “Q1 Goal: Reduce grading inconsistency by 40%”

Sections: Who I am, what I own, current goals with metrics, key context.

Why one file instead of splitting it up? Less files = less LLM decision-making about what to prioritize. Claude can pick up what it needs from one consolidated doc.

Tasks/

Brain dump anything that comes up into backlog.md. Move things to active.md when you’re actually working on them. Archive when done.

That’s it. Three files:

• backlog.md - everything captured, unprocessed

• active.md - what you’re working on now

• archive/ - completed stuff for reference

Projects/

When something is bigger than a task, I create a project folder and dump all context into it. Then I point Claude at the folder: “hey claude we’re working in here @project-folder”

All research, drafts, and outputs stay together. The project folder becomes the workspace.

Examples:

• Building a new dashboard feature → ta-workload-tracker/

• Preparing a board presentation → q1-board-deck/

• User research study → ta-satisfaction-research/

Inside each project:

• brief.md - context dump (what, why, who, timeline)

• research/ - interviews, data, anything project-specific

• Output files flat at root (PRDs, specs, drafts)

• assets/ - images, slides, diagrams

Workflows/

This is where it gets interesting.

When I find myself repeating a certain kind of work, I turn it into a workflow. Each workflow is basically a mini-workspace with its own CLAUDE.md and step-by-step process. I work through it collaboratively with Claude—each step builds on the last.

Examples:

• Writing weekly newsletter → Workflows/weekly-newsletter/

• Running quarterly planning → Workflows/quarterly-planning/

• User research synthesis → Workflows/research-synthesis/

Inside each workflow:

• CLAUDE.md - scoped instructions for THIS workflow specifically

• workflow-spec.md - overview of the process

• [step-N].md - prompts/guides for each step

• Reference docs (style guides, examples, patterns)

• Drafts/ and Published/ folders for outputs

Projects are one-off. Workflows are for things you do repeatedly. If you catch yourself setting up the same kind of project more than twice, make it a workflow. As you build and refine your workflow, you can turn all the pieces where you don’t need to actively involved into skills.

Meetings/

Capture notes during or after meetings. I sync from Granola MCP, but you can do it manually. Reference past meetings when you need context on decisions. Prep for 1:1s by reviewing previous notes.

Structure:

• 1on1s/ - organized by person

• standups/ - organized by date

• One-off meetings flat at root

Knowledge/

Stuff I reference across multiple projects. Stable facts about company, product, team. Research learnings that build up over time.

Three folders:

• Reference/ - stable facts (company.md, product.md, team.md)

• Research/ - learnings, industry trends, explorations

• People/ - stakeholder notes, working styles, preferences

Important distinction: Projects/research/ is temporary, scoped to that project. Knowledge/ is persistent, reusable everywhere.

Templates/

Document structures I use repeatedly. Point Claude at a template: “use the PRD template in Templates/”

I evolve these over time as I figure out what works.

Examples:

• prd.md - PRD structure

• weekly-update.md - stakeholder update format

• 1on1-notes.md - 1:1 meeting notes

• research-summary.md - research synthesis format

Templates are for document structure. Workflows are for multi-step processes. A PRD template defines the sections. A PRD workflow guides you through filling it out.

.claude/skills/

Reusable commands for things I do repeatedly. Type /standup instead of explaining what I want every time.

Skills are the interface layer—they can call tools, reference files, or just be prompts.

Examples:

• /standup → generate daily standup from recent work

• /weekly-update → draft stakeholder update

• /synthesize-research → summarize across research files

Tools/

Scripts and utilities. Build automation here first, iterate until it works. Once stable, wrap it with a skill that calls the tool.

Keep README and any context with the tool.

Simple tools are just a .py file. Complex tools get their own folder with run.py, README.md, config.json.

In the example repo, Alex has two tools:

1. metrics-pull/ pulls data from Amplitude and formats a weekly summary with period-over-period comparisons and red/yellow/green alerts.

2. meeting-prep/ searches past meeting notes and extracts open action items into a prep doc.

Both get called through skills — Alex types /weekly-update and the skill runs the metrics tool behind the scenes. You never run the scripts directly.

I’ve found it works best to build the tools in one place and then have the skills reference those tools rather than putting all of this into the skills themselves.

_temp/

Dump random files here without thinking about where they belong. Screenshots, downloads, stuff someone sent you. Clean up periodically.

A Day In the Life of a Claude Code Native PM

Here’s a walkthrough of exactly what this whole system looks like all together. The example repo shows what this OS might look like for a PM named Alex at a fictional company called GradeFlow.

This walkthrough follows Alex through a typical Tuesday. Every command and file below is real — you can find them all in the example repo.

1. Morning standup. Alex opens Claude Code and types /standup. Claude scans recent file changes, reads @Tasks/active.md, and generates a briefing: yesterday you hit 80% on the hallucination guardrails spec, today you need to prep for your 1:1 with David and knock out TA onboarding interview #4. One blocker flagged — still waiting on Jordan’s eng estimate for the workload tracker.

2. Prep for a 1:1. /meeting-prep @Meetings/1on1s/david-chen.md. Claude pulls the last three 1:1 notes (you owe David an update on Acme churn risk), checks @Knowledge/People/david-chen.md to remember his preferences (BLUF format, no surprises, data first), and generates a prep doc with talking points. You walk into the meeting with a plan instead of winging it.

3. Deep work on a project. “Let’s work on the workload tracker @Projects/ta-workload-tracker/”. Claude reads brief.md for context — you’re building a dashboard so professors can spot TA workload imbalances. You ask it to tighten up the requirements based on user research. It pulls quotes directly from research/interview-sarah-ta.md (”I just silently pick up the slack”) to ground every recommendation.

4. Synthesize research. /synthesize-research @Projects/ta-workload-tracker/research/. You just wrapped interview #6. Claude reads all the interview files, extracts patterns across participants, and writes a synthesis: 0 out of 5 professors currently monitor workload, but all said they’d act if they could check in under 30 seconds. It organizes themes by frequency and links each to direct quotes.

5. Draft a PRD section. /draft-prd-section “Success Metrics” @Projects/ta-workload-tracker/. Claude pulls from the brief, your research synthesis, and @GOALS.md — you’re targeting 60% professor adoption and a grading inconsistency drop from 0.8 to 0.48 std dev. It drafts metrics grounded in actual user data, not guesses.

6. Quick capture mid-day. You get off an unplanned customer call. “Hey, just got off a call with Riverside School District, here are my rough notes...” Claude writes them to _temp/quick-notes-customer-call.md. No folders, no structure, just capture. You’ll process it later or not — that’s the point of _temp/.

7. Add to the backlog. “Reminder — we need to research competitor approaches to grade calibration scoring.” Claude appends it to Tasks/backlog.md under Features. It sits there until you’re ready to promote it to active or spin up a project.

8. Run a workflow for your stakeholder update. “Let’s do the weekly update @Workflows/weekly-stakeholder-update/”. Claude reads the workflow’s own CLAUDE.md — scoped instructions for this specific process (leadership audience, under 500 words, red/yellow/green status). It follows gather-metrics.md to know what data to reference, checks your recent project updates, and drafts the email. You review, tweak one line, done.

9. Prep for tomorrow. “What should I focus on tomorrow?” Claude cross-references @Tasks/active.md (rollout playbook is at 30% and due in 8 days), @GOALS.md (TA adoption stuck at 62%, target 80%), and this week’s meeting notes. It flags that the AI Feedback Assistant launch is 16 days out and the CSM rollout playbook is the critical path.

10. The compounding effect. None of this required Alex to explain context twice. The 1:1 prep knew David’s preferences because Knowledge/People/ exists. The PRD draft hit the right metrics because GOALS.md was up to date. The stakeholder update wrote itself because the workflow remembered the format and audience. Every file you maintain makes every future interaction smarter.

Getting Started

1. Clone the repo

2. Look at EXAMPLE-OS/ to see how it works (you can test it with Alex’s commands above)

3. Copy BLANK-OS/ and make it yours

4. Start with CLAUDE.md + GOALS.md—that’s 80% of the value

5. Add workflows/skills as you find yourself repeating things

FAQ

Where does planning go?

Planning doesn’t need its own folder. Everything planning-related either:

1. Goes in GOALS.md - priorities, objectives, focus areas

2. Is a Project - quarterly planning, board deck prep, annual strategy (discrete work with outputs)

3. Is a Workflow - if you do planning the same way every quarter

Don’t create folders for categories of work. Create folders for actual work (projects) or repeatable patterns (workflows).

Templates vs Workflows?

Templates = document structure (the what)

• PRD template defines sections

• You point Claude at it: “use this template”

• Output: a single document

Workflows = multi-step process (the how)

• PRD workflow guides you through research → drafting → review → finalization

• Has its own CLAUDE.md, step files, reference docs

• Output: multiple documents, iterated over sessions

Need consistent format? Template. Need to guide a complex process? Workflow. Need both? Workflow that references templates.