The owner's facts and context. Changes occasionally. The stable "what each project is" lives here; live status and next-actions live in 200 Projects/000 Projects Dashboard.md — don't duplicate them.
Not yet set up? Run
/onboard. It interviews the owner and rewrites this whole file — profile, projects, and cadences — from their answers. Everything below is a working default plus guidance on what belongs in each section.
Who the owner is, in a short paragraph or two.
What to put here: what they do, where they are, what they're building or working toward, and any standing context an assistant would otherwise have to ask about every session — family situation if it affects their time, a second job, a visa status, a health constraint, a hard commitment on their calendar.
Include the things that bound decisions, not just the things that describe them. "Works full-time and builds on evenings" changes what advice is realistic. "Has two young kids" changes what a free weekend means. An assistant that doesn't know these will confidently suggest things that were never possible.
Leave out anything that would be awkward if the vault were read over your shoulder, unless the vault is private and you've decided otherwise.
One row per thing you're actually carrying. Live status lives in the Dashboard — this table is the stable "what is it" frame.
| Project | Description | Status |
|---|---|---|
Keep this short. Five active projects is a lot; ten means several are lying about being active. Anything you haven't touched in a month is dormant — mark it so, and let that be an honest signal rather than a source of guilt.
Statuses worth using: active, ongoing (no end date — probably an Area), dormant (parked, could revive), blocked (waiting on someone else).
A short section per project: what it is, the stack or the shape of the work, who else is involved, and any standing constraint.
Enough that an assistant reading only this file understands what the project is without opening the folder. Live status does not belong here — it goes stale, and the Dashboard and Activity Logs already own it.
Project name — one line on what it is and why it exists. The stack, tools, or method. Who else is involved and what they own. Any standing constraint that bounds every decision on it (a budget cap, a deadline, an NDA, a rule like "evenings only"). Live status → see 200 Projects/<name>/.
| Cadence | Duration | Focus |
|---|---|---|
| Daily (morning) | 5 min | Process inbox, set 3 priorities, write in journal |
| Weekly | 30 min | Empty inbox, review all projects, update next_actions |
| Monthly | 1 hour | Review areas, archive completed projects |
| Quarterly | 2 hours | Strategic review, kill or accelerate projects |
Pick the ones you'll actually do. A cadence you skip is worse than one you never claimed, because it turns the vault into a record of your own non-compliance. If only the daily and weekly survive contact with your real life, keep those two and delete the rest.
Set the weekly review on a specific day and say which one here — "sometime on the weekend" is how it stops happening.
Protected time. If there are hours or days that are not available for work — a sabbath, family evenings, a standing commitment — write it here as a rule, not a preference. An assistant that knows about it will stop suggesting Sunday deadlines, and will read a quiet weekend as designed rather than as slippage.