Organize daily notes

Organize Daily Notes

Clean up and organize Obsidian daily notes while conservatively assimilating durable knowledge into 02-SlipBox/.

Core Principles

• Never delete information. Reorganize and polish; do not curate or remove.
• Prefer existing slipbox notes over new ones. When a relevant 02-SlipBox/ note exists, assimilate into it.
• Focus where judgment matters. Don't spend effort on obvious cleanup. Prioritize: implicit wikilinks, entity resolution, loose text needing structural interpretation, and durable knowledge hidden near existing slipbox links.

Daily Note Structure

Daily notes follow the template at Templates/daily-note-template.md. Two sections are sacred — never modify them:

• Priority (including the ![[Top 3 Things]] embed)
• Backlog (including tasks code blocks)

The two editable sections are:

• Daily Log: Main content — tasks, events, meetings, learnings, ideas. May contain timed subsections (### HH:MM Activity Title).
• Quick Notes: Optional ad-hoc captures — images, web links, ideas, quick reminders.

Cleanup

Claude handles spelling, grammar, capitalization, and time format correction by default. For user-specific preferences that override defaults, see references/cleanup-prefs.md.

Markdown Structure

• Section ordering: Priority > Backlog > Daily Log > Quick Notes.
• Heading levels: ## for main sections, ### for timed activities, ####+ for nesting. When restructuring, adjust child headings to maintain relative depth.
• Loose/floating text: Organize under the nearest appropriate heading or bullet. If ambiguous, ask the user.

Entity Linking

Resolve plain-text mentions of existing vault notes to [[Wikilinks]]. Discover linkable note titles via the obsidian-cli skill (obsidian search) or Glob across 01-Project/**/*.md, 02-SlipBox/**/*.md, 03-Reference/**/*.md.

• Only add new links; never remove or change existing wikilinks (including placeholders to notes that don't yet exist).
• Match whole phrases at word boundaries — do not link substrings.
• Skip if uncertain — when multiple notes could match or the mention is ambiguous, leave as plain text and record it for the report as an unresolved entity.
• Do not link inside existing wikilinks, task blocks, code blocks, or embeds.

Conservative Slipbox Assimilation

When daily notes contain durable knowledge, assimilate it into 02-SlipBox/:

• Follow the links. If a daily note links to an existing slipbox note and continues with explanation, examples, or heuristics, that surrounding content is the highest-signal assimilation candidate. Distill it into the linked note.
• What counts as durable: Reusable heuristics, principles, mental models, setup/debugging guidance, stable relationship facts, concepts likely to matter again.
• What does not count: Bare mentions, meeting logistics, transient status updates, one-off todos, thin facts.
• New notes are a last resort. Only create a new slipbox note when no suitable existing note exists, the content is clearly reusable, the title is obvious, and there is enough substance to avoid a stub. If too raw, leave it in the daily note or mark it #toprocess.

For heavy or multi-note knowledge integration, read ../assimilate-knowledge/SKILL.md. For creating a new slipbox note, read Templates/slip-box-base-template.md only after the conservatism bar is cleared. Check Memory/ notes for stored vault preferences before writing.

Ontology-Aware Property Population

When assimilating into a typed slipbox note (or one whose type can be inferred), consult Memory/vault-ontology-reference.md for available schema.org properties.

• Read the ontology reference to find the curated property subset for the note's type.
• Extract structured facts from the daily note context surrounding the wikilink. E.g., "[[Josh Bragg]] is now tech lead on FDE" yields jobTitle: "Tech Lead" and memberOf: ["[[FDE]]"].
• Populate only properties with concrete evidence. Do not infer from vague mentions or add empty fields.
• Add the type field if the note lacks one and the type can be confidently inferred (e.g., slip-box/people tag → type: "schema:Person").
• Merge, don't overwrite existing property values. For array properties like colleague, append new values; for scalar properties like jobTitle, update only if the new information is clearly more current.
• Respect the property ordering convention: all non-semantic properties are sorted alphabetically A-Z (the Obsidian linter enforces this on save). TOPIC/PRIOR/NEXT/RELATED_TO are always pinned at the bottom.

This step runs during slipbox assimilation (not as a separate pass). When you're already reading context around a slipbox link and deciding what to distill, also check whether the context contains type-specific facts worth capturing as structured properties.

Alias Link Resolution

After entity linking, newly added [[Wikilinks]] may use aliases instead of the canonical note name (e.g., [[LLM]] instead of [[Large Language Model|LLM]]). Use the resolve-alias-links skill to normalize these. Read ../resolve-alias-links/SKILL.md for the script and detection rules.

Semantic Link Sync

After slipbox assimilation, updated or newly created 02-SlipBox/ notes may have frontmatter semantic properties (RELATED_TO, PRIOR, NEXT) whose bidirectional counterparts need syncing. Use the sync-semantic-links skill to validate and fix these. Read ../sync-semantic-links/SKILL.md for the script and validation rules.

Security Flagging

If you notice plaintext secrets, API keys, tokens, or passwords, flag them in the report. Do not delete them.

AI-Todo Tags

Inline #ai-todo/<action> tags (e.g., #ai-todo/assimilate, #ai-todo/link) are user-directed action requests. The <action> verb is open-ended — interpret it from surrounding content within the smallest enclosing bullet or paragraph. An AI-Todo is explicit user intent, so it overrides the usual conservatism (e.g., #ai-todo/assimilate means "distill this, even if borderline"). On success, remove only the tag token and leave everything else verbatim. If you can't complete the action, leave the tag in place and log it in the report's Deferred Knowledge section.

For the common verbs and how to interpret each, see references/ai-todo-tags.md.

Workflow

1. Determine date range from user's request. Default: since last run (check run-log.jsonl) through yesterday (today − 1), or past 3 days if no log exists. Today's note is excluded by default because it is likely still being edited; the user can explicitly include it by specifying a range.
2. Discover notes and entities in parallel: Glob daily notes in 00-Inbox/YYYY-MM-DD.md; discover linkable entity titles via the obsidian-cli skill or Glob.
3. Read daily notes and ontology reference (in parallel). Read daily notes, Memory/vault-ontology-reference.md, and any 02-SlipBox/ notes linked with substantive surrounding content.
4. Apply fixes per note in chronological order — cleanup, entity linking, slipbox assimilation, ontology property population, and any #ai-todo/* tags encountered, in a single pass per note. For image-heavy notes, use the image-metadata-from-cache skill for context.
5. Resolve alias links on edited daily notes — read the resolve-alias-links skill and run its script to normalize any [[alias]] wikilinks to [[actual note|alias]] format.
6. Sync semantic links — if slipbox notes were updated or created, read the sync-semantic-links skill and run its script on 02-SlipBox/ to fix any broken bidirectional frontmatter links.
7. Report using the template at templates/report.md.
8. Update run log — append an entry to run-log.jsonl (see below).

Run Log

The file run-log.jsonl in this skill's directory provides continuity across sessions. Each line is a JSON object:

{"date": "2026-04-05", "range": ["2026-04-03", "2026-04-05"], "notes_processed": ["2026-04-03", "2026-04-04", "2026-04-05"], "slipbox_updated": ["Learning", "North"], "slipbox_created": [], "unresolved_entities": [{"file": "2026-04-04", "mention": "Dory", "candidates": ["Dory.md"]}], "deferred": ["2026-04-05: raw brainstorm on deployment strategy"]}

Fields:

• date: When this run happened (ISO date).
• range: [start, end] date range processed.
• notes_processed: Daily note dates that were organized.
• slipbox_updated: Existing slipbox notes that received new content.
• slipbox_created: New slipbox notes created (empty array if none).
• unresolved_entities: Entities that couldn't be confidently linked — carry forward for future runs so the user can revisit them.
• deferred: Knowledge left in daily notes for later processing, including any unhandled #ai-todo/* tags (format as "YYYY-MM-DD #ai-todo/<action>: reason").

Cold start: If run-log.jsonl does not exist (e.g., first run or new user), create it after the first successful run. Use the user's requested date range (or the 3-day default) since there is no history to resume from. No special setup is required — just append the first entry.

Using the log: At the start of each run, read the last entry to:

• Default the date range to start after the last processed date and end at yesterday (today − 1). Today's note is excluded because it is likely still being edited; the user can override this by explicitly requesting a range that includes today.
• Surface previously unresolved entities and deferred knowledge so the user can revisit them.
• Avoid re-processing notes that were already organized.

Recording the range: Only include notes through yesterday in range and notes_processed. If the user explicitly requests today's note and it is processed, still record the range ending at yesterday so the next default run re-processes today's note after it is finalized.

Gotchas

Common failure modes. Update this section as new ones appear.

• Skipping content after a slipbox link. When a daily note says [[Learning]] followed by bullets, Claude often treats it as a bare mention. Always check what follows — e.g., [[Learning]] - discovered that batch size affects... means the trailing explanation should be distilled into Learning.md.
• Creating slipbox notes from bare mentions. "Met with Alice about deployment" is not grounds for a new Alice.md. A name-drop or one-line reference is not enough material.
• Copying daily prose verbatim into slipbox. Raw daily text is contextual. Distill into evergreen wording — e.g., "Today I learned that X does Y" should become a clean explanation of the concept.
• Mistaking todos for knowledge. Checkboxes and status tracking belong in daily notes unless they reveal a durable principle behind the task.
• Over-linking uncertain entities. If "model" could refer to [[ML Model]] or [[Data Model]], report it as unresolved instead of guessing.
• Over-assimilating raw brainstorms. If material is still a sketch, leave it in the daily note or mark #toprocess.
• Over-populating ontology properties. "Chatted with Josh about backend" does not justify adding knowsAbout: "[[Backend]]". Only populate properties from specific, concrete facts.
• Duplicating TOPIC in ontology properties. Do not use schema.org's isPartOf/hasPart — the existing TOPIC and Sub-Topics base already handle hierarchical containment.
• Stripping AI-Todo tags too aggressively. Remove only the #ai-todo/<action> token. Do not also strip adjacent punctuation or separators that belong to the content — e.g., in [[Learning]] #ai-todo/assimilate - Learning strategy: the - separator is user content and must stay.

Sacred Content

Never modify any of the following:

• Existing wikilinks — targets and display text stay as-is. Only add new links.
• Task checkboxes — - [x], - [ ], - [/], - [-], task metadata, and plugin syntax (#task, ⏫, 🛫, 📅, ✅).
• Embedded content — ![[image]] and ![[note]] transclusions.
• Backlog queries — content inside ```tasks``` code blocks.
• Priority section — the ![[Top 3 Things]] embed and everything in Priority.
• Code blocks — don't modify content inside fenced code blocks (except to fix the language identifier).

Exception: #ai-todo/<action> tags are the one category of tag the agent is expected to remove — specifically, after successfully addressing the requested action. Leave all other user-authored tags (e.g., #toprocess, #task, topic tags) untouched.

Preserve the user's tone — fix mechanical issues but don't rewrite their thoughts.