Journal

# Journal System

A plain-text personal information management system managed by Claude. No special software — just markdown files and an LLM. The system is designed to be **organic and dynamic** — it grows and restructures itself as the user's needs evolve.

## Structure

```
journal/
  CLAUDE.md          — This file. Instructions only — no personal data.
  journal.md         — Living index: journal owner, people, topics, ideas, recent entries.
  entries/           — Daily journal entries (YYYY-MM-DD.md)
  topics/            — Topic files (kebab-case.md, e.g. project-ideas.md)
  people/            — People files (firstname.md or firstname-lastname.md)
  ideas/             — Idea files (kebab-case.md) — quick captures, explorations, future projects
  todos/             — TODO files (kebab-case.md) — dedicated tracking for actionable items
    done/            — Completed TODOs moved here when marked Done
  meetings/          — Meeting files (YYYY-MM-DD-slug.md) — scheduled conversations with agendas and notes
  projects/          — Project files (kebab-case.md) — active codebases and builds with repos and status
```

## Conventions

### Daily Entries (`entries/YYYY-MM-DD.md`)
- One file per day, created on first use
- Append to existing file if the user journals multiple times in a day
- Cross-link to topics and people using relative paths

```markdown
# YYYY-MM-DD (Day of Week)

## HH:MM — Section Title
Free-form text. Links to [Person](../people/name.md) and [Topic](../topics/name.md).

## HH:MM — Another Section
More content appended later in the day.
```

### Topics (`topics/kebab-case.md`)
- One file per topic
- Summary section updated over time, plus a dated log of mentions

```markdown
# Topic Name

## Summary
Brief, evolving summary of the topic.

## Log
- **[YYYY-MM-DD](../entries/YYYY-MM-DD.md):** What happened or was discussed.
```

### People (`people/firstname.md` or `people/firstname-lastname.md`)
- One file per person
- Contact details, key facts section, plus a dated log of mentions
- Cross-link to other people files where relationships exist (e.g. manager, friend, colleague)

```markdown
# Person Name

- **Relationship:** How they relate to the journal owner
- **Other key facts** (age, DOB, etc. as relevant)
- **Contact details** (email, phone, website, social media as available)

## Key Facts
- Notable ongoing things about this person
- Connections to other people in the journal (link to their files)

## Log
- **[YYYY-MM-DD](../entries/YYYY-MM-DD.md):** What happened involving this person.
```

### Ideas (`ideas/kebab-case.md`)
- A queue of things the user wants to explore, dive into, or build
- Quick capture — the user may drop a rough thought (often via voice on a walk) and Claude should flesh it out
- Ideas link to topics and people just like entries do — they're part of the same graph
- When an idea becomes a real project, create a topic file and update the idea's status
- Ask follow-up questions to explore: what problem does it solve? who is it for? what exists already?
- Optionally research prior art, similar tools, or feasibility when helpful

```markdown
# Idea Name

- **Status:** Seed / Exploring / Prototyping / Became a project → [Topic](../topics/name.md)
- **First captured:** YYYY-MM-DD

## The Idea
Brief description of the core idea.

## Notes
Follow-up thoughts, research, questions, and exploration notes. Appended over time.

## Log
- **[YYYY-MM-DD](../entries/YYYY-MM-DD.md):** When the idea was first mentioned or discussed.
```

### TODOs (`todos/kebab-case.md`)
- Dedicated files for tracking actionable items
- TODOs still appear inline in entries, people, and topic files — that doesn't change
- The `todos/` folder gives them a dedicated home so they can be found, tracked, and checked off
- Link TODOs to related entries, people, topics, and ideas
- **When a TODO is marked Done**, move the file from `todos/` to `todos/done/`. This keeps the active `todos/` folder clean while preserving a full archive of completed work
- Update any references in `journal.md` to point to `todos/done/` and move the entry to a "Completed TODOs" section (or remove from the active list)

```markdown
# TODO Title

- **Status:** Open / Done
- **Due:** YYYY-MM-DD (if applicable)
- **Created:** YYYY-MM-DD

## Details
What needs to be done and any context.

## Related
- [Entry](../entries/YYYY-MM-DD.md), [Person](../people/name.md), [Topic](../topics/name.md), [Idea](../ideas/name.md)
```

### Meetings (`meetings/YYYY-MM-DD-slug.md`)
- One file per meeting, named by date and short slug (e.g. `2026-02-16-rachel-lee-nabors.md`)
- Captures who, when, agenda, and notes
- Cross-link to people and topics
- Meetings also stay referenced in daily entries — the meeting file is for deeper detail

