feat(obsidian-markdown): add skill

Generated-by: Claude Opus 5.5

README.md

@@ -22,8 +22,9 @@ Code](https://code.claude.com/docs/en/skills) and
   failure path leaves a trace in the logs.
 - [lazy-tdd](lazy-tdd/SKILL.md) — works the first time? fine. Goofed?
   You owe a test.
-- [docs-files-api](docs-files-api/SKILL.md) — exported API docs over
+- [docs-files-api](docs-files-api/SKILL.md) — README sells and gets
-  file docs. Avoid chit-chat.
+  you to TADA; CONTRIBUTING has the rest; AGENTS.md links to it.
+  Exported API docs over file docs. Avoid chit-chat.
 
 ## commits and PRs
 
@@ -44,6 +45,9 @@ Code](https://code.claude.com/docs/en/skills) and
   with live links, quoted and dated.
 - [ibis-design](ibis-design/SKILL.md) — search a design space:
   issues, positions, and arguments.
+- [obsidian-markdown](obsidian-markdown/SKILL.md) — the workspace is
+  an Obsidian vault: one line per paragraph, relative links, no file
+  symlinks you expect Obsidian to show.
 
 ## at the terminal
 

docs-files-api/SKILL.md

@@ -1,10 +1,38 @@
 ---
 name: docs-files-api
-description: JSDoc placement rules for TypeScript/JSDoc code — use when writing or reviewing code comments, JSDoc, or file headers; deciding where @file/@see links go; documenting exported symbols or external specs; when a `//` comment explains what a declaration is or does (it belongs in JSDoc).
+description: Where docs go — README vs CONTRIBUTING vs AGENTS.md, and JSDoc placement — use when writing or reviewing a README, CONTRIBUTING, or AGENTS.md/CLAUDE.md; when someone asks "how do I run it?" and there's no README; when writing or reviewing code comments, JSDoc, or file headers; deciding where @file/@see links go; documenting exported symbols or external specs; when a `//` comment explains what a declaration is or does (it belongs in JSDoc).
 ---
 
 # Documentation Conventions
 
+## README, CONTRIBUTING, AGENTS.md
+
+A **README** sells, then gets the reader running:
+
+- **Up top, about two sentences:** what it is and why to care. Then
+  straight to getting started.
+- **Getting started:** get them to TADA! with no fuss. Readers skip to
+  the first fenced block and copy it; if it doesn't work, boo. So that
+  block runs as-is from a fresh clone and ends with something to look
+  at (a URL, output). No architecture, no principles.
+- **After that:** features and benefits, as much as earns its place.
+
+**Headings say something.** A heading is prime real estate: it shows in
+the outline and in link targets. "What's in it", "Overview", "Features",
+"Details" say nothing; name the point instead ("Bookmarks in, a zine
+out"). Plain labels are fine only where the reader hunts for them by
+name: "Getting started", "Deploying".
+
+Everything else goes in **CONTRIBUTING**: design, layout of the code,
+how to test, conventions, deploying.
+
+**AGENTS.md is a symlink to CONTRIBUTING.md** (likewise CLAUDE.md, if a
+tool wants one). Good advice is good advice, for people and bots alike.
+If agents need something people don't, give it a short section in
+CONTRIBUTING.
+
+## JSDoc
+
 JSDoc placement rules (from the
 [portfolio-contract contributing notes](https://github.com/Agoric/agoric-sdk/blob/master/packages/portfolio-contract/CONTRIBUTING.md#documentation-conventions)):
 

obsidian-markdown/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: obsidian-markdown
+description: Markdown in an Obsidian vault that agents also write — use when an agent writes or edits any .md file in a workspace with a `.obsidian/` folder (notes, READMEs, CONTRIBUTING, AGENTS.md, skills, docs); when someone mentions Obsidian, hard wrap, ragged "poetry" margins, wikilinks, or the vault; when adding a symlink to markdown. Not for Discord or PR text (see grice-maxims).
+---
+
+# Markdown for an Obsidian vault agents write in
+
+The workspace is an [Obsidian](https://obsidian.md/) vault: a `.obsidian/` folder at its root. Dan reads and edits in Obsidian; agents write the same files from a terminal. Write markdown that reads well in Obsidian and on GitHub, and is easy for an agent to edit.
+
+## One line per paragraph
+
+Don't hard-wrap prose. A paragraph is one line; so is each list item. Break lines only between blocks: paragraphs, list items, headings, fences.
+
+Wrapped paragraphs render with a ragged "poetry" margin in Dan's Obsidian, and they make diffs of a one-word edit reflow a whole paragraph. Code blocks keep their line breaks, of course.
+
+When you rewrite a wrapped paragraph, unwrap it. Don't unwrap a whole file you aren't otherwise rewriting: that's a noisy diff in someone else's prose.
+
+## Links
+
+- Standard markdown links with relative paths: `[the webkeys pattern](docs/webkeys.md)`. Obsidian follows them, and GitHub renders them. `[[wikilinks]]` render only in Obsidian.
+- No spaces in file names, so links need no `%20`.
+- Link text says where the link goes (see hypertext-links).
+
+## File names and headings
+
+Obsidian shows file names in tabs, the file explorer, and search, so name files for what's in them.
+
+Headings show in Obsidian's outline pane: make them say something.
+
+## Frontmatter
+
+Obsidian shows YAML frontmatter as Properties. Keep it valid YAML: quote values that contain `: ` or start with a special character.
+
+## Symlinks
+
+From [Obsidian's symlinks page](https://obsidian.md/help/symlinks):
+
+> Obsidian ignores any symlink to a parent folder of the vault, or from one folder in the vault to another folder in the same vault.
+
+> File symlinks (as opposed to folder symlinks) may work, but aren't officially supported at this time.
+
+So a folder symlink inside the vault (`.claude/skills` → `.agents/skills`) is invisible to Obsidian, and that's fine: no duplicates. A file symlink like `AGENTS.md` → `CONTRIBUTING.md` may not show or update in Obsidian. Edit the target, never the link.