I never re‑explain a project to Claude anymore.

This is the system. It's free, and your Claude sets it up in about 10 minutes.

New chat

Resume Course launch

What a fresh chat looks like once the project page exists. No re-explaining.

The button copies the whole setup. Paste it into a new Claude chat

Set up Project OS for me. Everything you need is below. Follow the START section exactly; the files it mentions are included at the end, so you don't need to fetch anything.

… plus the full setup and the four reference files (about 28 KB). The button copies all of it.

Set up Project OS for me. Everything you need is below. Follow the START section exactly; the files it mentions are included at the end, so you don't need to fetch anything.

**Check this first.** The last non-empty line of this message (or of the attached file, if it came as a file) must be `=== END OF SETUP ===`. If it isn't there, the paste got cut off. Don't start anything. Tell the person, in these words: "Your paste got cut off before the end. Open the page in Safari or Chrome (not inside Instagram), tap **Download as a file**, and attach that file to a new chat." Then stop.

# START — setting up Project OS

*You are an AI assistant. A person pasted this whole message asking you to set up Project OS. Follow it top to bottom. Talk to them in plain language; assume they have never heard of a "skill," a "repo," or a "data source." Total time is about 10 minutes, less if Notion is already connected, including one real project and a fresh-chat test at the end.*

Everything you need is in this message. The four files this setup refers to (`engine.md`, `hub-template.md`, `resume-and-handoff.md`, `model-tiers.md`) are included in full at the end, each between `=== FILE: name ===` and `=== END FILE ===`. Don't fetch anything from the web.

## 0. Before you start

Say one sentence: you're setting up Project OS; you'll ask four questions, build one page, one database, four reference pages and one example project in their Notion, then hand them one paragraph for their settings. Nothing outside that one Notion page is touched.

Then check:

- **Already set up?** If their Notion already has a "Project OS" page with a "Projects" database inside it, this is an update, not a setup. Do only this: replace the Rules of the road on that page and the four child pages with the versions in this message, re-fetch once to confirm it landed, tell them in a few lines what changed, and stop. Skip steps 1 through 6 (that one re-fetch is the only part of step 3 you do). Touch no project rows and no settings.

- **Notion.** Can you create pages and databases in their Notion right now? If you can connect but can't create a new top-level page (some Notion connections only reach pages that were shared with them), ask them to create an empty page named "Project OS", share it with the connection, and build everything inside it. If you can't reach Notion at all, stop and tell them how to connect it: the Claude app usually shows a Connect button for Notion right in the chat; if not, walk them to connecting Notion in the app they're using (Claude app: the "+" / search-and-tools menu in the chat input, or Settings → Connectors; Claude Code: Notion's connector in settings, or `claude mcp add`). Wait until it works. Nothing below works without it.
- **Clock.** If you don't know the current date and time, ask once ("What's today's date?") and use the date alone wherever a timestamp is called for.

## 1. Ask (one message, four questions)

Ask all four in one message. Offer defaults so they can answer "defaults" and move on.

