# Build Your Personal AI Operating System with Claude Cowork

A Product Compass flagship module. You run client work. You're drowning in status updates, scattered notes, half-finished proposals, and a calendar that mugs you every Monday. You are not a developer, and you don't want to become one.

This module shows you how to stand up a **personal AI operating system** — a set of dashboards, briefs, and skills that run *your* practice — using Claude Cowork. By the end you'll have a working "mission control" for your consulting work, built block by block, with no code you didn't paste yourself. Time to first working system: **3 hours.**

*Method inspired by Tina Huang's "Claude Cowork Fundamentals." Our consulting examples and copy are original. Accurate as of June 2026.*

## The one idea that makes this work: PRD first

Most people open an AI tool and start typing wishes. They get a demo, not a system. The demo impresses them for a day and then rots because nothing about it was designed.

The fix is boring and it works: **write a Product Requirements Document (PRD) before you build anything.** A PRD forces you to name the problem, define what "done" looks like, set scope, and agree a plan — *then* you build against it. Same discipline you'd demand from a junior consultant before they touch a client deck.

You don't write the PRD by hand. You make Claude write it by interviewing you. We'll get there. First, set the rules.

## Step 1 — Set the operating instructions

Before any build, you tell Cowork how to behave. These four rules are the difference between an assistant that ships your practice and one that quietly breaks it. Paste this into a file called `CLAUDE.md` at the root of your project.

```
Operating instructions — Product Compass AI OS

1. PRD before build. Do not build, automate, or change anything until we
   have a written PRD with: the problem, success criteria, scope, constraints,
   and a step-by-step plan. Propose it, then wait for my explicit sign-off.
   No PRD, no work.

2. Push back. If something I ask for is strategically wrong, technically
   inconsistent, or going to bite me later, say so before doing it. I'd rather
   argue for two minutes than unwind a mess. Disagreement is a feature.

3. Take notes obsessively. Document decisions, sources, and what you changed
   as you go. As this system grows you will forget context — written notes are
   how we keep it coherent. Update the relevant memory/ files and the decision
   log every time something non-obvious happens.

4. Reversibility and consent. Confirm with me before anything destructive or
   anything that touches money, clients, or external systems (sending email,
   deleting files, posting). When in doubt, interrupt me. A paused build beats
   a silent mistake.
```

Why these four? Rule 1 kills the demo trap. Rule 2 stops you building confidently wrong things. Rule 3 is what lets the system survive past week one. Rule 4 is what lets you point it at your actual client data without lying awake.

## Step 2 — Generate your PRD with the metaprompt

Here's the move: instead of writing a PRD, you paste a **metaprompt** — a prompt that makes Claude interview you and write the PRD for you. Paste this into Cowork as your first real instruction.

```
Act as my product partner. I want to build a personal AI operating system for
my consulting practice in Claude Cowork. Before writing anything, interview me:

1. Ask me 5–7 sharp questions about my work, my biggest time sinks, and what a
   great Monday morning would look like.
2. Based on my answers, propose 4–6 candidate "domains" I could build (e.g. a
   client dashboard, a weekly digest, a proposal builder). For each, one line
   on what it does and why it's worth it.
3. Ask me my technical comfort level and which connectors I have available
   (Gmail, Calendar, Drive, Slack, etc.).
4. Ask my build-time budget: 3, 5, or 8 hours.
5. Then output a build-ready PRD containing: an executive summary; a quick-start;
   goals and explicit non-goals; a three-tier memory architecture; a data-layer
   spec with the exact folder structure; component specs for each domain; a
   time-boxed build plan; copy-paste prompts for each block; a decision log; and
   an out-of-scope list.

Do not start building. Stop after the PRD and wait for my sign-off.
```

Answer its questions honestly. The interview is the work — it's where your practice gets turned into a spec. When the PRD comes back, read it like you'd read a junior's proposal: cut scope, fix wrong assumptions, push back. Then sign off.

**Scope ruthlessly.**

