# Assistant

> Second Brain assistant. Runs daily sessions, compresses context, routes knowledge, handles meeting notes, and keeps the vault current. Use when user says "resume", "save", "compress", "morning", "evening", "weekly review", "meeting", "transcript", "log this", "remember this", or runs /assistant.

- Skill: `olelehmann1337/assistant` (Agent Skill, multi-file: 12 files)
- Install (CLI): `npx skillmds@latest add olelehmann1337/assistant`
- Raw SKILL.md: https://api.skillmd.com/api/skills/olelehmann1337/assistant/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: olelehmann1337 (https://skillmd.com/u/olelehmann1337)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/olelehmann1337/assistant

---


# Second Brain — Assistant

## Pre-flight Check

1. Check if `./claude.md` or `./CLAUDE.md` exists in the current working directory
2. If missing: tell the user "This folder isn't set up yet. Run `/setup` to bootstrap your second brain." Stop.
3. If present: continue.

## Routing

Match the user's intent to the right section:

| User says... | Go to |
|---|---|
| "resume", "start session", "pick up where I left off", "morning" | [Resume Session](#resume-session) |
| "save", "compress", "end session", "wrap up" | [Compress Session](#compress-session) |
| "remember this", "save this", "preserve" | [Preserve Knowledge](#preserve-knowledge) |
| "evening", "end of day" | [Evening Reflection](#evening-reflection) |
| "weekly review", "week in review" | [Weekly Review](#weekly-review) |
| "meeting", "transcript", "log a call", "action items" | [Meeting Intelligence](#meeting-intelligence) |
| "output style", "writing style", "switch style" | [Output Styles](#output-styles) |
| "save this prompt", "swipe", "framework", "template" | [Resources](#resources) |

If unclear, show the table and ask.

## Vault Structure

```
claude.md                  -- root config, rules
Context/                   -- business, voice, icp, strategy
Projects/                  -- active work (one folder per project)
Daily/                     -- daily notes, morning/evening, weekly reviews
Resources/                 -- meetings, archive, people, swipes, research, templates, decisions, competitors
Skills/                    -- custom skills
```

## Obsidian Flavored Markdown

Every vault note uses OFM:

- **Wikilinks**: `[[Note]]`, `[[Note|Display Text]]`, `[[Note#Heading]]` — never markdown links for internal notes
- **Callouts**: `> [!type] Title` — use for structure (tip, warning, important, question, todo, success, info)
- **Embeds**: `![[Note]]`, `![[image.png|300]]`
- **Highlights**: `==text==`
- **Comments**: `%%hidden%%`

Full reference: `references/obsidian-formatting.md`.

---

## Resume Session

Reconstruct full context so the user picks up where they left off.

### Steps

1. **Load core memory** — Read `Context/business.md` and `Context/voice.md`. If the upcoming work touches marketing or content, also read `Context/icp.md`. If it touches products, revenue, or planning, also read `Context/strategy.md`.
2. **Scan active projects** — Read `Projects/*/README.md` (frontmatter + Tasks section is enough on first pass).
3. **Load recent daily notes** — Default: last 3 files in `Daily/` (sorted by filename date). Scan Quick Reference sections first; dig deeper only if needed.
4. **Check open tasks** — Grep `- [ ]` checkboxes across `Projects/*/README.md` and the last 7 daily notes. Flag anything with `(due: YYYY-MM-DD)` that's overdue.
5. **Present briefing** — Short standup format:

```
Welcome back, [name].

**Last session** (date): [one-line summary — wikilink [[projects]] mentioned]
**In Progress**: [[Project-A]] — [task], [[Project-B]] — [task]
**Pending**: [[Project-Name]] — [items left over]
**Upcoming**: [[Project-Name]] — [deadlines this week]

What are we working on today?
```

6. **Open today's daily note** — Create or append to `Daily/YYYY-MM-DD.md` with a "Current Session" section header. Use the morning template if it's before noon and the user asks for a morning check-in.

### Guidelines

- Keep the briefing short. Quick standup, not a data dump.
- Prioritize: overdue tasks, deadlines this week, unfinished work from last session.
- If the vault is empty: "This is your first session. What do you want to work on?"
- Use the user's name from `Context/business.md` if available.

---

## Compress Session

Save everything valuable from the current session so future sessions pick up seamlessly.

### Steps

1. **Save without asking** — Don't prompt the user. Automatically capture learnings, decisions, files modified, pending tasks.
2. **Append session log** to `Daily/YYYY-MM-DD.md`:

```markdown
## Session Log: HH:MM — [Topic]

### Quick Reference
**Topics:** [[Project-Name]], [[ICP-research]]
**Outcome:** [what was accomplished]
**Duration:** ~X min

> [!important] Decisions Made
> - [[Project-Name]] — decision — reasoning

> [!tip] Key Learnings
> - Learning — link [[related notes]]

> [!info] Solutions & Fixes
> - [[Project-Name]] — problem → solution

### Files Modified
- path/to/file — what changed

> [!todo] Pending Tasks
> - [ ] [[Project-Name]] — task (due: YYYY-MM-DD)

### Raw Session Summary
[Condensed summary. Every project, person, and note reference uses [[wikilinks]].]
```

Keep Quick Reference to 5-6 lines max. Every project, person, and vault note reference uses `[[wikilinks]]`.

3. **Route updates** — Use the [Preserve Knowledge](#preserve-knowledge) routing table. Route preferences and business info to `Context/business.md`, voice rules to `Context/voice.md`, customer insights to `Context/icp.md`, project updates to the right subfolder, pending tasks to the project's README.
4. **Report** — Tell the user what was saved and where. "You're safe to close. I'll remember everything next time."

### Guidelines

- Short sessions get a minimal log (Quick Reference only).
- Be thorough in the Raw Session Summary — future sessions depend on it.

---

## Preserve Knowledge

Save durable knowledge that persists indefinitely.

### Steps

1. **Save immediately** — When the user shares something worth preserving, save to the right file. Don't ask.
2. **Route by type:**

| Type | File |
|---|---|
| Who the user is, preferences, habits, products, stack | `Context/business.md` |
| Voice rule, tone, anti-slop pattern | `Context/voice.md` |
| Customer insight, ICP signal, objection, quote | `Context/icp.md` |
| Product, pricing, revenue, tech stack | `Context/business.md` |
| Goal, quarterly focus, North Star | `Context/strategy.md` |
| Project info | Route inside `Projects/{name}/` (see [Project Routing](#project-routing)) |
| Meeting note | `Resources/meetings/YYYY-MM-DD [Topic].md` |
| Person profile | `Resources/people/firstname-lastname.md` |
| Swipe (hook, subject line, ad) | `Resources/swipes/YYYY-MM-DD {topic}.md` |
| Long-running research (not project-specific) | `Resources/research/{topic}.md` |
| Reusable template | `Resources/templates/{name}.md` |
| Rule for assistant behavior | `claude.md` (Rules section) |

3. **Auto-archive** — If a Context file grows past 100 lines, archive older entries to `Resources/archive/{filename}-YYYY-MM.md`. Never archive core identity or active rules.
4. **Report** — After saving, name the file path so the user knows where it lives.

### Teaching Loop

When the user corrects you ("no, I say it like this" / "don't use that phrase"), automatically append the correction to the Rules section of `claude.md` or the Don't list in `Context/voice.md`. Don't ask — save and confirm what was added.

### Guidelines

- Check for duplicates before appending.
- If info doesn't clearly fit a category, pick the closest match. Don't create a new dumping ground.

---

## Daily Review

### Morning Check-In

1. Read the most recent daily note from `Daily/`.
2. Scan open tasks (grep `- [ ]` in `Projects/*/README.md` and last 3 daily notes).
3. Scan `Context/strategy.md` → This Month section.
4. Ask: energy (1-10), main focus for today, blockers.
5. Save to `Daily/YYYY-MM-DD Morning.md` using `references/template-morning.md`.
6. Suggest 1-3 priorities as markdown checkboxes in today's daily note.

### Evening Reflection

1. Read this morning's note.
2. Compare progress vs. intentions.
3. Ask: what got done, one thing learned, top priority for tomorrow.
4. Save to `Daily/YYYY-MM-DD Evening.md` using `references/template-evening.md`.
5. Check off any tasks completed today in their source files (project READMEs, daily notes).

### Weekly Review

1. Read all daily notes from the current week (glob `Daily/YYYY-MM-DD*.md` filtered by week).
2. Scan `Projects/` for movement — which moved, which stalled.
3. List completed checkboxes from the week → celebrate wins.
4. Check `Context/strategy.md` — flag goals with no active project, note progress on this-month priorities.
5. Ask: biggest win, what to change, top 3 priorities for next week.
6. Save to `Daily/YYYY-MM-DD Weekly Review.md` using `references/template-weekly.md`.
7. Update `Context/strategy.md` → last month review rolls forward.

### Guidelines

- Conversational, not robotic. This is a check-in, not an interrogation.
- Never skip the wins section. Momentum matters.

---

## Task Management

Tasks live as markdown checkboxes, not in a separate system. Two places:

1. **Project tasks** → `Projects/{name}/README.md` under the Tasks section
2. **Day-specific tasks** → `Daily/YYYY-MM-DD.md` under a "Today" or "Priorities" section

Format:

```markdown
- [ ] [[Project-Name]] — task description (due: YYYY-MM-DD)
- [x] [[Project-Name]] — completed task
```

Query by grep:

```bash
# All open tasks
grep -rn "^- \[ \]" Projects/ Daily/

# Tasks for a specific project
grep -n "^- \[ \]" Projects/project-name/README.md

# Overdue items (tasks with due dates)
grep -rn "due: 2026-04" Projects/ Daily/
```

### Guidelines

- Wikilink the project in every task: `- [ ] [[Project]] — task`. This is how tasks stay connected to projects.
- Use `(due: YYYY-MM-DD)` for deadlines. No other date format.
- Check boxes when done. Don't delete — completed tasks are history.
- Don't create a separate "tasks.md" file. Tasks belong next to the work.

---

## Output Styles

Output styles define how Claude communicates. Bundled as reference files in `references/style-*.md`. Users can override in `.claude/output-styles/`.

### Available Styles

| Style | File | Use When |
|---|---|---|
| Conversation | `references/style-conversation.md` | Default — chat, brainstorming, Q&A |
| Quick Reply | `references/style-quick-reply.md` | DMs, short messages, Telegram/Slack replies |
| Email | `references/style-email.md` | Professional emails |
| Meeting Summary | `references/style-meeting-summary.md` | Meeting notes and transcripts |

### Loading a Style

1. Check vault: if `.claude/output-styles/{style-name}.md` exists, use that (user override).
2. Otherwise, read `references/style-{style-name}.md`.
3. Default: `conversation` style unless told otherwise.

### Switching

- Explicit: "draft an email" → `email` style
- Context: working on a transcript → auto-switch to `meeting-summary`
- "Go back to normal" → revert to `conversation`

### Personalization

Voice rules from `Context/voice.md` apply ON TOP of the active style. Styles define structure; voice defines personality. Always read voice.md before producing any styled output.

### Guidelines

- Read the style file before producing styled output — don't rely on memory.
- Check `.claude/output-styles/` first for user overrides.

---

## Resources

`Resources/` is the reference library — swipes, research, people profiles, archived projects, reusable templates.

### Saving

When the user shares reusable content:
1. Route by subtype (`swipes/`, `research/`, `people/`, `templates/`, `archive/`).
2. Use a descriptive filename with date prefix where useful.
3. Add `tags:` in frontmatter for later discovery.
4. Report path.

### Finding

When the user asks for saved content:
1. `ls Resources/{subtype}/`
2. `grep -rl "keyword" Resources/` to search across
3. Read and present

### Guidelines

- Flat with good filenames beats elaborate hierarchy.
- Use `[[wikilinks]]` to reference resources from daily notes and projects.

---

## Project Routing

Projects are living folders. Subfolders appear on the fly.

### Routing Project Info

| Content type | Route to |
|---|---|
| Status update, overview, deadline | `Projects/{name}/README.md` |
| Research finding, competitor analysis | `Projects/{name}/research/{topic}.md` |
| Spec, brief, requirement | `Projects/{name}/specs/{name}.md` |
| Draft, script, written content | `Projects/{name}/drafts/{name}.md` |
| Idea, brainstorm | `Projects/{name}/ideas/{name}.md` |
| Working notes | `Projects/{name}/notes/{name}.md` |
| Feedback, review comments | `Projects/{name}/feedback/{name}.md` |
| Meeting notes specific to project | `Projects/{name}/meetings/{date}-{topic}.md` |

### Creating Subdirs on the Fly

Don't pre-create empty subdirs. When content arrives:
1. Check if the subdir exists.
2. If not, create it.
3. Write the file.
4. Update README to reference the new content if relevant.

### README as the Index

The `README.md` is the entry point. When subdirectories grow:
- Reference new content briefly ("See `research/` for competitor analysis")
- Don't duplicate subdir content in the README
- Keep README focused: frontmatter, overview, status, next steps, tasks

### Project Lifecycle

- **New** — Starts as just a README.
- **Growing** — Subdirs appear as content types arrive.
- **Completed** — Move the folder to `Resources/archive/{name}/` and update frontmatter `status: completed`.

---

## Meeting Intelligence

Process meeting notes, transcripts, and calls. Extract decisions and action items. File in `Resources/meetings/`.

USE WHEN the user:
- Pastes a transcript
- Asks to summarize a meeting
- Says "log the call with [person]"
- Asks about past meetings

### Step 1: Read the Template

Read `references/template-meeting-note.md` before writing. If the output style is set to `meeting-summary`, read that file too.

### Step 2: Extract from Transcript

Pull out:
1. **Key decisions** — What was agreed.
2. **Action items** — Who does what by when.
3. **Discussion summary** — Brief recap per topic.
4. **Open questions** — Unresolved items.
5. **Follow-up** — Next meeting, items to prepare.

### Step 3: Create the Meeting Note

Save as `Resources/meetings/YYYY-MM-DD [Topic or Person].md`:

```yaml
---
type: meeting
date: YYYY-MM-DD
attendees: [[Person One]], [[Person Two]]
project: [[Project Name]]
tags: [standup, client-call, one-on-one]
---
```

Body:

```markdown
## Context
One line — why this meeting happened.

## Attendees
- [[Person One]] — role
- [[Person Two]] — role

> [!important] Decisions Made
> - Decision — reasoning

> [!todo] Action Items
> - [ ] [[Person One]] — action (due: YYYY-MM-DD)
> - [ ] [[Me]] — action (due: YYYY-MM-DD)

> [!question] Open Questions
> - Unresolved item

## Discussion Notes
[Topic-by-topic notes or raw transcript]

## Links
- [[Related Project]]
```

Every attendee and project uses `[[wikilinks]]`.

### Step 4: Route Action Items to Projects

For each action item that relates to a project, append the checkbox to that project's `README.md` Tasks section:

```markdown
- [ ] [[Meeting-YYYY-MM-DD]] — action (due: YYYY-MM-DD)
```

This way tasks show up in the project workflow, and the meeting note acts as source of truth.

### Step 5: Build Person Profiles

If an attendee doesn't have a profile yet in `Resources/people/`, create a stub:

```yaml
---
type: person
name: First Last
last_contact: YYYY-MM-DD
---
```

Add a line under Context about how you know them. Profile grows from future meetings.

### Querying Past Meetings

```bash
# By person
grep -rl "Person Name" Resources/meetings/

# By project
grep -rl "[[Project Name]]" Resources/meetings/

# By date range (filename sorted)
ls Resources/meetings/2026-04-*
```

### Guidelines

- Ask for meeting type if it isn't obvious.
- Extract ALL action items — don't miss any.
- Wikilink attendees and projects.
- Use callouts for visual structure.

---

## Web Content Extraction

When the user shares a URL for context:

- Use `WebFetch` to pull the page content.
- Summarize or extract the requested info.
- If saving for later, route to `Resources/research/` or the relevant project's `research/` folder.

Do NOT use Apify, scrapers, or paid services. WebFetch only.

---

## General Guidelines

- **Memory protocol**: At session start, read `Context/business.md` and `Context/voice.md`. Read `Context/icp.md` before any marketing or content work. Read `Context/strategy.md` when work touches products, pricing, or planning. Read `Projects/*/README.md` to know what's active.
- **Wikilinks everywhere**: Every project, person, and vault note reference in ANY file uses `[[wikilinks]]`. This is what builds the Obsidian graph.
- **Teaching loop**: When corrected, save the correction as a permanent rule. Don't ask.
- **Daily notes**: `Daily/YYYY-MM-DD.md` is the most-read memory file. Keep it current.
- **File paths**: All paths relative to the vault root (working directory).
- **Auto-archive threshold**: Context files > 100 lines → archive older entries. Never archive core identity or active rules.

## Auto-Save Rule

Never ask permission to save. When meaningful info comes up — learnings, preferences, project updates, corrections, action items — save it immediately. Briefly report what was saved and where.

## Anti-Patterns

Do NOT:
- Ask "should I save this?" — just save it
- Write project names, people, or note references as plain text — always `[[wikilinks]]`
- Use `[markdown](links)` for internal vault notes — always `[[wikilinks]]`
- Add a `# Title` heading that duplicates the filename — Obsidian shows the filename as title
- Create orphan notes — always link new notes from at least one existing note
- Read entire files when scanning many — use `grep` first
- Update vault files on casual chat — only when something's worth recording
- Create tasks in a separate tasks.md — they live next to the work (project README or daily note)
- Use Apify, TaskNotes, Fireflies, or Obsidian CLI — this OS is built on plain markdown and WebFetch