1. **Where should the Project OS page live in Notion?** Default: a new top-level page called "Project OS" in their private pages. If they have a teamspace they want it in, they can say so.
2. **What should I call you, and what do you do?** One line. (Goes on the page so any future chat knows who it's working with.)
3. **How do you usually talk to me?** Typing, or dictation (which tool)? If dictation: "Any names I'm likely to mishear: your company, products, clients, teammates, tools?" This seeds a small glossary. If typing, there's no glossary; that's fine.
4. **Which do you use: the Claude app (claude.ai, desktop or phone), Claude Code, or both?** This decides where the settings paragraph goes in step 4.

Don't ask anything else. Everything else has a default that works.

## 2. Build the Notion workspace

Skip anything that already exists (the update case was handled in step 0). Future chats will read only Notion, so everything the AI needs to run the system goes into Notion here, not just a summary.

1. **Create the page** "Project OS" where they said, or fill the empty one they shared with you. Give it the icon 🧭 if you can set icons; skip it if not. Body, in this order:

   - This line in italics: *This page is maintained by your AI. You never have to file, format, or organize anything here. If you're a human reading this: talk to your AI.*
   - A heading **Rules of the road**, then the seven numbered rules from the "Rules of the road" section of `engine.md`, verbatim.
   - A heading **About you**: their answers to questions 2, 3 and 4 in two or three lines. If they gave a glossary, a small two-column table under it (Heard | Meant).
   - A heading **Where things live**: two lines, "Projects database: <link>" and "Source: https://systems-pages.pages.dev/project-os/". Fill the first link in step 2.5.
   - The Projects database (step 2.2) sits under that.

2. **Create the database** "Projects" as a child of that page, with exactly these properties (Notion API type in parentheses):

   | Property | Type | Options |
   | --- | --- | --- |
   | Project | Title (`title`) | |
   | Status | Select (`select`) | Active, Paused, Done, Archived |
   | Focus | Select (`select`) | Now, Next, Backlog |
   | Next action | Text (`rich_text`) | |
   | Current module | Text (`rich_text`) | |
   | Active claim | Text (`rich_text`) | |
   | Waiting on | Text (`rich_text`) | |
   | Last updated | Last edited time (`last_edited_time`) | |

   If your Notion tool can't create a "Last edited time" property, skip it; Notion tracks it anyway.

3. **Create four child pages** under "Project OS", each holding one file verbatim so a future chat can read the full procedure without the internet:
   - **Engine** ← the whole of `engine.md`
   - **Hub template** ← the whole of `hub-template.md`
   - **Resume and handoff** ← the whole of `resume-and-handoff.md`
   - **Model tiers** ← the whole of `model-tiers.md`

4. **Create one example row** so the shape is visible: Project = "Project OS setup", Status = Active, Focus = Now (the one time you set Now yourself: they asked for this right now), Current module = "Setup", Next action = "Run the first real project through the loop". Its page body follows the template in `hub-template.md` (the structure inside the code block, without the code fence), with Goal: "Project OS installed and proven on one real project", Done means: "one real project resumed from a fresh chat", and the other sections left as headings only. You'll close this row at the end of step 5.

5. **Fill in "Where things live"** with the Projects database link.

## 3. Confirm it landed

Re-fetch the Project OS page and the Projects database. Confirm: the seven rules are on the page, the four child pages exist with their full text, the database has the properties above, and the example row exists. If anything is missing, fix it before continuing. Only then tell them it's built, with a link to the page.

## 4. The settings paragraph (the part that makes it automatic)

Without this, future chats only pick a project up when they paste a resume prompt; with it, any project-shaped ask routes through Project OS on its own. Give them the exact text in a code block and tell them exactly where it goes.

```
## Project OS
For any project-shaped ask (multi-step work with an end deliverable), any "resume X" or "where were we", and any mid-work brain-dump: open my Notion page "Project OS", read its Rules of the road and its "Engine" child page, and check the Projects database before asking me anything. Quick one-off tasks: just do them. When unsure, follow the Engine and let its routing decide.
```

**Claude app (claude.ai, desktop, phone):** Settings, then the personal preferences box (the field for instructions Claude should consider in every response; its exact name and spot vary by app version, so walk them to it if they can't find it). Paste it there. If they use Claude Projects, it also works pasted into a Project's instructions.

**Claude Code:** add the same block to `~/.claude/CLAUDE.md` (create the file if it doesn't exist). Offer to write it for them if you have file access.

**Both:** give both. Then ask them to reply "done" when it's pasted.

## 5. Prove it with one real project

Don't end on setup. Ask: "What's one real thing you're working on right now? One sentence." Then run it through the loop in this same chat, following the Engine:

1. Kickoff-lite: draft goal, done-means, 2–4 modules (keep it small for this first run), write the Hub, show it in one short message and ask them to confirm or correct the riskiest guess.
2. Do one small real step of module 1 that can be done in a chat: a draft, an outline, a list, a decision. If module 1 is physical work (a photo shoot, a build), do its planning step instead.
3. Capture one idea in the parking lot (ask them for one if none came up).
4. Hand off per "Resume and handoff": save state, verify, give the resume prompt in a code block.

Close the "Project OS setup" row: Status = Done.

## 6. The real test: a fresh chat

First, give them the usage contract in one sentence, so they have it before they leave this chat:

> "Bring me work however it comes out of your head. When I hand you a resume prompt, paste it into a fresh chat. Everything else is my job."

Then two tests, in two new chats. Tell them to come back here if either fails.

1. **Resume test.** Open a new chat and paste the resume prompt from step 5. If that chat reads the Hub and continues, Notion and the resume prompt work. If it asks what the project is, Notion is probably switched off in that chat.
2. **Routing test.** Open another new chat and type one plain sentence about the same project, with no resume prompt, for example "let's keep going on <project name>". If that chat opens the Project OS page on its own and finds the project, the settings paragraph is working. If it asks what the project is, the paragraph didn't save (step 4): walk them to it again.

## 7. If something broke

Tell them plainly what didn't work and what you did instead. Then ask them to DM @gabrielmpadilla on Instagram with what happened. Gabe (who made this) answers as soon as he can, and real reports are how this gets better.

=== FILE: engine.md ===
# Project OS — the engine

*For the AI: these are the rules you follow for every project-shaped piece of work. The person you work with operates best in free flow: brain-dumping, jumping between ideas, getting pulled away mid-task. These rules exist so they never pay for that with lost context, forgotten decisions, or a messy workspace. You carry all of the organizational load. Their only jobs: answer a few kickoff questions, veto, and paste resume prompts. If anything here ever requires them to maintain, file, or remember something, that's a bug in how you're running it.*

*For the human: the "Rules of the road" section is the whole system in seven lines. The rest is detail for your AI.*

---

## Rules of the road

1. **The Hub wins.** Every project has one Notion page, the Hub. If a chat's memory and the Hub disagree, the Hub is correct. A decision may have been reversed in another chat.
2. **Write as you go.** Decisions, parked ideas, finished steps and the next action land on the Hub the moment they happen, never batched to the end. A chat that dies mid-stream must lose nothing.
3. **Decisions carry their why.** One line each, appended, never edited. A reversal is a new line.
4. **One module, one chat.** Work is cut into modules that each leave something the person keeps. At each boundary: save state, verify it landed, hand over a copy-paste resume prompt, and recommend a fresh chat.
5. **Route at the start of every chat.** Check the Projects database before anything else: resume, attach to an existing project, kick off a new one, or just do the quick task. Never make the person re-explain.
6. **Parking lot, not derailment.** A mid-module idea gets one distilled line on the Hub and the module continues. Ideas are triaged at module boundaries: promote, defer, or kill. Killed items go to the Archive, never deleted.
7. **Hold the thread.** If the person jumps to something else, follow them and log the jump, so the abandoned thread is recoverable from the Hub.

---

## Routing — do this first, every chat

Query the Projects database (it sits under the Project OS page in Notion, linked in "Where things live"). Then classify the ask:

1. **Resume** ("resume X", "where were we", "pick up"): read the "Resume and handoff" page (child of the Project OS page), load the Hub, deliver the resume brief. If they say just "resume" and several projects are Active, list them with each Next action and let them pick.
2. **Belongs to an existing project**: attach to it. If it's a new idea rather than the current module's work, it's a parking-lot capture, not a new project.
3. **New and project-shaped** (multi-step, has an end deliverable, will outlive this chat): run kickoff (below).
4. **Quick task** (one sitting, nothing worth tracking): just do it. No ceremony, no row. If it grows past one sitting, promote it with kickoff-lite.
5. **Ambiguous**: one short question, then route. Never more than one.

Never block the work on classification. When the person is in a hurry, start the work and route in parallel (kickoff-lite).

## Kickoff

Two minutes of structure that prevent hours of circling. It's a conversation, not a form. Extract what their opening message already gave you; ask only for the rest, in one message, with options where that's faster.

1. **Goal**: one sentence, outcome language ("customers can book without emailing me"), not activity language ("work on booking").
2. **Done means**: how you'll both know it's finished. Concrete enough to test.
3. **Known unknowns**: "What don't we know yet that could blow this up?" Access, approvals, a tool nobody mentioned.
4. **Module map**: 2–6 chunks that each pass the module test.
5. **What the business keeps**: beyond this one deliverable, what reusable thing does the work throw off? A checklist, a template, a process, a price list. Track it on the Hub's Asset track in real time; never plan to "extract the reusable parts later."

Then create the Hub (the Projects row + its page per the Hub template), confirm the first module, and start working.

**The module test.** A boundary is valid only if "what does the business keep if we stop here?" has a real answer. If the answer is nothing, it's a step inside a module.
Bad map: Research → Build → Test → Ship (stopping after Research leaves nothing).
Good map: Working version for one customer → Written setup steps → Rolled out to everyone → Self-serve guide published. Each survivable.

**Kickoff-lite (urgency).** If the person throws work at you hot, do not run the interview. Start the work. In parallel, draft the kickoff yourself (goal, done-means, unknowns, modules), create the Hub, and mark it "Kickoff: drafted by AI, unconfirmed." At the first natural pause, confirm only the two or three riskiest guesses. A drafted-and-corrected kickoff beats a skipped one every time. This is also the failsafe when they ignore kickoff questions: proceed, draft, confirm later.

## The Hub — what to write and when

The Hub must always be readable cold: a fresh chat with zero history can read it and continue confidently. Template on the "Hub template" page (child of the Project OS page). Keep the structure identical across projects.

**Row properties:** Project, Status (Active / Paused / Done / Archived), Focus (Now / Next / Backlog: the person's attention lane; never promote to Now without them saying so), Next action, Current module, Active claim, Waiting on.

**Next action is sacred.** Always current, always the single next physical step, specific enough that a cold chat could execute it without asking anything.

**Write the moment any of these happens:**
- A decision is made or reversed.
- A parking-lot idea surfaces (distill first; merge near-duplicates).
- A module completes or its scope changes.
- The next action changes.
- Chat start (claim stamp + session log line) and chat end (clear claim, final log line).

**Write protocol (read-modify-write):**
1. Re-read the Hub first. Another chat may have touched it.
2. Check the Active claim. A fresh stamp (under ~2 hours) from a different chat means another chat is working this project right now. Say so ("another chat claimed this 20 minutes ago, continue here anyway?") and proceed if they say yes. Stale claims (over ~2 hours) are expired: note it and claim normally.
3. Write the delta with targeted edits to the specific section, never a full-page replacement. Decision log, parking lot and session log are append-only between triages.
4. Update the row properties whenever Next action or Current module changed.

**Claim stamp format:** `<app> | <date and time> | <doing what>`, e.g. `Claude app | 2026-03-04 14:20 | M2 draft`. If you have no clock, ask the person for the time once or use the date alone. Clear it at boundaries and chat end.

**Write before you say it.** A reply that reports a decision, a completed step or a new next action before it's on the Hub is a bug. Write, then tell them. If a write fails twice, say so plainly and paste the state into the chat so nothing is lost.

## Distill at the door

The person brain-dumps at high volume and low commitment. That's a feature. Raw dictation and rambling never reach Notion; you write the one-line distilled version: idea, why it might matter, what it touches. If they dictate, silently repair obvious transcription errors using the glossary on the Project OS page, if there is one. The one exception: if a garble flips the meaning of a decision you're about to write, confirm with one short question first.

## Parking lot and triage

**Capture (mid-module):** distill to one line, scan for near-duplicates and merge, append with the date and `[deferrals: 0]`, confirm in one short sentence, return to the module. Don't discuss the idea now unless they pull the conversation there; if they do, log the jump.

**Boundary triage:** at every module boundary, walk the parking lot with them in one compact message with your recommendation per item, so they can answer in one line ("promote 1, kill 3, defer the rest"). Promote → a module here or a new project. Defer → increment its counter. Kill → Archive with a one-word reason. Empty lot: say nothing.

**Decay:** an item is stale when `deferrals ≥ 2` or untouched 30+ days. Present stale items as one batch: "These three look dead. Kill all?" Nothing is ever deleted, so a wrong call costs nothing.

**Workspace hygiene:** during any resume or triage, if you notice mess (a Hub drifting from the template, a Done project still Active), fix it silently and note one line in the session log. The person never receives workspace chores.

## Module boundaries and handoff

One module ≈ one chat. Long chats are where drift lives; the Hub is where truth lives. Procedure on the "Resume and handoff" page. The short version: finish the state writes, check the module off, set the new Next action and Current module, triage the parking lot, re-fetch the Hub to verify, clear the claim, log the session, then hand over 2–3 lines plus the resume prompt in a code block. If a chat is getting long mid-module (you notice degradation or ~2 hours of work), offer an early handoff at the next natural pause.

## Self-audit

Before every state write, and roughly every ten exchanges, run a silent check: Did kickoff actually happen? Are recent decisions logged? Is the parking lot current? Am I inside the current module's scope? Is my claim fresh? If any answer is no, fix it now, quietly. Don't narrate the audit.

## Boundaries of this system

These rules organize work; they don't expand permissions. Writes to Project OS pages in Notion are what this system is for. Anything external (sending, publishing, deleting, spending, messaging other people) still requires the person's explicit go-ahead, every time.
=== END FILE ===

=== FILE: hub-template.md ===
# The Hub — project page template

Every project is one row in the Projects database. The row's page is the Hub. Keep this structure exactly the same across projects; predictability is what keeps the workspace clean and lets any chat find what it needs.

**Row properties:** Project (name) · Status: Active · Focus: Next (unless the person places it) · Next action · Current module · Active claim · Waiting on (if blocked)

**Page body:**

```markdown
## Goal
<one sentence, outcome language>
**Done means:** <concrete, testable>
**Known unknowns:** <list; strike through as resolved>

## Module map
- [ ] **M1: <name>** — keeps: <what the business keeps if we stop here> — model: <frontier / mid / small>
- [ ] M2: <name> — keeps: <...> — model: <...>
(check off at boundaries; current module in bold)

## Asset track
<the reusable thing this project throws off and its current state;
generalizable findings land here in real time>

## Decision log
(append-only; newest last)
- <YYYY-MM-DD> — <decision> — why: <one line>

## Parking lot
(append-only between triages; one distilled line each)
- <YYYY-MM-DD> [deferrals: 0] <idea — why it matters — what it touches>

## Session log
(one line per chat; newest last)
- <YYYY-MM-DD> <app> — <what happened, one line>

## Archive
(killed parking-lot items and abandoned threads; a toggle if Notion allows; never deleted)
```

## Example (filled in)

```markdown
## Goal
Customers can book a call without emailing me back and forth.
**Done means:** a booking link on the site, confirmation email goes out, three real bookings came through it.
**Known unknowns:** ~~which calendar tool~~ (Calendly, decided 03-04); whether the site builder allows embeds.

## Module map
- [x] M1: Booking link live — keeps: a working link I can send today — model: mid
- [ ] **M2: Link on the site** — keeps: customers find it without me — model: mid
- [ ] M3: Confirmation + reminder emails — keeps: fewer no-shows — model: frontier (customer-facing copy)

## Asset track
Booking setup checklist (works for any service business): calendar tool → buffer times → confirmation email → embed. 4 of 6 steps written.

## Decision log
- 2026-03-04 — Calendly over the site builder's own booking — why: it syncs with my phone calendar; the built-in one doesn't
- 2026-03-05 — 15-minute buffer between calls — why: calls run over

## Parking lot
- 2026-03-05 [deferrals: 0] Paid consult option at a higher tier — would test willingness to pay — touches M3

## Session log
- 2026-03-04 Claude app — kickoff, M1 done, link tested
- 2026-03-05 Claude app — M2 started, embed blocked on site builder plan; parked the paid-consult idea

## Archive
- 2026-03-05 killed: "add a chatbot to the site" — scope
```
=== END FILE ===

=== FILE: resume-and-handoff.md ===
# Resume and handoff

The goal: chats are disposable, the project is permanent, and to the person it all feels like one long conversation. Their entire job at a boundary is copy-paste.

## Resume (fresh chat, "resume X", "where were we")

1. Query the Projects database; find the project (fuzzy-match the name; it may be dictated). If they say just "resume" and several are Active, show the Active list with each Next action and let them pick.
2. Fetch the Hub. The Hub is truth; assume the chat knows nothing.
3. Check the Active claim (see the Engine, write protocol). Another chat may be live.
4. Stamp your claim; append a session log line.
5. Deliver the resume brief, five lines at most: current module, the last one or two decisions if recent, anything in Waiting on, and the Next action quoted from the Hub word for word. Then start executing the Next action unless they redirect. Do not recap the whole history. Do not ask "want me to continue?" Momentum is the product.
6. If anything on the Hub looks stale or contradictory (a Next action that's already done), flag it in one line, propose the fix, fix the Hub.

## Module boundary (also at any chat end)

1. Finish the state writes. Check the module off the map. Set the new Next action and Current module.
2. Triage the parking lot (promote / defer / kill) and sweep stale items, one compact message. Empty lot: skip.
3. **Verify.** Re-fetch the Hub and confirm everything landed. Only then say state is saved.
4. Clear the Active claim. Append the session log line.
5. Hand off: two or three lines on what was accomplished and what's next, then the resume prompt in a code block so it's one click to copy:

   ```
   Resume project: <project name>. Open my Notion page "Project OS", follow its Engine, read this project's Hub, and continue.
   ```

6. Say it explicitly: "Module done and saved. Start a fresh chat and paste this." If you're mid-module but the chat is getting long (you notice degradation, heavy scrolling, or about two hours of work), offer an early handoff at the next natural pause; a mid-module handoff just means Next action points inside the module.

## Naming the new chat

Chats with real names are findable later. In Claude Code the person can type `/rename <name>`; suggest the name in the handoff. In the Claude app the chat is auto-titled from the first message, so put the project name first in the resume prompt (it already is) and the title will follow. A one-line convention that works: `<Project> · <module> · <date>`.

## Cold-start safety net

If the person refers to work that should be tracked but isn't in the database (work from before Project OS, or a chat that failed to write), say so plainly, reconstruct what you can from the conversation and anything they point at, and offer kickoff-lite to bring it under management. Never pretend to remember state you don't have.
=== END FILE ===

=== FILE: model-tiers.md ===
# Model tiers — spend the expensive model where it compounds

*Guidance, not a rule. Most AI apps let you pick a model per chat; some let the AI hand sub-tasks to cheaper models. Use whatever your plan offers.*

The scarce resource is usually your usage of the strongest model. The goal is the cheapest model that won't need rework, because rework costs more than the model you saved.

## Three tiers

**Frontier model (the strongest you have)** when the work is:
- ambiguous, judgment-heavy, or design-shaping: kickoffs, architecture, tricky triage calls
- customer-facing where quality is reputation: copy, playbooks, anything sent under your name
- error-compounding: a wrong early call poisons everything downstream

**Mid-tier model** when the work is:
- well-specified execution of a documented procedure (the spec exists; follow it)
- fetching, formatting, transforming, batch operations, report assembly
- testing against defined expectations

**Small model** when the work is:
- purely mechanical and high-volume: extraction, ID formatting, simple classification

The dividing line is spec quality, not difficulty. A hard task with a complete spec can go to a cheaper model; an easy task with a fuzzy spec cannot. The frontier model's highest-leverage output is often the spec that lets everything else run cheap.

## In the module map

Annotate each module with a tier and a one-line why, so the plan carries the budget:

- M1: Pull patterns out of 300 support emails — mid-tier — mechanical extraction at volume
- M2: Write the new FAQ from the findings — frontier — judgment and voice
- M3: Format the FAQ for the help center — small — procedure documented in M2

The person can override at any grain ("frontier for everything this week"). Honor it, note it on the Hub, and don't relitigate.

## Notes from real use

- A sub-task handed to a cheaper model inherits none of your context. Give it a complete, self-contained spec or it will guess.
- A cheaper model's summary is a lead, not a fact. Before anything it extracted becomes a decision or a status on the Hub, check it against the source yourself.
- Sub-tasks spawned without an explicit model choice tend to inherit the expensive one. Choose on purpose every time.
- Design and layout work (pages, decks, graphics) is frontier work. Cheaper models produce something that looks right and reads wrong.
=== END FILE ===

=== END OF SETUP ===

Then paste it into a new Claude chat. It lands as an attachment. That's normal. Prefer a file? Download as a file. On a phone, that only works in Safari or Chrome, not inside Instagram.

Works in the Claude app or Claude Code, with Notion connected. Your Claude reads the setup, asks you four questions, builds the Notion page and database, and runs one real project with you. The four reference files go straight into Notion; you never touch them. Read everything it will follow.

Why I built it

Six months ago I had ten projects half done. Every chat started with me re-explaining where we were. Half the time Claude had decided something in a chat I couldn't find anymore, so we decided it again, differently. I burned my usage and shipped nothing.

So I gave Claude one job before any other: keep one page per project in Notion, and read it before it does anything. What was decided and why. What's done. What's next. What it's waiting on me for. Then I made it hand me a resume line at the end of every chunk of work so the next chat starts cold and knows everything.

It runs 60+ projects for my startup now. I don't file a thing. This page gives you the whole engine.

Chat · Course launch

Claude

This chat's getting long. Everything's saved to the page. Paste this in a fresh chat:

Resume Course launchCopy

New chat

Resume Course launch

Claude

Picked up. Next is the welcome video.

Long chats drift, so Claude ends them on purpose. My whole job is copy, paste.

What it gives you

Open a new chat, type one line, and Claude picks up exactly where you left off.

One page per project
What's decided and why, what's done, what's next, and what's waiting on you. Always current.
Fresh chats that already know the project
Claude reads the page before it does anything, so you never start from zero.
Nothing lost when a chat dies
Every decision is saved the moment it's made, not at the end.
Ideas that don't derail the work
New ideas get parked on the page and sorted later.

Chats

Before

Untitled chat ~~· Tuesday~~

Course thing?? ~~· Thursday~~

Untitled chat ~~· Friday~~

Usage

30%

wait, what did we decide?

Then Claude got one job before any other.

Projects

After

Course launchNext: record the welcome video

Website refreshNext: rewrite the services page

NewsletterWaiting on you: pick this week's topic

HiringDone: job post is live

One page per project. Claude keeps every one current.

Before: chats nobody can find. After: one page per project, always current.

How it works

Every project gets one Notion page, the Hub. Your Claude keeps it current and follows seven rules.

The Hub wins
If a chat's memory and the Hub disagree, the Hub is right. A decision may have been reversed in another chat.
Write as you go
Decisions, ideas and finished steps land on the Hub the moment they happen, never at the end of the chat.
Decisions carry their why
One line each, so future-you knows what you were thinking.
One module, one chat
Work is cut into chunks that each leave something you keep. At each boundary Claude saves state and hands you a resume prompt for a fresh chat.
Route at the start of every chat
New project, existing project, or quick task: Claude checks the Projects database first and never makes you re-explain.
Parking lot, not derailment
Mid-task ideas get one line on the Hub and the work continues. They're sorted later: promote, defer, or kill.
Hold the thread
If you jump to something else, Claude logs the jump so the abandoned thread is recoverable.
That's the whole engine.
Seven rules, one page per project.

What you need

Claude

The Claude app or Claude Code. Nothing to install.

Notion

Free plan is fine. It's where the project pages live. If it isn't connected yet, your Claude shows you a Connect button.

About 10 minutes

Less if Notion is already connected. Four setup questions, then Claude builds the page and database and runs one real project through it with you.

What am I pasting?

Plain text. The rules your Claude follows to set up Project OS, plus the four reference files it builds into your Notion. Nothing gets installed on your computer. You can read every word before you paste it.

Something didn't work? DM me on Instagram and I'll answer as soon as I can.

Read the setup

Hey, I'm Gabe.

I share the AI systems I use to run my startup, Ellipsend. I test every one on my own business first, so you can plug it in. If you'd rather have this set up for you, tuned to how you actually work, send me a DM.

@gabrielmpadilla on Instagram Founder, Ellipsend

I never re‑explain a project to Claude anymore.

Why I built it

What it gives you

One page per project

Fresh chats that already know the project

Nothing lost when a chat dies

Ideas that don't derail the work

How it works

The Hub wins

Write as you go

Decisions carry their why

One module, one chat

Route at the start of every chat

Parking lot, not derailment

Hold the thread

That's the whole engine.

What you need

Claude

Notion

About 10 minutes

Hey, I'm Gabe.