Claude

Claude sits in two different roles for me, and I try to keep them distinct rather than letting one bleed into the other.

As a coding partner

Mostly through Claude Code in the terminal, working directly in the repos I maintain — a fork of the Obsidian Breadcrumbs plugin (TypeScript + Svelte 5, with a Rust/WASM core) and its docs site. A few habits that make this work well:

• Think before code. I want assumptions stated and interpretations surfaced before anything gets written, not a confident guess silently baked into a diff.
• Surgical changes. Touch what the task requires, match existing style, don’t drive-by refactor adjacent code. It’s a lot easier to review a diff that does one thing.
• Verify, don’t assert. “Done” means tests pass and the build is green, shown, not just claimed.

As a thinking/planning partner

The other half is less about code and more about using Claude the way I’d use a notebook with a memory — weekly planning (tasks live in OmniFocus), personal knowledge work in Obsidian, and working through decisions out loud before committing to one. This is the part that doesn’t show up in any git log: talking through a plan, stress-testing an idea, or turning a messy set of thoughts into something structured enough to act on.

Why the split matters

Treating “write this code” and “help me think this through” as the same kind of request tends to produce worse results at both — code that’s over-explained instead of just correct, or planning conversations that get rushed toward an artifact before the thinking is actually done. Being explicit about which mode a given conversation is in keeps both halves useful.

See Keeping Updated for how I approach staying current as this tool changes quickly.

Page template for this section

Every Tool is a hub page plus a handful of atomic notes, nested as tools/<tool>/index.md and tools/<tool>/<note-slug>.md. See CONTEXT.md and docs/adr/0001-hub-and-atomic-notes-for-tools.md at the repo root for the reasoning; this section is the concrete template to follow when writing or adding pages.

Frontmatter — every page (hub or atomic note) has title and description at minimum.

Hub page (index.md):

• A short framing paragraph: what the tool is and where it fits relative to its siblings (for tools with siblings competing for the same job — CI/CD tools especially) or how it’s set up (for tools without a direct sibling).
• A linked list of that tool’s atomic notes.
• Deliberately thin — elaboration belongs in the atomic notes it links to, not on the hub itself.

Atomic note (<note-slug>.md):

• Opens with a one-line definition of the idea before elaborating.
• Body: the elaboration — why this holds up, what it prevents, how it’s applied.
• Closes with a short “Related” list of cross-links, where relevant (to other atomic notes on this tool, other tools, or a cross-cutting page).

Voice — first person, present tense, the “I do X because Y” pattern already used throughout this section. Keep it consistent across hub pages and atomic notes alike; it’s the one thing that was already uniform before this template existed, so it shouldn’t drift now that structure is being added.

Cross-cutting pages (performance.md, updates.md) — thin aggregators only: a short intro plus a linked list into the relevant atomic notes per tool. Never restate an atomic note’s content — the atomic note is the single source of truth.

Splitting an atomic note from a hub’s content — the test is “would I ever want to link to just this idea from another page?” If yes, it’s its own note. If it only makes sense as a sub-point of a broader idea, merge it into that broader note. Prefer a handful of notes per tool (3-5) over one-note-per-bullet.

Voice by sidebar group

The section-level template above (hub + atomic notes, “Where it fits” / “Principles that hold up”) is the Professional group’s voice specifically — tech-focused, how-to-and-setup oriented, since these tools compete with siblings for the same job and a reader needs to know which one to reach for. Personal and Desktop & Life are a different register: tools I use and how they help me, first-person and benefit-driven, no “Where it fits” or “Principles” headings. Their natural sections are “How I use it” (bullets in “I do X because Y helps me Z” form, not “Principle: general claim”), and — only when a page has a real sibling or competitor, the way Due pairs with OmniFocus or Magnet pairs with Moom — “Role in the stack” or “Divide labor” to explain the split. Don’t borrow the Professional scaffold for these groups; it was tried once (on Due, Readwise, and all of Desktop & Life) and corrected because it read as noticeably more clinical than Obsidian/OmniFocus/Claude’s established tone.