---
name: note-taker
description: Write to the users notes. Use when asked explicitely.
---

# Note taker

Take notes in the user's personal style. Notes live at `~/Sync/Notes/`.

## File layout

- One topic per file. Filename in lowercase kebab-case (`bash.md`, `linux-processes.md`, `writing-git-commit.md`,
  `neovim-lua.md`).
- No frontmatter. No dates. No metadata. Plain Markdown only.
- Reuse an existing file when the topic fits; create a new one only if the topic doesn't belong in any existing note.
- Files are auto-formatted on save: `mdformat` (with `mdformat-gfm` + `mdformat-frontmatter`) handles wrap (~110 chars),
  hanging indents, and the 70-underscore horizontal rules; `link.vim` collects inline URLs into the `## Links` section.
  Write naturally — don't pre-format, and don't generate `## Links` or `_____` rules yourself.

## Structure

- Top of file: a single `# Title`. The title is a descriptive phrase, not a literal filename echo (`linux-processes.md`
  → `# Processes in Linux`, `writing-git-commit.md` → `# Writing git commit messages`).
- `##` sections, `###` subsections.
- Use `######` (h6) as a compact heading for a one-off block when intermediate `##`/`###` would be overkill — see
  `linux.md`'s `###### Change login shell`.

## Heading vs list item

User's own rule from `writing.md`: **use a list when you don't want the item to appear in the table of contents**. If it
deserves TOC presence, it's a heading; otherwise it's a list item.

## Markdown conventions

- **Bold** (`**word**`) for key terms, keyboard shortcuts (**Ctrl+T**), and labels in definition-style lists (**feat**:
  add new feature).
- *Italic* (`*word*`) for first-time introduction of a term (e.g. "i.e. the *shebang*"), and for parenthetical acronym
  expansions: `**ps**: *(process status)* print a snapshot of current processes`.
- Inline `` `code` `` for commands, filenames, env vars, code identifiers, signal names (`TERM`, `KILL`).
- Fenced code blocks always carry a language tag. Use `bash` for shell, `default` for templates/skeletons that have no
  syntax (e.g. format specs like `<type>[optional scope]: <description>`).
- Write all links **inline**: `[text](https://example.com)`. The `link.vim` plugin moves them into a trailing `## Links`
  reference section on save — don't write that section yourself, and don't use `[text][0]` / `[0]: ...` reference style.
- Man-page links use the `man://` scheme inline: `[chsh(1)](man://chsh)`, `[ps(1)](man://ps)`.
- Tables (GFM pipe syntax) for genuinely tabular data — see `xdg.md`.

## Tone

- Terse, factual, practical — the user re-reads these later, so optimize for "useful at a glance."
- First-person is fine when it captures the user's preferences ("I use the types:", "I don't use BREAKING CHANGE, these
  are overkill for personal stuff").
- Casual asides are allowed in small doses (`index.md` ends with "There are emojis in environment.d(5) lol.").
- Opinions welcome when they're the user's actual stance.
- RFC 2119 keyword semantics (MUST / SHOULD / MAY) apply when prescribing — the user references RFC 2119 in
  `writing.md`.

## When asked to take a note

1. Read the relevant file (if it exists) first to match level/section structure and avoid duplication.
2. Apply the style above. Don't over-explain. Don't add headings the user wouldn't want in the TOC.
3. Don't fix typos or rewrite other sections unless asked. Touch only what's needed for the new content.