# Obsidian

> Use when creating, editing, or organizing notes in the Obsidian vault — daily notes, meeting notes, project notes, or links between them. Covers naming, structure, linking, and when a note is worth writing at all.

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

---


# Obsidian Notes

## Vault Location

All notes live in the Obsidian vault. Don't create notes outside it unless explicitly asked.

## Naming Conventions

- Use lowercase with hyphens: `project-planning.md`, not `Project Planning.md`
- Be descriptive: `api-rate-limiting-design.md`, not `notes.md`
- Date-prefix daily/weekly notes: `2026-04-17.md`
- Date-prefix meeting notes: `2026-04-17-design-review.md`

## Structure

- One idea per note. If a note covers two things, split it.
- Lead with context: what is this, why does it exist.
- Use headings for scanning. Keep paragraphs short.

## Linking

- Link liberally: `[[note-name]]` for any concept or project mentioned.
- Don't orphan notes. Every note should link to or be linked from something.
- Use MOCs (Maps of Content) for broad topics that tie many notes together.

## Project Notes

- Create a project note for any project that spans more than one session.
- Include: goal, key decisions, architecture overview, links to related notes.
- Update the project note as the project evolves — it's the living summary.

## Meeting Notes

- Capture decisions and action items, not transcripts.
- Format action items as checkboxes: `- [ ] Action item here`
- Link to project notes and people notes.

## When to Create Notes

- After a design decision is made
- When learning something non-obvious
- When a debugging session reveals something worth remembering
- When a project's scope or direction changes
- When context is getting large and needs to be offloaded

## When NOT to Create Notes

- For trivial information easily googled
- For things already well-documented elsewhere
- During active implementation (notes are for after, not during)