Content
81%Weight 40%Scale 1-5Reviews 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.
| Dimension | Reasoning | Score |
|---|---|---|
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 |