| Budget | What you build |
|---|---|
| 3 hours | Foundation + 1 domain + a morning brief |
| 5 hours | Foundation + 2 domains (or 1 rich one done properly) |
| 8 hours | Foundation + 2–3 domains |

Build your top-priority domain *fully* before adding a second. A finished client dashboard beats three half-built toys.

## Step 3 — Initialize the project

1. On your machine, create a folder. Call it something you'll respect: `mission-control/`.
2. In Claude Cowork, create a **New Project** and point it at that folder.
3. Drop the PRD in as a markdown file (`PRD.md`) inside the folder, alongside your `CLAUDE.md` operating instructions.
4. Activate it with: *"Please start building with the Product Compass AI OS PRD. Begin with Block 0."*

That's it. Cowork now has its rules, its spec, and a place to work.

## Step 4 — Build block by block

Resist the urge to build the pretty dashboard first. **Data before interfaces.** A dashboard with nothing behind it is a screenshot.

- **Block 0 — Setup (15 min):** install your productivity plugin, run `/start`, enable the connectors your PRD calls for (Gmail, Calendar, Drive, Slack). Confirm Cowork can see them before moving on.
- **Block 1 — The data layer (hour 1):** the unglamorous hour that makes everything work. Build the pipelines *before* the interfaces — lay down the folder structure, seed real inputs, define the refresh workflow, and stand up the three-tier memory.
- **Blocks 2+ — Interfaces, briefs, skills:** now build what you actually see, in priority order — dashboards (always-on), morning briefs (scheduled), on-demand skills, and autonomous builders (only once the basics are solid).

## The architecture (memorize this shape)

Every domain you build sits inside one consistent skeleton. This is what keeps a growing system from turning to mud.

```
mission-control/
├── CLAUDE.md            # operating instructions + cross-cutting context
├── TASKS.md             # the running to-do / build log
├── PRD.md               # the signed-off spec
├── memory/              # deep knowledge, by domain
│   ├── clients/
│   ├── pipeline/
│   └── practice/
├── dashboard.html       # always-on view(s)
└── {domain}/            # one folder per domain
    ├── CLAUDE.md        # role-specific instructions for THIS domain
    ├── inputs/          # raw stuff coming in
    ├── data/            # cleaned / structured
    └── outputs/         # what the system produces
```

**Three-tier memory** — the part people skip and regret:

1. **Root `CLAUDE.md`** — cross-cutting truths (your firm, your voice, the operating rules).
2. **`memory/{domain}/`** — deep knowledge for a domain (everything about a key client, your pricing logic).
3. **`{domain}/CLAUDE.md`** — role-specific instructions for working *in* that domain.

**Four interaction patterns** — every useful thing you build is one of these:

| Pattern | Cadence | Example |
|---|---|---|
| Dashboard | Always-on | Client health board |
| Brief / digest | Scheduled | Monday morning practice brief |
| Skill | On-demand | "Draft a proposal for this client" |
| Autonomous builder | Hands-off | Watches a `pending/` folder and works the queue |

## Common ways people blow it (and the fix)

- **Skipping the PRD.** You get a demo, not a system. Fix: Rule 1, no exceptions.
- **Building the dashboard first.** It has nothing to show. Fix: data layer in hour 1.
- **Pointing it at everything at once.** Thin and useless across five domains. Fix: one domain, fully, then the next.
- **No memory tiers.** Week two it forgets why it did things. Fix: build `memory/` on day one.
- **Letting it act without consent.** It emails a client something half-baked. Fix: Rule 4.

---

# Three consulting builds: copy-paste prompts & folder skeletons

These replace generic investing/personal examples with builds that earn their keep in a consulting practice. Build the one that hurts most first. They share one `mission-control/` skeleton and one `memory/clients/` brain.

## Build A — Client Health Dashboard

An always-on view of every active client — status, last contact, open deliverables, risk flags, and what needs your attention this week. The thing you wish you had open every morning.

**Paste-ready PRD seed:**