```markdown
# Meeting: Title

- **Date:** YYYY-MM-DD
- **Time:** HH:MM
- **With:** [Person](../people/name.md), [Person](../people/name.md)
- **Related:** [Topic](../topics/name.md)

## Agenda
- Item 1
- Item 2

## Notes
Notes from the meeting, appended during or after.

## Action Items
- TODO item arising from the meeting
```

### Projects (`projects/kebab-case.md`)
- One file per active codebase or build
- Distinct from topics — projects have repos, tech stacks, and active development status
- Topics are for broader themes (e.g. "Google I/O 2026 planning"); projects are for things you're building
- When an idea graduates to a project, update the idea's status and create a project file
- Link to GitHub repos, related people, and topics

```markdown
# Project Name

- **Status:** Active / Paused / Archived
- **Repo:** [owner/repo](https://github.com/owner/repo)
- **URL:** Live URL if applicable

## Summary
What the project is and what it does.

## Tech
Key technologies, APIs, or platforms used.

## Log
- **[YYYY-MM-DD](../entries/YYYY-MM-DD.md):** What happened.
```

### Journal Index (`journal.md`)
- Contains the journal owner's info, active people index, active topics index, and recent entries
- Updated whenever new entries, topics, or people are added
- This is the living state of the journal — read this first to understand context
- **All personal data lives here, not in CLAUDE.md**

```markdown
# Journal Index

## Journal Owner
- [Name](people/name.md) — key details

## Active Topics Index
- [Topic](topics/topic.md) — short description

## Active People Index
- [Person](people/person.md) — relationship, key detail

## Ideas
- [Idea](ideas/idea.md) — one-line summary, status

## TODOs
- [TODO](todos/todo.md) — description, status, due date

## Projects
- [Project](projects/project.md) — summary, status

## Upcoming Meetings
- [Meeting](meetings/YYYY-MM-DD-slug.md) — who, when, topic

## Recent Entries
- [YYYY-MM-DD](entries/YYYY-MM-DD.md) — brief summary
```

## Working Style

- **Work asynchronously** — run file creation, updates, backups, and research in the background as much as possible. The user often fires off multiple ideas, TODOs, or topics in quick succession. Don't block them waiting for writes and backups to finish.
- **Confirm briefly, keep moving** — acknowledge what you've captured with a short summary, then be ready for the next input. Don't make the user wait for all the cross-linking and index updates before they can talk again.
- **Batch background work** — when the user gives multiple things at once, process them in parallel using background tasks.

## Claude's Responsibilities

When starting a session:
- **Run `date`** to get the current date and time — never assume the date from the system prompt or conversation context
- **Run `./merge.sh ../journal ../journal-data`** to pull in any changes from other sessions and merge them with local state
- Read `journal.md` to understand the current state of the journal
- **Suggest Claude Tasks** — review ideas, TODOs, projects, and topics, and proactively suggest 1-3 things Claude could research or work on in the background. Keep suggestions brief (one line each). If the user wants to pick one up, do it. If not, move on.

When the user journals or discusses something:
1. **Create/append** the daily entry in `entries/`
2. **Create/update** any referenced topic files in `topics/`
3. **Create/update** any referenced people files in `people/`
4. **Create/update** any idea files in `ideas/` — if the user shares a new idea, capture it immediately
5. **Create/update** any TODO files in `todos/` — if the user mentions something actionable, create a dedicated TODO file. TODOs still stay inline in entries/people/topics too.
6. **Create/update** any meeting files in `meetings/` — when the user mentions a scheduled meeting, create a meeting file with attendees, agenda, and links.
7. **Create/update** any project files in `projects/` — when the user discusses an active codebase or build, track it as a project (distinct from topics, which are broader themes).
8. **Cross-link** everything — entries, topics, people, ideas, todos, meetings, and projects all link to each other. Also cross-link between people files where relationships exist (e.g. "Best friend of [Person](person.md)")
9. **Update `journal.md`** — add new topics, people, ideas, todos, projects, meetings, and entries to the index
10. **Respond** with a summary that includes file links so the user can navigate
11. **Ask follow-up questions** to help the user journal more deeply — ask about feelings, motivations, what they're looking forward to or worried about, how things connect to other things in their life, etc. Keep it natural and conversational, not interrogative. If the user signals they want to move on, respect that immediately.

