context/projects.md

projects.md is so Claude can recognise project shorthand and topic mentions without you spelling each one out. When an email mentions “the Q2 review” or “the migration”, Claude should already know which workstream that is and what its current state is.

The file is also the input to focus recommendations in the morning brief — Claude can’t usefully say “spend time on X today” without knowing what X is and what stage it’s at.

Scope: internal projects only

If you’re using the clients/ directory structure described in section 24, this file covers internal and non-client projects only. Client engagements live in their own clients/<name>/context.md files. Mixing client work into shared projects.md defeats the bleed-prevention model.

Examples of what belongs here:

• Internal product development you’re driving
• Cross-team initiatives you’re contributing to
• Thought leadership or content workstreams
• Internal change programmes
• Recruiting or team-building efforts
• Anything that isn’t a billable client engagement

If you don’t use a clients/ directory — your role doesn’t have distinct client engagements — then this file covers everything active, the way it would in any single-engagement role.

What to include

• Project name and acronym, if you use one
• A one-line description of what the project is
• Current state — usually one phrase (“MVP scaffolded”, “in editorial review”, “awaiting sign-off”)
• Key collaborators
• Next milestone with a rough date if known
• Any standing context — decisions made, constraints, things that would otherwise need re-explaining

What to exclude

• Client engagements (these go in clients/<name>/context.md)
• Content that already lives in the project’s own documents — link or reference, don’t copy
• Dead projects (move them to a completed.md archive if you want history; or just delete)
• Projects you’re tangentially involved in but don’t drive — the criterion is whether emails about it would benefit from Claude knowing the context
• Sensitive deal information that shouldn’t be in a local markdown file

Template

# Active Projects (Internal)

## [Project name / acronym]
- What: [one-line description]
- State: [current phase, recent milestone, or status]
- Collaborators: [names — typically 3-5 most relevant]
- Next milestone: [what and roughly when]
- Key decisions made: [things that would otherwise need
  re-explaining, e.g. "decided to scope to internal users first"]

## [Next project]
- What: ...
- State: ...
- Collaborators: ...
- Next milestone: ...
- Key decisions made: ...

## [...continue for each active internal project]

How many projects belong here

Three to six is a good range for internal projects. Fewer than three usually means you haven’t captured everything; more than six usually means you’re either splitting things too granularly or you’re overcommitted on internal work alongside client engagements.

Why “key decisions made” matters

The most useful field in the template, and the most overlooked.

Without it, Claude treats each email mention of a project as if the conversation is starting from zero. With it, Claude knows that the project decided not to pursue option B in February, and a draft reply doesn’t accidentally re-open that decision.

Capture the decisions that would be costly to re-explain: scope choices, technology choices, partner choices, anything that took a meeting to settle and that you’d be annoyed to argue again.

How often to update

Monthly. Plus an immediate update whenever a project changes state significantly — milestone hit, decision changed, scope shifted, collaborator added or removed. State that’s a month stale produces drafts that reference yesterday’s truth.

A useful prompt at the end of each month: “look at projects.md and tell me what’s likely out of date based on the last 30 days of inbox content.” Claude can’t always tell, but it’ll surface the obvious gaps.

Where client projects go instead

Each active client engagement gets its own folder under clients/:

clients/
├── client-a/
│   ├── CLAUDE.md
│   ├── context.md          ← engagement state, decisions, contacts
│   ├── inputs/
│   └── outputs/

The clients/<name>/context.md follows the same template shape as this file — project name, state, collaborators, milestones, key decisions — but scoped to that engagement only. Section 24 covers the full per-client folder structure and the session activation pattern that controls which client is loaded at any moment.