```
Build me a Client Health Dashboard.
Problem: I lose track of which clients are slipping until it's a fire.
Success: one dashboard.html showing every active client with status
(green/amber/red), last-contact date, open deliverables, next milestone, and a
"needs attention" list at the top, refreshed from my Gmail, Calendar, and a
clients/ folder.
Scope: read-only dashboard + a refresh skill; no auto-emailing.
Constraints: I confirm before anything leaves my machine.
Propose the PRD with folder structure and a 60-minute build plan, then wait for
sign-off.
```

**Folder skeleton:**

```
mission-control/
├── dashboard.html
├── memory/clients/{client}.md     # one deep file per client
└── client-health/
    ├── CLAUDE.md                   # how to score health, what "red" means
    ├── inputs/                     # exported emails, notes, status updates
    ├── data/clients.json           # status, lastContact, deliverables[], risk
    └── outputs/attention.md        # this-week needs-attention list
```

**Block 1 — data layer:**

```
Create client-health/data/clients.json with one record per active client: name,
status (green/amber/red), lastContact, nextMilestone, openDeliverables (list),
riskNotes. Seed it from the files in client-health/inputs/ and from my Gmail +
Calendar connectors. For anything you're unsure about, mark it amber and tell
me — don't guess green.
```

**Block 2 — scoring rules** (write into `client-health/CLAUDE.md`):

```
Health scoring:
Red   = no contact in 14+ days, OR an overdue deliverable, OR an unresolved escalation.
Amber = contact in 7–14 days, OR a milestone within 5 days with open items.
Green = recent contact and nothing overdue.
Always surface red and amber at the top of the dashboard.
```

**Block 3 — the dashboard:**

```
Build dashboard.html: a clean board, one card per client, color-coded by status,
sorted red → amber → green. Top section: "Needs attention this week" pulled from
outputs/attention.md. Each card shows last contact, next milestone, and open
deliverables. No frameworks, single file, opens in a browser.
```

**Block 4 — refresh skill:**

```
Create an on-demand skill "Refresh client health": re-pull Gmail + Calendar,
update clients.json, regenerate attention.md and dashboard.html, and give me a
3-line summary of what changed since last refresh. Confirm before sending or
deleting anything.
```

## Build B — Weekly Client Digest

A scheduled brief — your Monday 7am practice summary. What happened across clients last week, what's due this week, where you're at risk, and a clean daily plan.

**Paste-ready PRD seed:**

```
Build me a Weekly Client Digest.
Problem: I start the week reactive, reconstructing where everything stands.
Success: every Monday, a single markdown brief covering — per client: last
week's activity, this week's deadlines, blockers; plus a consolidated calendar
view, an inbox triage (what needs a reply), and a suggested daily plan Mon–Fri.
Scope: generate the brief into outputs/; do not send anything.
Constraints: read-only on email/calendar.
Propose the PRD and a build plan, then wait for sign-off.
```

**Folder skeleton:**

```
mission-control/
├── memory/clients/                 # shared with Build A — reuse it
└── weekly-digest/
    ├── CLAUDE.md                   # tone, structure, what to include/skip
    ├── inputs/                     # last week's notes, anything ad-hoc
    ├── data/week-{date}.json       # assembled raw material for the week
    └── outputs/digest-{date}.md    # the finished Monday brief
```

**Block 1 — gather:**

```
Create weekly-digest/data/week-{this-monday}.json. Pull from Gmail, Calendar,
and memory/clients/: per active client, last 7 days of activity and any deadline
in the next 7 days; all my meetings this week; emails flagged or unreplied older
than 2 days. Structure it, don't summarize yet.
```

**Block 2 — digest format** (write into `weekly-digest/CLAUDE.md`):

```
The digest is for a busy consultant reading Monday at 7am. Order:
1. This week's headline — the one thing that matters most.
2. Per-client — 2–3 bullets each, deadlines bolded.
3. Inbox triage — who's waiting on me, ranked.
4. Daily plan Mon–Fri — 3 priorities per day, calendar-aware.
Plain, direct, no filler. Flag risks explicitly; don't bury them.
```

