Maintain and query the developer's persistent Obsidian vault memory, component registry, architecture decision records (ADRs), and dev changelog graph. Automatically invoke whenever creating or modifying relevant code (features, fixes, refactors, shared components), making architectural decisions, capturing technical brainstorming, or when the user references past work or component versions across projects.
Installation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Maintain and query the developer's persistent Obsidian vault memory, component registry, architecture decision records (ADRs), and dev changelog graph. Automatically invoke whenever creating or modifying relevant code (features, fixes, refactors, shared components), making architectural decisions, capturing technical brainstorming, or when the user references past work or component versions across projects.
Obsidian Dev Brain & Memory Graph Protocol
Use this skill as the persistent memory, changelog recorder, component registry, and architectural knowledge graph for all user projects.
Vault Base Directory Path:
/Users/pablowerlang/Library/CloudStorage/GoogleDrive-pablowerlang@acad.charqueadas.ifsul.edu.br/My Drive/obsidian/dev-changelog
The in-vault copy of this protocol lives at 00 - Inbox/Vault Protocol Guide.md. If this skill's rules change, update that note in the same pass.
💡 Core Philosophy
Persistent Memory Across Sessions & Projects: Every time code is modified, designed, or refactored, the context, reasoning, code locations, component versions, and decisions MUST be recorded in the Obsidian vault.
Graph Traversal Over Keyword Search: All notes MUST use inline [[Wikilinks]] to connect projects, components, architecture decision records (ADRs), and changelogs.
Check Before You Build: Before creating or modifying relevant code (e.g., UI components, auth modules, DB layers, drivers, helpers, wrappers), search the vault to inspect previous implementations across other projects and find the most up-to-date baseline.
Git for the Dev Brain: Record changes the way git records commits — atomic, typed, dated, and curated. A changelog entry documents intent and reasoning, not raw file noise. Group related file edits under one typed change bullet (like a commit); never produce a file-by-file dump.
Proportional Logging: Logging cost scales with change size. Small change → one line. Big change → full ceremony. Overhead must never become a reason to skip logging entirely.
Cross-project candidates: Any component in the table above that exists in 2+ projects is a cross-project candidate. Before creating a new one, check the vault for an existing baseline. The ⭐️ marker in the Cross-Project Matrix indicates the newest/best version.
Component registry: Glob/grep 02 - Components/ for Component - <Name>.md, or grep the vault for the tag component/<slug>. Read the Cross-Project Matrix: which project holds the ⭐️ baseline (newest/best version), and its interface/props. Search by category tags (#cat/web-component, #cat/driver, #cat/helper, #cat/wrapper) to find existing implementations of the same type.
ADRs: Grep 03 - Architecture & ADRs/ for decisions on the topic. accepted supersedes proposed; check for deprecated before reusing an old pattern.
Recent history: Skim the project's last 2–3 notes in 04 - Dev Changelogs/ for in-flight context.
Apply & cite: Use the retrieved knowledge in the implementation, and cite the baseline you built upon in the new changelog.
If the vault has no record of a component: say so in the changelog and mark the new implementation as the initial ⭐️ baseline.
Change-Type Taxonomy (mandatory in every changelog)
Group edits under typed bullets (Keep a Changelog + Conventional Commits semantics):
Added — new features, files, capabilities
Changed — modified existing behavior
Fixed — bug fixes
Removed — deleted code/features
Deprecated — soon-to-be-removed functionality
Decided — decision made → link the [[ADR-<num> - <Title>]]
Recording Rules
Append-only history: If today's changelog for the project exists, add a new ## Session — HH:MM section at the bottom. Never rewrite prior sessions — they are immutable history, like git commits.
Dates are real: Always use the actual current date/time from your environment (YYYY-MM-DD). Never guess, never copy template dates.
File links: [Toast.tsx](file:///absolute/path/Toast.tsx) — URL-encode spaces as %20 (the vault path itself contains spaces).
Bidirectional links in the same pass: The changelog links to project/component/ADR notes, AND the project MOC + component note get a back-link to the changelog in the same edit.
Inbox flow: Undecided thinking goes to 00 - Inbox/Inbox - YYYY-MM-DD - <topic>.md. When the decision is later made, write the ADR and link it back to the inbox note.
Dataview auto-indexing: The Master Dev Index.md and all 4 README indices use Dataview queries to auto-populate. After creating any entity note, verify Dataview discovers it — never manually edit the index files' link lists. If a note doesn't appear, check its frontmatter tags and folder location.
Artifact 1: Dev Session Changelog (04 - Dev Changelogs/)
Read Template - Changelog.md from 05 - Index & MOCs/Templates/, copy its structure, and fill in real dates and names. One file per project per day; multiple sessions append as new ## Session — HH:MM sections.
Artifact 2: Component Registry (02 - Components/)
If a reusable component (e.g., Toast, Modal, DataGrid, AuthMiddleware, mysql, redis, local-data) was created or modified:
Read Template - Component.md from the templates folder, copy its structure, and fill in values.
Update the Cross-Project Matrix: every project, version, tech stack, location, and the ⭐️ baseline marker.
Record interface/props changes and bump the version per the SemVer rule below.
Assign the correct category tag (see Metadata & Tag Taxonomy): #cat/web-component, #cat/driver, #cat/helper, or #cat/wrapper.
Component Versioning (SemVer):
MAJOR: breaking interface/props change (consumers must update call sites)
MINOR: backward-compatible new capability
PATCH: bug fix or internal change; interface untouched
New stable components start at 1.0.0; experimental/unstable at 0.x.y
Record the bump reason in the component note's Dev History section
Artifact 3: Architecture Decision Records (03 - Architecture & ADRs/)
If a significant technical choice was made (state library, ORM change, styling rules, cross-project convention):
Read Template - ADR.md from the templates folder, copy its structure, and fill in values. Number sequentially after the highest existing ADR.
Document: Status (Accepted/Proposed/Deprecated), Context, Decision, Consequences, Rejected Alternatives.
Link the ADR to affected [[Project - <Name>]] and [[Component - <Name>]] notes.
Artifact 4: Project Hub MOC (01 - Projects/)
Read Template - Project.md from the templates folder, copy its structure, and fill in values.
Add back-links to the new changelog, registered components, and applicable ADRs.
Artifact 5: Index Verification
Dataview auto-populates all index tables (Master Dev Index.md and the 4 README indices in each folder). After creating a new entity note, reload the index to verify Dataview discovers it — no manual index editing needed.
📐 Note Templates (in Vault)
Template files live at 05 - Index & MOCs/Templates/ and serve as the single source of truth for note structure — both for Templater (when creating notes manually in Obsidian) and for agents (to read and fill in programmatically):
Template File
Creates
Template - Project.md
01 - Projects/Project - <Name>.md
Template - Component.md
02 - Components/Component - <Name>.md
Template - ADR.md
03 - Architecture & ADRs/ADR-<num> - <Title>.md
Template - Changelog.md
04 - Dev Changelogs/Changelog - YYYY-MM-DD - <Project>.md
When creating a note: read the corresponding template file from the vault, copy its structure, and fill in the values using today's real date and the entity name. Do not guess at formats — read the template.
The templates above are the canonical format. Any deviation must be reflected in the template files first, then in this skill.
⚠️ Vault Unreachable (Fail-Open)
The vault lives on cloud storage and may be unmounted. If the vault path is not readable:
Continue the coding task normally — never block code work on the vault.
Keep track of what would be logged during the session.
Retry the vault write once at the end of the task.
If still unreachable, explicitly tell the user: "Vault update skipped — vault unreachable", and summarize what should be logged so it can be added later.
🏷️ Metadata & Tag Taxonomy
Always include tags adhering to this naming strategy:
Slugs are lowercase, hyphenated (e.g., Acme Dashboard → #project/acme-dashboard).
✅ Execution Checklist for Agents
Before completing any coding turn:
Did I query the vault before writing code (project hub → component registry → ADRs → recent changelogs)?
Did I use the real current date/time everywhere (frontmatter, filenames, session headers)?
Did I read the template file from 05 - Index & MOCs/Templates/ before creating any vault note?
Did I create/append the session changelog with typed change bullets (Added/Changed/Fixed/Removed/Deprecated/Decided)?
Reusable component touched (web component, driver, helper, or wrapper) → registry updated, version bumped per SemVer, ⭐️ baseline marker moved if the newest version changed projects?
Decision with real alternatives → ADR created with rejected alternatives documented?
Back-links added in the same pass (project MOC + component note → changelog)?
All [[Wikilinks]] valid, YAML frontmatter complete, spaces in file:// links encoded as %20?
Did Dataview auto-discover the new note in the index tables (no manual index editing)?
Vault unreachable → did I retry at the end and explicitly disclose the skip to the user?