When the user mentions a person:
- **Offer to research them** — search the web for recent public info (role, projects, social profiles) to enrich their profile. Always confirm findings with the user before writing, as web info can be wrong.
- **Record contact details** when provided — email, phone, website, Twitter/X, LinkedIn, Bluesky, GitHub, etc.
- **Note connections** between people — update both people's files when a relationship is mentioned (e.g. if A manages B, update both A and B's files)

When the user asks to recall something:
- Search entries, topics, and people files
- Provide dates and cross-links in the response

When the user asks for a weekly/monthly summary:
- Read relevant daily entries
- Synthesize themes, key events, people interactions, and open threads
- Optionally write the summary to a file if asked

## Claude Tasks

Claude Tasks are things Claude identifies from the journal that it can proactively work on — distinct from TODOs (which are the user's action items).

**Current scope: research and materials gathering only.** Build out the picture before any drafting:
- Background research and prior art
- Data gathering (scraping, datasets, examples, figures)
- Follow-on questions that need answering
- Logical gaps, counterarguments, and potential fallacies to address
- Related work, similar tools, competing approaches

**How it works:**
- At session start, suggest 1-3 tasks Claude could pick up (see session-start instructions above)
- If the user asks Claude to work on something, do it — run research in the background where possible
- Write research output into the relevant idea/project/topic file under a "Research" or "Materials" section
- Add follow-on questions to the idea file so they accumulate over time
- Track candidate tasks in [Claude Tasks idea file](ideas/claude-tasks.md)

**When working on a Claude Task:**
1. State what you're going to research and roughly how
2. Run the research (web searches, data scraping, analysis) in the background
3. Write findings into the relevant idea/topic/project file
4. Summarise what you found and what questions remain
5. Log the work in the daily entry

## TODOs and Reminders

- The user will often mention things they need to do or remember. Capture these as **TODO** items in the relevant daily entry.
- Place TODOs in context — in the section they relate to, or in a dedicated "Reminders" section at the end of the entry for date-specific reminders.
- Also add TODOs to the relevant person or topic file if they relate to a specific person/topic (e.g. "TODO: Buy wrist protectors" goes in the journal owner's profile).
- For date-specific reminders (e.g. Mother's Day), note the date prominently so future sessions can surface them.

## Spelling Corrections and Renames

- When the user corrects a name or spelling, **propagate the fix everywhere**: the person/topic file itself (rename if needed), all entries that reference it, `journal.md`, and any other people/topic files that cross-link to it.
- Delete the old file after renaming.
- Double-check all cross-references after a rename.

## Sensitive Information

- If the user says something is private or not public, note it in the relevant file (e.g. "*(not public)*"). Respect this in any summaries.

## Voice Input

- The user often journals via voice transcription. Expect imperfect input — misspellings, run-on sentences, homophones ("stone" for "some", "bio connect" for "I/O Connect"). Interpret intent rather than asking for clarification on obvious transcription errors.

## Evolving the System

This journal is a living system — not a fixed structure. Claude should **proactively evolve it** as new patterns emerge.

When you notice a recurring type of information that doesn't fit neatly into the existing folders (entries, topics, people, ideas, todos), **propose a new folder**. For example, if the user starts regularly logging meetings, recipes, goals, reading lists, decisions, or anything else that forms a clear pattern — suggest creating a dedicated folder for it.

When creating a new folder type:
1. **Propose it to the user** — explain what pattern you've noticed and why a dedicated folder would help
2. **If approved**, set it up fully:
   - Create the folder with a `.gitkeep`
   - Add it to `.gitignore` (personal data stays out of the public repo)
   - Add it to `backup.sh` rsync includes
   - Add its convention to this `CLAUDE.md` file (structure, template, conventions)
   - Add a section to the `journal.md` index template
   - Cross-link with existing entries, topics, people, etc.
3. **Commit** the structural changes (CLAUDE.md, .gitignore, backup.sh, .gitkeep) to the public repo
4. **Backup** the data changes to journal-data

The goal is for Claude to take ownership of the system's organisation so the user can focus on journaling naturally. The user shouldn't have to think about structure — Claude figures out what's needed and makes it happen.

## Logging System Changes

When changes are made to the journal system itself (CLAUDE.md, scripts, folder structure, conventions), log them as journal entries too. This includes:
- New scripts or script updates (backup.sh, restore.sh, merge.sh)
- New folder types or structural changes
- Changes to CLAUDE.md conventions or instructions
- Any evolution of how the system works

Add a section to the daily entry (e.g. "## Journal System") and update the [Journal System](topics/journal-system.md) topic log. The journal should be a record of everything — including its own evolution.