**Block 3 — generate:**

```
Generate this week's digest into weekly-digest/outputs/digest-{this-monday}.md
from the week's data, following the format in weekly-digest/CLAUDE.md. Keep it
under one screen of scrolling.
```

**Block 4 — schedule** (reversibility check first):

```
Set this to run every Monday at 7am: refresh the data, generate the digest, and
leave it in outputs/ for me to read. Do NOT email it anywhere. Confirm the
schedule with me before enabling it.
```

## Build C — Proposal / PRD Builder

An on-demand skill that turns a messy discovery call into a structured client proposal (or internal PRD) in your firm's voice, using your templates and past winners.

**Paste-ready PRD seed:**

```
Build me a Proposal / PRD Builder skill.
Problem: proposals take me a day and start from a blank page every time.
Success: I give it discovery notes + a client name, and it produces a draft
proposal in our house structure (situation, objectives, approach, scope,
deliverables, timeline, commercials placeholder) in our voice, drawing on past
winning proposals in inputs/.
Scope: generate a draft into outputs/; I edit and send manually.
Constraints: never invent commercials or client facts — flag gaps for me to fill.
Propose the PRD and build plan, then wait for sign-off.
```

**Folder skeleton:**

```
mission-control/
├── memory/practice/voice.md        # our tone, banned phrases, house style
├── memory/practice/pricing-logic.md# how we scope and price (never auto-filled)
└── proposal-builder/
    ├── CLAUDE.md                    # the proposal structure + rules
    ├── inputs/templates/            # our proposal template(s)
    ├── inputs/winners/              # 3–5 past proposals that won
    ├── data/discovery-{client}.md   # the notes for the current job
    └── outputs/proposal-{client}.md # the generated draft
```

**Block 1 — teach it our style:**

```
Read everything in proposal-builder/inputs/templates/ and inputs/winners/. Write
memory/practice/voice.md: our proposal structure, tone, recurring phrases that
work, and anything to avoid. Then summarize back to me what you think "our voice"
is in 5 bullets, so I can correct you.
```

**Block 2 — the build rules** (write into `proposal-builder/CLAUDE.md`):

```
Structure every proposal: Situation (their world, in their words) → Objectives →
Our approach → Scope & deliverables → Timeline → Commercials (placeholder, never
fill) → Why us. Rules: never invent client facts, dates, or numbers — insert
[CONFIRM: …] and list every gap at the top. Match the voice in
memory/practice/voice.md. This is a draft for me to finish, not send-ready.
```

**Block 3 — the skill:**

```
Create an on-demand skill "Draft proposal": input = a client name + discovery
notes (I'll drop them in data/discovery-{client}.md). Output =
outputs/proposal-{client}.md following the structure and rules. Start the file
with a "Gaps to confirm" checklist. End with 3 suggested next steps for me.
```

**Block 4 — dry run:**

```
Run the skill on the sample discovery notes in data/. Show me the draft. Then
tell me: what was strong, what you had to guess, and which gaps you flagged.
We'll tune the rules from there.
```

## How the three fit together

Build A gives you the always-on picture. Build B turns it into a weekly rhythm. Build C does your heaviest writing on demand. Start with A or B (fastest payoff), add C when you've got an hour and a stack of past proposals to feed it. None of these send, delete, or spend without asking you first — that's not a limitation, it's what lets you point them at real client data.

---

## What you'll have at the end

A `mission-control/` folder that is genuinely *yours*: operating rules it obeys, a spec it was built against, a data layer that refreshes, and at least one domain running for real. From there, every new capability is just another block on the same skeleton.

That's the whole trick. Not magic. Discipline, applied once, that pays out every Monday.

*Method inspired by Tina Huang's "Claude Cowork Fundamentals." Original examples, copy, and consulting builds by Product Compass. Accurate as of June 2026.*