Designing your projects for ingestion

Once you start emailing Deck from scripts and webhooks, the projects you set up up front matter more than they do when you're forwarding mail by hand. The right split keeps snapshots from colliding, makes routing unambiguous, and lets you ask cross-project questions later.

Two organizing ideas

There are two kinds of projects you'll want:

• A meta project — usually called Brain. Your calendar, your work habits, your decision frameworks, newsletter digests, anything about you. This is what Deck reads when you ask "what's on my plate today?".
• One domain project per area of work. Pipeline (CRM-style), Product, Fundraising, Family, Hiring — whatever maps to how you actually carve up your week.

Don't try to invent ten projects on day one. Start with Brain plus one or two others; add new ones as you find yourself sending the same kind of email to the wrong place.

Playbook: your runbook for the assistant

A playbook is a markdown file inside a project that codifies how you want Deck to handle a particular kind of work or recurring decision. Think of it like a runbook the assistant follows: less "who I am" and more "when this kind of thing lands, here are the steps."

Without a playbook, you end up re-briefing Deck every time — "compare this CIM against my criteria, pull the management bios, flag what's missing, and give me three sharp questions." With a playbook, you forward the CIM and write "triage this using the New-Deal playbook in Brain." Deck already knows the steps.

Distinguish a playbook from the two other static-file types:

• Seed / reference files describe static facts about you — work habits, communication style, the firms in your pipeline.
• Decision frameworks are the criteria themselves — what makes a deal a yes, what makes an investment a pass.
• Playbooks tie those criteria to a workflow. They say "when this input arrives, apply these criteria in this order and return this shape of output."

Playbooks usually live in Brain (when the workflow is about how you process things) or in the domain project that owns the work (a pipeline/ playbook for triaging deals, a hiring/ playbook for screening candidates).

What goes in a playbook

At minimum: a purpose, the inputs it expects, the steps, the output shape, and ideally an example of a good vs. bad result. Keep it short — one page is plenty.

# Playbook: Triage a new CIM

## Purpose
Quick first read on inbound deals. Reject obvious passes, flag the three best
candidates for a second look.

## Inputs
A forwarded CIM, deck, or memo.

## Steps
1. Compare against my criteria in `decision_framework.md`.
2. Pull the management bios and last round.
3. Identify the three sharpest questions to ask the banker.
4. Flag anything missing from the materials.

## Output
- A one-paragraph thesis
- Three risks
- Three questions
- Verdict: pass / second look / dig in

Reference the playbook by name in your email instruction — "triage this using the New-Deal playbook in Brain" — so Deck knows which workflow to follow. A named reference is more reliable than hoping Deck infers which file applies.

A real example layout

Projects · Workspace

SeedPlaybookContent

Brain

About you

profile.md

work_habits.md

decision_frameworks.md

playbook_triage_new_cim.md

playbook_monday_digest.md

Pipeline

CRM-shaped work

hubspot_snapshot.md

acme — pricing pushback.md

playbook_log_new_meeting.md

Product

Roadmap & feedback

roadmap.md

feature_requests.md

Family

Life outside work

school_schedule.md

household_logistics.md

Each project gets seeded with a handful of stable files (preferences, frameworks, reference data) plus a playbooks/ folder where it makes sense, and then grows from whatever you forward, CC, or pipe in from scripts. Playbooks naturally cluster in Brain (they describe how you process things), with project-specific playbooks living alongside the work they govern.

Seed files are surprisingly important. Two paragraphs about your work habits in Brain is the difference between Deck saying "you have a 2pm meeting" and "you have a 2pm meeting, but that's during your usual deep-work block."

How routing actually works

Deck reads the whole message — subject, body, attachments, and the thread it came from — to decide which project a piece of mail belongs to. A subject prefix isn't required and Deck won't refuse to route without one. That said, a convention like Brain — … or Pipeline — … is useful for your own organization: it makes intent unambiguous when you skim your send folder, and it keeps long-running snapshot jobs tidy.

Subject pattern	What it does
Brain — Calendar update Mar 25	Clear signal — Deck files into Brain. The prefix removes ambiguity.
Pipeline — Meeting prep: Acme	Same idea, scoped to Pipeline.
Daily Brief — March 25	Useful naming for cross-project digests you can filter later in Gmail.
(no prefix) Quick question about Acme	Deck figures out routing from the body, the attachments, and any project names mentioned.

When you script things, lean on the prefix not because Deck needs it but because you will — six months in, a tidy send-folder is the difference between trusting your pipeline and rebuilding it.

A folder layout for your seed files

Deck projects are flat — each project holds a single list of files, no subfolders inside. If you keep your seed files in a repo (recommended, especially if you want to back them up or run with GitHub Actions), mirror that flatness locally and use filename prefixes to keep playbooks identifiable:

your-deck-setup/
├── prompts/
│   └── system_prompt.md          ← optional custom system prompt
├── brain/
│   ├── profile.md
│   ├── work_habits.md
│   ├── communication_style.md
│   ├── decision_frameworks.md
│   ├── playbook_triage_new_cim.md
│   └── playbook_monday_digest.md
├── pipeline/
│   ├── pipeline_overview.md
│   └── playbook_log_new_meeting.md
├── product/
│   └── product_strategy.md
├── fundraising/
│   └── fundraising_context.md
├── jobs/
│   ├── calendar_sync.py
│   ├── hubspot_sync.py
│   ├── newsletter_sync.py
│   └── new_meeting_webhook.py
├── config.yaml                   ← which jobs are enabled, subject templates
└── README.md

Each top-level folder is one Deck project. The files inside upload as a flat list — playbook_* is just a filename convention so you can tell them apart at a glance. Run the jobs in jobs/ on a schedule. Edit config.yaml when you want to toggle a job on or off.

Pitfalls to avoid

• Don't make a project per email type. "Daily briefings", "Weekly summaries" are not projects; they're outputs. The project is Brain.
• Don't pipe two unrelated sources into the same snapshot. "Brain — Calendar + HubSpot" will route fine but Deck has to disentangle them later. Send two emails.
• Don't be cute with subject lines. "Brain" is parseable; "🧠 morning data" is not.
• Don't forget seed context. Snapshots are only as good as the static files they sit alongside.

The single highest-leverage thing you can do once your projects are set up: write a playbook for any work you do more than twice. It turns repeat decisions into one-line emails.

Next

• Scheduled snapshots — the cron pattern that feeds these projects.
• Webhook-driven context — the event pattern that feeds these projects.
• Drive Deck with Claude — let Claude write your seed files and jobs.