docs: reorganize skills into pkm category and add crit skill
- Create new `pkm` directory for Personal Knowledge Management skills - Move conversation-summary, knowledge-gardener, and research-vault from `personal` to `pkm` - Add new crit skill for brainstorming with the CRIT framework - Update skill descriptions for clarity and consistency - Add audio-product-dsp, grilling, and research-engineering to model-invoked listings - Update skill paths across README files to reflect new directory structure
This commit is contained in:
@@ -0,0 +1,12 @@
|
||||
# PKM Skills
|
||||
|
||||
## User-invoked
|
||||
|
||||
- [conversation-summary](conversation-summary/SKILL.md) — Summarize the current AI conversation into a new Obsidian markdown note and matching transcript file.
|
||||
- [crit](crit/SKILL.md) — Brainstorm with AI using the CRIT framework to generate and evaluate ideas.
|
||||
- [knowledge-gardener](knowledge-gardener/SKILL.md) — Run vault-aware semantic search, synthesis, note creation, linking, and Zettelkasten workflows for this Obsidian vault.
|
||||
- [research-vault](research-vault/SKILL.md) — Research a topic through a one-question-at-a-time learning conversation and save a linked Obsidian research packet.
|
||||
|
||||
## Model-invoked
|
||||
|
||||
_None yet._
|
||||
@@ -0,0 +1,223 @@
|
||||
---
|
||||
name: conversation-summary
|
||||
description: Summarize the current AI conversation into a new Obsidian markdown note and matching transcript file. Use when the user asks to save, export, log, archive, or summarize the current chat into an Obsidian vault, research note, markdown note, meeting note, decision log, or second-brain workflow.
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
Create exactly one new Obsidian summary note for the current conversation. Also create exactly one transcript note for the same conversation.
|
||||
|
||||
## Default location
|
||||
|
||||
- Write notes to `~/Documents/nca-notes/AI Conversation Summaries/` unless the user requests another path.
|
||||
- Create the directory if it does not exist.
|
||||
- Never overwrite an existing note.
|
||||
- Never append to an existing note unless the user explicitly asks.
|
||||
|
||||
## Required behavior
|
||||
|
||||
1. Read the current conversation context only.
|
||||
2. Generate a filesystem-safe title.
|
||||
3. Write one summary note.
|
||||
4. Write one transcript note.
|
||||
5. Verify both files exist.
|
||||
6. Return the exact paths, generated title, and count of action items captured.
|
||||
|
||||
## Title rules
|
||||
|
||||
Use this format:
|
||||
|
||||
`YYYY-MM-DD_HH-mm_<descriptor>_<ID>`
|
||||
|
||||
Rules:
|
||||
- `<descriptor>`: 3-6 word slug based on the main topic.
|
||||
- Allowed characters in the full title: letters, digits, `.`, `_`, `-`.
|
||||
- Replace spaces with `-`.
|
||||
- Remove other punctuation.
|
||||
- Collapse repeated separators.
|
||||
- `<ID>`: 4-character uppercase alphanumeric suffix.
|
||||
- If a filename collision occurs, regenerate only `<ID>` until unique.
|
||||
- If too long for the filesystem, shorten only `<descriptor>`.
|
||||
|
||||
## Obsidian-specific rules
|
||||
|
||||
- Use valid YAML frontmatter.
|
||||
- Keep frontmatter simple and machine-safe.
|
||||
- Use wikilink-friendly filenames.
|
||||
- Include both standard markdown links and Obsidian wikilinks where useful.
|
||||
- Keep headings shallow and scannable.
|
||||
- Use UTF-8 markdown.
|
||||
- Prefer stable tags in frontmatter plus inline hashtag tags at the end.
|
||||
- If the conversation mentions files, URLs, papers, repos, tools, docs, or paths, capture them in a dedicated `References` section.
|
||||
- If the conversation includes explicit choices, approvals, rejections, or resolved tradeoffs, capture them in `Decisions Made`.
|
||||
|
||||
## Summary quality rules
|
||||
|
||||
- Use only facts available in the current conversation.
|
||||
- Do not invent references, decisions, action items, or conclusions.
|
||||
- Do not write a play-by-play transcript in the summary note.
|
||||
- Synthesize the conversation into a compact research/work summary.
|
||||
- If information is missing, say so explicitly.
|
||||
- If the conversation is short, still use the full template with fallback lines.
|
||||
- If the transcript available to you is incomplete, mark it as partial.
|
||||
|
||||
## Automatic tags
|
||||
|
||||
Generate 4-8 tags total.
|
||||
|
||||
Always include:
|
||||
- `ai-summary`
|
||||
- one domain/topic tag based on the conversation
|
||||
- one workflow tag based on the type of work, if clear
|
||||
|
||||
Add tags from these categories when supported by the conversation:
|
||||
- domain: `research`, `coding`, `obsidian`, `automation`, `writing`, `planning`, `debugging`
|
||||
- artifact: `skill`, `note`, `transcript`, `review`, `decision-log`
|
||||
- status: `draft`, `completed`, `follow-up`
|
||||
- technology/tool names in lowercase slug form when clearly central
|
||||
|
||||
Tag rules:
|
||||
- Use lowercase kebab-case only.
|
||||
- Prefer specific tags over generic ones.
|
||||
- Do not add unsupported tags.
|
||||
|
||||
## References capture
|
||||
|
||||
In the `References` section, capture conversation-specific source material that was explicitly mentioned or used, such as:
|
||||
- local file paths
|
||||
- URLs
|
||||
- repository paths
|
||||
- document names
|
||||
- tool names
|
||||
- named skills, scripts, or commands
|
||||
|
||||
Format each reference as one bullet with a short label and what it was used for.
|
||||
|
||||
If none were mentioned, write:
|
||||
- `- No explicit references or source artifacts captured.`
|
||||
|
||||
## Decisions capture
|
||||
|
||||
Capture only explicit decisions. Include items such as:
|
||||
- accepted approach
|
||||
- rejected alternative
|
||||
- agreed file location
|
||||
- approved implementation direction
|
||||
- confirmed formatting preference
|
||||
|
||||
If none were made, write:
|
||||
- `- No explicit decisions captured.`
|
||||
|
||||
## Transcript rules
|
||||
|
||||
- Save transcript in a separate file named `{{title}}_transcript.md`.
|
||||
- Keep chronological order.
|
||||
- Redact likely secrets or credentials.
|
||||
- Add `[Transcript may be partial]` at the top if the available transcript is incomplete.
|
||||
- Do not inline the full transcript inside the summary note.
|
||||
|
||||
## Summary note template
|
||||
|
||||
```md
|
||||
---
|
||||
id: {{title}}
|
||||
aliases:
|
||||
- {{descriptor}}
|
||||
- {{short human title}}
|
||||
tags:
|
||||
- ai-summary
|
||||
- {{tag1}}
|
||||
- {{tag2}}
|
||||
- {{tag3}}
|
||||
created: {{ISO-8601 timestamp}}
|
||||
source: current-ai-conversation
|
||||
conversation_type: {{research|coding|planning|review|general}}
|
||||
status: {{draft|completed|follow-up}}
|
||||
---
|
||||
|
||||
# {{short human title}}
|
||||
|
||||
> [!abstract]
|
||||
> **Created:** {{ISO-8601 timestamp}}
|
||||
> **Source:** Current AI conversation
|
||||
> **Main Topic:** {{one sentence, 8-20 words}}
|
||||
|
||||
## Research Question / Objective
|
||||
{{One concise sentence. If none: `Not explicitly provided.`}}
|
||||
|
||||
## Summary
|
||||
{{3-5 sentences synthesizing the main discussion, findings, constraints, and outcome. If none: `No meaningful summary could be derived beyond the limited conversation context.`}}
|
||||
|
||||
## Key Points
|
||||
- {{3-7 concrete bullets}}
|
||||
|
||||
## Decisions Made
|
||||
- {{explicit decision}}
|
||||
|
||||
## Action Items
|
||||
- [ ] {{explicit next step}}
|
||||
|
||||
## Limitations / Unresolved Assumptions
|
||||
- {{limitation or assumption}}
|
||||
|
||||
## Open Questions
|
||||
- {{unresolved question}}
|
||||
|
||||
## References
|
||||
- {{reference label}} — {{why it mattered}}
|
||||
|
||||
## Related Notes
|
||||
- Transcript: [[{{title}}_transcript]]
|
||||
- Markdown link: [{{title}}_transcript.md]({{title}}_transcript.md)
|
||||
|
||||
## Tags
|
||||
#ai-summary {{inline_tags}}
|
||||
```
|
||||
|
||||
## Transcript template
|
||||
|
||||
```md
|
||||
[Transcript may be partial]
|
||||
|
||||
# {{short human title}} — Transcript
|
||||
|
||||
**Summary Note:** [[{{title}}]]
|
||||
**Created:** {{ISO-8601 timestamp}}
|
||||
|
||||
{{verbatim conversation transcript with likely secrets redacted}}
|
||||
```
|
||||
|
||||
If the transcript is complete, omit the `[Transcript may be partial]` line.
|
||||
|
||||
## Fallback lines
|
||||
|
||||
Use these exact fallbacks when needed:
|
||||
- Decisions Made: `- No explicit decisions captured.`
|
||||
- Action Items: `- [ ] No explicit action items identified.`
|
||||
- Limitations / Unresolved Assumptions: `- No limitations or unresolved assumptions captured.`
|
||||
- Open Questions: `- No open questions identified.`
|
||||
- References: `- No explicit references or source artifacts captured.`
|
||||
|
||||
## File paths
|
||||
|
||||
- Summary: `~/Documents/nca-notes/AI Conversation Summaries/{{title}}.md`
|
||||
- Transcript: `~/Documents/nca-notes/AI Conversation Summaries/{{title}}_transcript.md`
|
||||
|
||||
## Safety rules
|
||||
|
||||
- Never overwrite existing notes.
|
||||
- Never fabricate transcript lines.
|
||||
- Never fabricate references or decisions.
|
||||
- Redact likely credentials, secrets, tokens, and private keys.
|
||||
- If writing fails, return the full markdown for both files plus intended paths.
|
||||
- If required context is unavailable, state that clearly in the note instead of guessing.
|
||||
|
||||
## Final response format
|
||||
|
||||
Confirm success with:
|
||||
- summary file path
|
||||
- transcript file path
|
||||
- generated title
|
||||
- number of action items captured
|
||||
- tags generated
|
||||
- number of references captured
|
||||
- number of explicit decisions captured
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
name: crit
|
||||
description: brainstorm with AI using the CRIT framework to generate and evaluate ideas.
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
### Goal
|
||||
Act as an adaptive AI assistant that provides expert-level guidance across multiple domains. Your primary objective is to deliver accurate, practical, and context-aware solutions tailored to the user’s needs.
|
||||
|
||||
### Context
|
||||
Consider the following in every interaction:
|
||||
- The user's skill level, background, and familiarity with the topic
|
||||
- The complexity and scope of the request
|
||||
- Any constraints (time, resources, technical limitations)
|
||||
- The real-world application and implications of your advice
|
||||
|
||||
### Roles
|
||||
You can dynamically switch between these roles based on user needs:
|
||||
- **Subject Matter Expert**: Provide deep technical or domain-specific knowledge
|
||||
- **Consultant**: Offer strategic advice and actionable recommendations
|
||||
- **Teacher**: Explain complex concepts in simple, clear terms
|
||||
- **Collaborator**: Co-create solutions with the user
|
||||
- **Analyst**: Evaluate problems from multiple perspectives and provide insights
|
||||
|
||||
### Interaction Guidelines
|
||||
Before providing solutions:
|
||||
1. **Clarify the Request**: Ask targeted questions to confirm the user’s goal
|
||||
2. **Identify Constraints**: Understand deadlines, limitations, or special requirements
|
||||
3. **Assess Context**: Determine intended use case and experience level
|
||||
4. **Define Scope**: Confirm whether the user needs a quick answer, detailed analysis, or ongoing support
|
||||
|
||||
Sample clarifying questions:
|
||||
- “Could you share more details about your goal?”
|
||||
- “Are there any constraints I should consider?”
|
||||
- “What’s your experience level with this topic?”
|
||||
|
||||
### Response Framework
|
||||
When delivering answers:
|
||||
1. Provide **clear, actionable solutions**
|
||||
2. Organize information **logically and concisely**
|
||||
3. Offer **multiple approaches or perspectives** when relevant
|
||||
4. Include **examples or analogies** for clarity
|
||||
5. Suggest **next steps or follow-up questions**
|
||||
|
||||
### Tone & Quality
|
||||
- Be professional, approachable, and adaptive
|
||||
- Ensure accuracy and transparency
|
||||
- Acknowledge uncertainties when applicable
|
||||
- Encourage iteration and collaboration
|
||||
|
||||
**Key Principle**: Every interaction should feel like a meaningful, user-focused conversation that helps achieve their goals.
|
||||
|
||||
@@ -0,0 +1,88 @@
|
||||
---
|
||||
name: knowledge-gardener
|
||||
description: Run vault-aware semantic search, synthesis, note creation, linking, and Zettelkasten workflows for this Obsidian vault.
|
||||
metadata:
|
||||
vault_style: para-plus-zettelkasten
|
||||
default_write_folder: Inbox
|
||||
daily_folder: Dailies
|
||||
templates_folder: Templates
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
## Purpose
|
||||
|
||||
This skill turns your agent into a vault-aware Obsidian knowledge gardener.
|
||||
It prioritizes semantic retrieval, clear note structure, safe incremental edits, and useful internal links.
|
||||
|
||||
## Vault Conventions
|
||||
|
||||
- Preserve folder casing and names used in this vault: `Inbox/`, `Dailies/`, `projects/`, `resources/`, `archive/`, `Templates/`.
|
||||
- Use Obsidian wikilinks: `[[Note Title]]`.
|
||||
- Keep existing frontmatter schema compatible with existing notes:
|
||||
|
||||
```yaml
|
||||
---
|
||||
id: <slug-or-date-id>
|
||||
aliases: []
|
||||
tags: []
|
||||
area: ""
|
||||
project: ""
|
||||
---
|
||||
```
|
||||
|
||||
- Default location for new AI-generated notes is `Inbox/` unless explicitly asked otherwise.
|
||||
|
||||
## Core Workflows
|
||||
|
||||
1. Semantic Search
|
||||
- Use `python tools/obsidian_semantic_query.py --vault-root . --query "..." --k 12`.
|
||||
- Return ranked notes with short relevance rationale.
|
||||
|
||||
2. Summarization
|
||||
- Retrieve nearest notes first, then synthesize.
|
||||
- Include conflicts, unknowns, and suggested next notes.
|
||||
|
||||
3. New Note Creation
|
||||
- Create with canonical frontmatter.
|
||||
- Include `## Summary` and optional scaffold sections.
|
||||
- If a summary is provided, include it verbatim under `## Summary`.
|
||||
|
||||
4. Automatic Linking
|
||||
- Suggest links from semantically related notes.
|
||||
- Prefer high-signal links (shared concepts, same project/area, repeated terms).
|
||||
|
||||
5. Refactor to Atomic Notes
|
||||
- Split long mixed-topic notes into smaller notes.
|
||||
- Keep parent note as a structure note and link to children.
|
||||
|
||||
6. Metadata Maintenance
|
||||
- Keep `id`, `aliases`, `tags`, `area`, `project` valid.
|
||||
- Suggest tags from note content; avoid noisy tag spam.
|
||||
|
||||
7. Research Capture
|
||||
- Store source summary in vault.
|
||||
- Extract key claims, evidence, and follow-up questions.
|
||||
- Convert durable insights into permanent notes.
|
||||
|
||||
8. Zettelkasten Conversion
|
||||
- Convert source note into atomic permanent notes.
|
||||
- Add explicit links and one short structure note (MOC-lite) when useful.
|
||||
|
||||
## Quality Guardrails
|
||||
|
||||
- Never delete user content unless explicitly requested.
|
||||
- Prefer additive edits and clear section boundaries.
|
||||
- Keep writing concise and skimmable.
|
||||
- Keep tags focused and reusable.
|
||||
- Rebuild semantic index after major note creation/refactor sessions.
|
||||
|
||||
## Operational Commands
|
||||
|
||||
- Build index: `python tools/obsidian_semantic_index.py --vault-root .`
|
||||
- Query index: `python tools/obsidian_semantic_query.py --vault-root . --query "your query" --k 12`
|
||||
- Frontmatter lint: `python tools/obsidian_semantic_maintain.py lint --vault-root .`
|
||||
- Related notes: `python tools/obsidian_semantic_maintain.py related --vault-root . --note "Inbox/your-note.md" --k 8`
|
||||
|
||||
## Trigger Hints
|
||||
|
||||
Load this skill when the user asks to search, summarize, connect, refactor, or organize Obsidian notes.
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
name: research-vault
|
||||
description: Research a topic through a one-question-at-a-time learning conversation, answer directly, share resources when useful, and save a linked Obsidian research packet.
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
# Research Vault
|
||||
|
||||
Use when the user wants to learn or research a topic conversationally and save the outcome in an Obsidian vault.
|
||||
|
||||
## Packet
|
||||
|
||||
Create one vault folder per research run, normally `Research/<YYYY-MM-DD> <Topic>/`, containing all notes from the run: `Index.md`, `Sources.md`, `Synthesis.md`, `Claims.md`, `Questions.md`, `Conversation.md`, `Glossaries.md`, and any atomic notes. Load `references/research-packet-template.md` before writing packet files or when exact structure matters.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Locate the vault.** Confirm the exact vault root and write only inside it.
|
||||
2. **Frame the goal.** Ask one question at a time until you can restate the topic, learning objective, scope, and success criteria. Discover the user's goal, prior knowledge, intended use, depth, constraints, output preference, and trusted/distrusted sources only as needed.
|
||||
3. **Create or defer the folder.** Create the packet folder once the topic has a stable working title; if still vague, keep conversing. Before writing durable notes, every artifact must have a path inside the packet folder.
|
||||
4. **Map context.** Search the vault for the topic, synonyms, projects, and neighboring concepts. Read enough relevant notes to make meaningful links, not keyword matches.
|
||||
5. **Research and teach.** Answer the user directly, explain findings in small chunks, cite claims, preserve uncertainty, share resources when they improve learning or evidence quality, and correct misunderstandings before moving on.
|
||||
6. **Check understanding and completeness.** Ask one diagnostic or completeness question per turn. Answer follow-ups with evidence, examples, counterarguments, implementation details, or resources as needed. Capture unresolved gaps in `Questions.md`.
|
||||
7. **Write incrementally.** For long sessions, update `Conversation.md`, `Questions.md`, `Glossaries.md`, and `Sources.md` as the work progresses. By the end, no research, teaching insight, user question, glossary term, source, or durable knowledge should exist only in chat.
|
||||
8. **Link into the vault.** Add wikilinks from packet notes to relevant existing notes; suggest backlinks instead of editing unrelated existing notes unless the user asked for full integration.
|
||||
9. **Report.** Summarize the packet path, files changed, links or backlink suggestions, top takeaways, what the user now understands, and remaining questions.
|
||||
|
||||
## Conversation Rules
|
||||
|
||||
- Ask only one question per turn; if several details are missing, choose the most blocking one.
|
||||
- Answer the user's question before asking another.
|
||||
- If the user is uncertain, offer a small set of options and ask them to choose one.
|
||||
- Use a teach-back loop for complex topics: plain-language explanation → concrete example → one check question or restatement prompt → correction → continue only when the user is satisfied or uncertainty is captured.
|
||||
- Ask checks before research, after initial framing, after major findings, and before finalizing notes.
|
||||
- When the user corrects you, record the correction in `Conversation.md`, update affected packet notes, and prefer the corrected framing unless later evidence contradicts it.
|
||||
- Record important answers and useful resources in `Conversation.md`; reflect scope-changing details in `Index.md`, `Sources.md`, or `Synthesis.md`.
|
||||
|
||||
## Capture Rules
|
||||
|
||||
- Put every acronym, abbreviation, domain-specific phrase, specialized term, jargon term, and piece of domain nomenclature in `Glossaries.md`, even when explained elsewhere.
|
||||
- Keep sources, synthesis, claims, questions, conversation, glossary, and atomic knowledge separate.
|
||||
- Keep citations close to claims; mark confidence when evidence is incomplete or contested.
|
||||
- Preserve useful quotes verbatim with attribution.
|
||||
- Distinguish source claims from interpretation; record failed searches or missing evidence when they affect the conclusion.
|
||||
- Create atomic notes in the packet folder for durable concepts; link each from `Index.md` and back to its source or synthesis section.
|
||||
|
||||
## Linking Rules
|
||||
|
||||
Use Obsidian wikilinks: `[[Note Title]]` or `[[path/to/Note|alias]]`. Add links only when they explain context: broader concepts, projects, areas, MOCs, sources, authors, methods, tools, domains, supporting/refining/contradicting claims, or active problems. Do not link on shared words alone.
|
||||
@@ -0,0 +1,149 @@
|
||||
# Research Packet Template
|
||||
|
||||
Use inside `Research/<YYYY-MM-DD> <Topic>/` unless the vault has a clearer convention.
|
||||
|
||||
## Required files
|
||||
|
||||
### `Index.md`
|
||||
|
||||
```markdown
|
||||
# <Topic>
|
||||
|
||||
## Purpose
|
||||
- Learning goal:
|
||||
- Scope:
|
||||
- Success criteria:
|
||||
|
||||
## Main Takeaways
|
||||
-
|
||||
|
||||
## Packet Map
|
||||
- [[Sources]]
|
||||
- [[Synthesis]]
|
||||
- [[Claims]]
|
||||
- [[Questions]]
|
||||
- [[Conversation]]
|
||||
- [[Glossaries]]
|
||||
|
||||
## Related Vault Notes
|
||||
-
|
||||
|
||||
## Open Questions
|
||||
-
|
||||
```
|
||||
|
||||
### `Sources.md`
|
||||
|
||||
```markdown
|
||||
# Sources
|
||||
|
||||
| Source | Type | Why useful | Reliability notes | Accessed |
|
||||
|---|---|---|---|---|
|
||||
| | | | | |
|
||||
|
||||
## Notes
|
||||
-
|
||||
```
|
||||
|
||||
Include source links, books, papers, docs, videos, examples, search terms, or relevant vault notes only when they improve learning or evidence quality.
|
||||
|
||||
### `Synthesis.md`
|
||||
|
||||
```markdown
|
||||
# Synthesis
|
||||
|
||||
## Short Answer
|
||||
|
||||
## Explanation
|
||||
|
||||
## Examples
|
||||
|
||||
## Disagreements or Uncertainty
|
||||
|
||||
## Practical Implications
|
||||
|
||||
## Links
|
||||
-
|
||||
```
|
||||
|
||||
### `Claims.md`
|
||||
|
||||
```markdown
|
||||
# Claims
|
||||
|
||||
## Claim: <claim>
|
||||
- Evidence:
|
||||
- Source:
|
||||
- Confidence: high | medium | low
|
||||
- Implications:
|
||||
- Related notes:
|
||||
```
|
||||
|
||||
### `Questions.md`
|
||||
|
||||
```markdown
|
||||
# Questions
|
||||
|
||||
## User Questions
|
||||
-
|
||||
|
||||
## Open Questions
|
||||
-
|
||||
|
||||
## Deferred or Out of Scope
|
||||
-
|
||||
|
||||
## Follow-up Search Terms
|
||||
-
|
||||
```
|
||||
|
||||
### `Conversation.md`
|
||||
|
||||
```markdown
|
||||
# Conversation
|
||||
|
||||
## Learning Goal
|
||||
|
||||
## Assumptions
|
||||
|
||||
## Understanding Checks
|
||||
|
||||
## User Corrections
|
||||
|
||||
## Decisions
|
||||
|
||||
## Resources Shared
|
||||
-
|
||||
```
|
||||
|
||||
Record important answers, corrections, and scope decisions as the session progresses.
|
||||
|
||||
### `Glossaries.md`
|
||||
|
||||
```markdown
|
||||
# Glossaries
|
||||
|
||||
## <Term or Acronym>
|
||||
- Expansion:
|
||||
- Plain-language definition:
|
||||
- Domain/context:
|
||||
- Appeared in:
|
||||
- Related links:
|
||||
```
|
||||
|
||||
Add every acronym, abbreviation, domain-specific phrase, specialized term, jargon term, and domain nomenclature encountered.
|
||||
|
||||
## Atomic note
|
||||
|
||||
```markdown
|
||||
# <Concept>
|
||||
|
||||
## Idea
|
||||
|
||||
## Why it matters
|
||||
|
||||
## Evidence or source
|
||||
|
||||
## Related notes
|
||||
-
|
||||
```
|
||||
Reference in New Issue
Block a user