This skill should be used when the user asks to "노트 정리해줘", "노트로 만들어줘", "obsidian에 저장해줘", "obsidian에 정리", "vault에 저장", "논의 내용 정리해줘", "대화 내용 정리", "지금까지 내용 정리", "마크다운으로 정리", "obsidian 노트 작성", "save to obsidian", "write notes", "create a note", "summarize this conversation", "organize into a note", "save my notes", "export to obsidian", or wants to capture, organize, and persist the current AI conversation as a structured Obsidian-compatible markdown note with frontmatter, wikilinks, and tags.
From workflow-adapternpx claudepluginhub morigemini6668-ux/workflow-adapterThis skill uses the workspace's default tool permissions.
references/formatting-guide.mdSearches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Executes pre-written implementation plans: critically reviews, follows bite-sized steps exactly, runs verifications, tracks progress with checkpoints, uses git worktrees, stops on blockers.
Summarize and organize AI conversation content into Obsidian-compatible markdown notes. This skill produces flat-structure notes with YAML frontmatter metadata, [[wikilink]] cross-references, and tag-based grouping.
Look up the vault path in .claude/workflow-adapter.local.md. If the obsidian_vault_path field exists in the frontmatter, use that path.
If no path is configured, ask the user for their Obsidian vault path using AskUserQuestion. After receiving the path, save it to .claude/workflow-adapter.local.md frontmatter so it persists for future use.
Example .claude/workflow-adapter.local.md frontmatter:
---
obsidian_vault_path: /Users/username/ObsidianVault
---
Review the entire conversation to identify:
For long conversations (many back-and-forth exchanges), prioritize capturing decisions, conclusions, and actionable outcomes over raw discussion details. Summarize exploratory discussion into concise insights rather than reproducing it verbatim.
When a conversation covers multiple unrelated topics, consolidate into a single note with clearly separated sections. Apply shared tags to group the note with related content from other sessions.
Construct YAML frontmatter with these fields:
Required fields:
title: Concise, descriptive title of the notedate: Current date in YYYY-MM-DD formatauthor: Author name, obtained by running git config user.nametags: Array of relevant tags for grouping related notesContextual fields (add when relevant):
aliases: Alternative names for the note (for Obsidian search)summary: One-line summary of the note contentstatus: e.g., draft, in-progress, completerelated: List of [[wikilinks]] to potentially related notesproject: Project name if discussion is project-specificcategory: Content category (e.g., architecture, design, research, decision)Determine which contextual fields to include based on the conversation content. For example, include project only when a specific project was discussed, include status when action items remain.
Structure the note body following Obsidian conventions:
## Heading for major sections[[wikilink]] to reference concepts, tools, or topics that could be separate notes#architecture, #decision)> [!note] Key Decision
> Description of the decision made
Before writing to the vault, present the full draft to the user for review. Display the complete note content (frontmatter + body) as a code block so the user can see exactly what will be saved.
After presenting the draft, ask the user via AskUserQuestion:
If the user requests edits, apply them and repeat this preview step until the user approves. Only proceed to step 6 after explicit approval.
Generate the filename as {title-in-kebab-case}.md (flat structure, no subdirectories).
Write the file to {vault_path}/{filename}.
Confirm to the user:
Refer to references/formatting-guide.md for detailed Obsidian formatting conventions, callout types, and wikilink patterns.
---
title: API 인증 방식 논의
date: 2025-01-15
author: John Doe
tags:
- authentication
- api-design
- project/my-app
aliases:
- API 인증
- auth 방식
summary: JWT vs OAuth2 비교 분석 및 JWT 채택 결정
category: decision
---
# API 인증 방식 논의
## 배경
[[my-app]] 프로젝트의 API 인증 방식을 결정하기 위해 논의함.
## 비교 분석
### [[JWT]]
- 무상태(stateless) 인증
- 서버 부하 적음
...
### [[OAuth2]]
- 표준 프로토콜
- 서드파티 연동 용이
...
> [!note] 결정사항
> JWT를 기본 인증 방식으로 채택. 향후 서드파티 연동 필요 시 OAuth2 추가 검토.
## 다음 단계
- [ ] JWT 라이브러리 선정
- [ ] 토큰 만료 정책 결정
- [ ] [[refresh-token]] 전략 설계
[[wikilink]] liberally for concepts that could become their own notes/ for hierarchy (e.g., project/my-app)