From anthrosidian
This skill should be used when the user asks to "log this to my Obsidian knowledge base", "record this in my daily note", "save this problem and solution to my knowledge base", "write this to my Obsidian daily log", or wants to capture a technical note, bug fix, insight, or solved problem into their Obsidian vault's daily note.
How this skill is triggered — by the user, by Claude, or both
Slash command
/anthrosidian:daily-logThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Write structured problem/solution entries into today's Obsidian daily note.
Write structured problem/solution entries into today's Obsidian daily note.
Read VAULT_PATH from the active agent config:
~/.codex/obsidian-vault.conf~/.claude/obsidian-vault.confIf only one config file exists, use that one.
If the file is missing or VAULT_PATH is not set, stop and tell the user:
"Vault path is not configured. Please run anthrosidian:setup in Codex or /anthrosidian:setup in Claude Code to set it up."
<VAULT>/daily/<YYYY>/<YYYY-MM-DD>.md (today's date — daily notes are sharded by year directory)
If <VAULT>/daily/<YYYY>/ does not yet exist (first note of a new year), create the year directory.
When linking to other daily notes from anywhere in the vault, use basename wikilinks ([[YYYY-MM-DD]]) — not path-style ([[daily/YYYY-MM-DD]] or [[daily/YYYY/YYYY-MM-DD]]). Obsidian resolves basenames across all subdirectories, so basename links survive future re-sharding.
Create it directly with this template:
---
tags: [daily]
date: YYYY-MM-DD
---
# YYYY-MM-DD
## Tasks
- [ ]
## Problems & Solutions
## Technical Notes
Output language: write the actual log content in the user's working language (the language they wrote/spoke in this conversation). The English placeholders and examples in this skill are documentation only — do not mimic their language. Field labels (Context: / Symptom: / Cause: / Solution: / Why it works:) stay in English to keep grep compatibility with historical notes; everything else (titles, narrative, identifiers used in prose) follows the user's language.
Append completed work items under ## Tasks as checked checkboxes:
- [x] <one line — the high-level outcome, not the steps>
Granularity rule (important): one task ≈ one commit, or one work unit you'd report in a single sentence at a standup. Do not list individual operations — deleting a file, adding a dependency, removing an import, registering a config entry are steps, not tasks.
Aggregation: if multiple actions served the same goal (one refactor, one feature, one bugfix), collapse them into a single line that names the outcome.
Anti-pattern (avoid — one refactor exploded into a step-by-step log):
- [x] Delete <SomeClass>.java
- [x] Remove unused import in <Config>.java
- [x] Add <library> dependency to pom.xml
- [x] Register <datasource> in application.properties
- [x] Create <ModuleA>Mapper + XML
- [x] Create <ModuleB>Mapper + XML
- [x] Wire <ModuleA>Mapper into <ServiceA>
- [x] Wire <ModuleB>Mapper into <ServiceB>
Preferred (same work, aggregated):
- [x] Migrate <module-group> writes from <old store> to <new store> via <mechanism>
- [x] Fix <component> connection config (host/credentials)
Source: things the user actually finished in this conversation (features, bugfixes, refactors, docs, reviews). Skip abandoned attempts, pure discussion, or in-progress exploration.
Append under ## Problems & Solutions. The key information must be scannable — use bullets, one sentence per line. Do not write long paragraphs.
### <Problem Title — one line stating what the problem is>
- **Context:** <project / module, one line>
- **Symptom:** <what was observed, one line — not a list of causes>
- **Cause:** <why it happened, one line>
- **Solution:** <how it was fixed, one line — name the API / command / file>
- **Why it works:** <why the fix is correct, one line — omit if Cause + Solution already make it obvious>
Field split (key change): the old format used a single Problem field, which kept growing into "what happened + why + impact 1) 2) 3)" walls of text. The new format forces a split into Symptom (what was seen) and Cause (why), one line each. This is the core fix for the wall-of-text problem.
Rules:
## Technical Notes.Anti-pattern (avoid — symptom, cause, and impact all crammed into one paragraph):
**Problem:** Old <Component> used <mechanism> to do <thing>, which caused: 1) <impact A>; 2) <impact B>; 3) <impact C>.
Preferred (one sentence per field):
- **Symptom:** <one observable fact>
- **Cause:** <one causal explanation>
- **Solution:** <one fix, naming the concrete change>
- **Why it works:** <one sentence on the underlying mechanism>
Append reusable insights under ## Technical Notes as a short bullet list. No long paragraphs.
If the insight is reusable beyond today's specific code (patterns, API quirks, tool behaviors), offer to file it into wiki/<topic>/ as a standalone article.
Link from daily note: → [[wiki/<topic>/<article-name>]]
After creating wiki/<topic>/<article-name>.md, always update wiki/_index.md:
| [[wiki/topic/article-name\|topic]] | N | Description |
updated: in the YAML frontmatter to today's date.These three steps are mandatory — skip any one and the index becomes stale.
npx claudepluginhub donald-ada/anthrosidian --plugin anthrosidianFetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Applies a firm's KYC/AML rules grid to parsed onboarding records: assigns risk rating, checks required documents, outputs rule outcomes with citations, and routes for escalation.
Generates daily or weekly digests of activity from connected sources (chat, email, docs, tasks, CRM), highlighting action items, decisions, mentions, and project updates.