Help us improve
Share bugs, ideas, or general feedback.
From vault-pkm
Wraps up coding sessions: appends devlog summaries with accomplishments, decisions, blockers, next steps; captures undocumented research/debugging; audits session link health; updates project index.
npx claudepluginhub adrianv101/obsidian-pkm-plugin --plugin obsidian-pkmHow this skill is triggered — by the user, by Claude, or both
Slash command
/vault-pkm:pkm-session-endThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Workflow for session wrap-up. When running as a subagent, the delegation prompt provides the project path and devlog boundary context. The agent's system prompt handles transcript discovery (Step 0) before this workflow begins.
Generates and saves Markdown session logs capturing objectives, file changes, referenced materials, technical notes, future plans, open items, and metrics to resume project work across conversations.
Logs accomplishments from Claude Code sessions to dated markdown files at session end, context checkpoints, self-improve triggers, or user request.
Logs session diaries with summaries, git commits, decisions, and handoff notes for future recall. Invoked by 'save diary' or at session end.
Share bugs, ideas, or general feedback.
Workflow for session wrap-up. When running as a subagent, the delegation prompt provides the project path and devlog boundary context. The agent's system prompt handles transcript discovery (Step 0) before this workflow begins.
Append a session summary to the project devlog, most recent entry first.
If the devlog file doesn't exist yet (new project, first session), create it first:
vault_write({
template: "devlog",
path: "01-Projects/<Project>/development/devlog.md",
frontmatter: { tags: ["devlog"], project: "<Project>" }
})
Then append the session entry:
vault_append({
path: "01-Projects/<Project>/development/devlog.md",
heading: "## Sessions",
position: "after_heading",
content: "### YYYY-MM-DD HH:mm\n\n#### Session Summary\n- <what was accomplished>\n\n#### Key Decisions\n- <decisions made, link to ADRs if created>\n\n#### Blockers / Issues\n- <problems encountered, or \"None\">\n\n#### Next Steps\n- <what remains>\n\n---\n"
})
Use the actual date and fill in real content from the session. Keep entries concise but specific. Using after_heading inserts each new entry at the top, keeping the log in reverse-chronological order.
Wikilinks in devlog entries: Include [[wikilinks]] to tasks, ADRs, research notes, and other vault notes that were completed, created, or significantly updated during the session. For example: - Completed [[task-api-refactor]] or - Decided on caching strategy ([[ADR-003-caching]]).
Existing devlogs: Older devlogs may use ## YYYY-MM-DD entries without a ## Sessions heading. If vault_append fails with "Heading not found", add the heading first: vault_append({ path: "...", content: "\n## Sessions\n" }).
The parent agent's session-context message in the delegation prompt is the primary boundary for what counts as "this session." Use it to decide which work is in-scope to capture. The activity log is a discovery aid — useful for spotting files-touched you may have missed — not a session-scope definition.
Why this matters: the MCP server's session ID can span work that was already captured in earlier devlog entries within the same session, so filtering purely by session ID risks re-capturing already-documented work or capturing work outside the parent's intended scope.
Query the activity log to find files touched:
vault_activity({ limit: 1 })
The response header shows current session: <id> (an 8-character prefix). Filter to the same session for full file history:
vault_activity({ session: "<id-from-header>", limit: 50 })
Cross-reference the touched files against the parent's session context. Files outside the parent's stated scope, or files already covered by prior devlog entries in the same session, are not your responsibility to capture again.
Review the session's conversation for significant work that only exists in chat history. Most exchanges produce nothing worth capturing beyond the devlog entry in Step 1. When in doubt, don't capture — a missed capture is better than vault noise.
Skip entirely if the session was purely mechanical (config changes, minor fixes).
For each PKM-worthy item independently, determine whether to update an existing note or create a new one:
For each item, search the vault:
vault_semantic_search({ query: "<topic/title>", limit: 5 })
If unavailable, use vault_search with key terms + vault_query with matching tags.
Route based on results. Note on score interpretation: vault_semantic_search uses text-embedding-3-large (3072-dim) cosine similarity, which compresses hard. Even a verbatim title/heading of an existing note typically scores around 0.55–0.65; scores above 0.7 are essentially never observed.
vault_read and confirm it's actually about the same topic before routing — a 0.5 score can be a real duplicate or a same-domain neighbor. If same topic: go to 3b (update). If neighbor: go to 3c (create with links).When a note already covers this topic, enrich it rather than creating a duplicate:
vault_read the existing note to understand its current contentvault_append to add new findings, with a date-stamped section if the note uses chronological entriesvault_edit to update outdated information (e.g., refining a decision's rationale, adding a new root cause to a troubleshooting log)vault_update_frontmatter to update status or other metadata if changedvault_suggest_links to discover new connections worth addingFollow the pkm-write skill workflow for proper duplicate checking, template selection, and linking:
| Content Type | Template | Default Path |
|---|---|---|
| Architecture/design decisions | adr | <project>/development/decisions/ADR-NNN-{title}.md |
| Research findings or evaluations | research-note | <project>/research/{title}.md |
| Complex debugging sessions | troubleshooting-log | <project>/development/debug/{title}.md |
| Reusable insights or patterns | permanent-note | 03-Resources/Development/{title}.md |
| New tasks identified | task | <project>/tasks/{title}.md |
Where <project> is the vault project path from session context.
When a task's status, priority, or details changed during the session:
vault_query({ type: "task", custom_fields: { project: "<Project>" } }) to find the taskvault_update_frontmatter to update status/priorityvault_append to add context about what changedvault_add_links resolves target by file basename only — #heading suffixes in target are not parsed and the call will fail with not found. To link to a specific session entry, use vault_append to add an inline wikilink in the task body. Use the disambiguated devlog path (<project>/development/devlog) rather than the bare basename, since vaults can have multiple devlog.md files (one per project) and Obsidian's basename resolver may pick the wrong one:
vault_append({
path: "<task-path>",
content: "\n**Status change**: pending → done on YYYY-MM-DD HH:mm. See [[<project>/development/devlog#YYYY-MM-DD HH:mm]] for the session that completed this."
})
Substitute the actual project path and timestamp. Use the same ### YYYY-MM-DD HH:mm heading from Step 1 as the wikilink target. This produces a clickable heading-anchored backlink that Obsidian renders correctly. Bidirectional traceability: the devlog entry links to the task (Step 1), the task body links back to the specific session heading.Read back each note created in Step 3 using vault_read. Verify:
Fix any issues with vault_edit. If a note is entirely placeholder text, delete it with vault_trash — an empty note is worse than no note.
Run a targeted link health check on files touched during this session:
vault_link_health({ folder: "<project-folder>", checks: ["orphans", "broken"] })
For any orphan notes found (no connections), add links using vault_add_links. Broken links (pointing to non-existent files) may self-resolve if the missing notes were created earlier in this session — otherwise note them for manual review. For deeper audit (weak connections, ambiguous links, full vault scan), delegate to the link-auditor agent separately.
Check and update if changed during the session:
_index.md: Add links to new ADRs, update project status, add key links