CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

obsidian-writer

Write well-formatted notes to the atmosphere-vault Obsidian knowledge base. Use this skill whenever creating or updating an ADR, runbook, plan, API doc, guide, session output, or any structured document that should land in the vault — even when the user doesn't say "Obsidian" explicitly. Delegates to obsidian:obsidian-cli to write to the live vault and applies Atmosphere frontmatter and formatting standards.

70

Quality

88%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

81%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A highly actionable, well-sequenced operational skill: exact commands, explicit validation and error-recovery loops for the risky pull/push operations, and proper use of a one-level-deep reference file. Its weaknesses are redundancy — frontmatter rules and CLI patterns appear in both the body and the reference file, and the Step 6 publish-semantics paragraph is dense and repetitive — plus a workflow-critical script referenced but absent from the bundle.

Suggestions

Cut the Frontmatter Standards section to a one-line pointer to references/vault-structure.md (keeping only per-type required-tag differences if any), since the body already tells the reader the complete field table lives there — this removes the largest duplication.

Replace the Step 6 exit-0 prose paragraph with a short bulleted outcome list (exit 0 = published; files listed as 'already on origin/main then changed' = re-read before reporting; non-zero = not published, re-read and redo) — the current single paragraph restates the same distinction three ways.

Fold the 'Key obsidian-cli Patterns' section into the workflow steps (or drop it, since Steps 2–5 already show every command verbatim), and either ship vault-sync.sh in the bundle's scripts/ or note where it is installed so the referenced path resolves.

DimensionReasoningScore

Conciseness

Mostly operational with no padding about concepts Claude already knows, but there is clear tightening to do: the Frontmatter Standards section duplicates the field table that the body itself says lives in "references/vault-structure.md"; the "Key obsidian-cli Patterns" section repeats the create/read/append commands already shown in Steps 2–5; and the Step 6 exit-0 paragraph ("Your notes are the files under the paths that the push's commit changed, and those the vault holds differently from the origin/main it forked from...") is a long, repetitive, hard-to-parse block that could be a short bulleted interpretation of outcomes. This fits anchor 3 — could be tightened — more than anchor 2, since none of it is concept explanation, just redundancy.

3 / 5

Actionability

Fully executable throughout: exact commands ("obsidian create name=\"ADR-0042 Adopt Virtual Threads\" path=\"Architecture/ADRs/ADR-0042 Adopt Virtual Threads.md\"", "vault-sync.sh push -m \"docs(<kind>): <what>\" <path>…"), concrete frontmatter templates per doc type, exact target directories, the exact expected error string ("An API key must be provided via OBSIDIAN_API_KEY") with its exact fix ("npm uninstall -g obsidian-cli"), and verification commands ("obsidian read file=\"<Note Title>\""). Copy-paste ready and covers the common cases.

5 / 5

Workflow Clarity

A clearly sequenced six-step workflow with explicit validation checkpoints and error-recovery loops: pull-before-search with full non-zero-exit handling ("If `pull` exits non-zero, stop and report what it printed"), read-back verification after writing (Step 5), and push exit-code interpretation with a redo loop ("re-read those notes and redo your change if it is gone"). Destructive/publish operations all carry feedback loops, matching the anchor-5 pattern.

5 / 5

Progressive Disclosure

Good structure: the detailed field table and directory map are correctly pushed to a clearly signaled, one-level-deep "references/vault-structure.md" (which exists in the bundle), and the body stays an overview with a quick-reference table. Two minor gaps keep it from anchor 5: the body's Frontmatter Standards section duplicates content the reference file owns, and the workflow centrally depends on ".claude/skills/obsidian-writer/vault-sync.sh", which is not present in the bundle (no scripts/ directory) — a referenced path the reader cannot reach from what ships here.

4 / 5

Total

17

/

20

Passed

Description

91%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: it names concrete artifact types, gives an explicit and broad 'Use when' trigger clause, and anchors itself to a specific vault and CLI. It sits just below the top anchors on specificity (actions collapse to write/update plus frontmatter application) and distinctiveness (intentionally broad trigger surface for generic doc types).

DimensionReasoningScore

Specificity

Concrete actions are stated — "Write well-formatted notes", "creating or updating an ADR, runbook, plan, API doc, guide, session output", "applies Atmosphere frontmatter and formatting standards" — with a named delegation target ("obsidian:obsidian-cli"). Not quite the anchor-5 bar of comprehensive multi-action coverage: the distinct actions reduce to write/create/update plus applying frontmatter; supporting operations like search/dedupe/publish are not named, leaving minor gaps.

4 / 5

Completeness

Both halves are explicit: what — "Write well-formatted notes to the atmosphere-vault Obsidian knowledge base... applies Atmosphere frontmatter and formatting standards"; when — "Use this skill whenever creating or updating an ADR, runbook, plan, API doc, guide, session output, or any structured document that should land in the vault". This matches the anchor-5 pattern of a concrete what plus an explicit trigger clause with concrete phrases.

5 / 5

Trigger Term Quality

Rich natural trigger vocabulary users would actually say: "ADR, runbook, plan, API doc, guide, session output", plus "knowledge base", "vault", and "Obsidian" with synonyms covered. The explicit "even when the user doesn't say 'Obsidian' explicitly" clause broadens natural-language matching; no meaningful terms are missing for this domain (file extensions are not applicable).

5 / 5

Distinctiveness Conflict Risk

Clear niche (the atmosphere-vault destination, a specific CLI, Atmosphere standards) distinguishes it from generic skills, but the deliberately broad catch-all "any structured document that should land in the vault — even when the user doesn't say 'Obsidian' explicitly" and generic terms like "plan" and "guide" create minor overlap risk with closely related documentation/planning skills and the companion obsidian-vault-setup skill. Mostly distinct rather than minimal-conflict.

4 / 5

Total

18

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

Atmosphere/atmosphere

Path

.claude/skills/obsidian-writer/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.