1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
|
---
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.
|
