| name | awesome-search-knowledge-graph |
| description | Build and maintain a dense semantic knowledge graph about search and IR inside an Obsidian vault. Triggers on article URLs, article titles or names (from Clippings/, raw_articles/, or unprocessed vault notes), and requests to enrich or reprocess existing notes for concepts, people, companies, tools, or topics. |
Awesome Search Knowledge Graph
Use this skill when the user asks to process any article into the knowledge graph. Triggers include:
- A URL to a new article to fetch and process
- A title or name of an article already in the vault (e.g. in
Clippings/, raw_articles/, or Awesome Search/Articles/) that hasn't been fully processed yet
- A request to process, enrich, or link an existing note that is missing entity extraction, wikilinks, or related notes
- A request to update or reprocess a topic, concept, person, company, or tool note
Goal
Build a dense but meaningful semantic knowledge graph inside Obsidian. Prefer creating high-quality conceptual connections when substantial thematic overlap exists.
Vault Structure
Awesome Search/Articles/ — one note per processed article
Awesome Search/Concepts/ — technical ideas, methods, algorithms
Awesome Search/Topics/ — broader thematic areas
Awesome Search/People/ — authors, researchers, practitioners
Awesome Search/Companies/ — organisations mentioned
Awesome Search/Case Studies/ — real-world implementations
Vault Access
Always use the Obsidian MCP server for all vault operations — never access the vault directly via the filesystem (no Read/Write/Bash file tools). The MCP server is the only sanctioned way to read, search, create, and edit notes.
Invariant: index.md mirrors HOME.md
After every workflow run (or any operation that modifies HOME.md), read the current content of HOME.md and overwrite index.md with that exact content. These two files must always be identical. Do this as the final step before reporting completion.
Workflow
When asked to read/process articles, follow these steps in order:
1. Download the article
Fetch the full article content from the provided URL using WebFetch. No confirmation needed.
2. Save the article note
Save to Awesome Search/Articles/<Title>.md using the standard note structure (see below).
3. Extract entities
- concepts – specific technical ideas, methods, algorithms, terminology
- topics – broader thematic areas grouping multiple concepts/trends/domains
- people, companies, tools
- case studies – concrete real-world implementations, experiments, deployments
Rules:
- Only extract explicitly stated or strongly supported entities.
- Avoid trivial/incidental mentions unless likely to recur across multiple articles.
4. Normalize entities
- Use stable canonical forms; no duplicates under slightly different names.
- Do not merge distinct entities from the same company/product family.
- "agentic retrieval", "agentic search" → shared canonical concept when semantically equivalent.
- Prefer separate notes over incorrect merges.
5. Create or update entity notes
Auto-create/update: Article notes, Concept notes, Person notes, Company notes, Tool notes.
6. Add Obsidian wikilinks
Connect: articles ↔ concepts ↔ people ↔ companies ↔ topics
7. Apply linking rules
- Prioritize meaningful relationships, especially when entities are central to the article or strongly connected to existing notes in the vault.
- Prioritize entities that appear repeatedly or are central to the article's argument.
- Preserve relationship types:
author_of, discusses, implements, compares_to, critiques, works_for
- Factual: must be explicitly stated or strongly supported by the article.
- Semantic: may be inferred when concepts, topics, or discussions substantially overlap.
- Acceptable to create conceptual links between related search, IR, ranking, recommendation, retrieval, and agentic-system topics even when the relationship is implicit.
8. Connect authors through shared concepts
If multiple authors write about the same concept → connect them via shared concept notes.
9. Related Notes sections
Include "Related Notes" sections only for strongly related concepts/entities.
10. Authorship rule
Do NOT assume someone invented something unless explicitly stated.
11. Preserve external URLs
Always capture URLs found in source material:
- Conferences/events: official website URL in note body and frontmatter as
website:
- Companies: official website in frontmatter as
website:
- People: personal blog, homepage, or primary professional URL in frontmatter as
website: or blog:; also as a clickable link in note body
- Tools: repository (GitHub) and/or docs URL in frontmatter as
website: and repo:; also in note body
- Preserve links to external resources (papers, talks, repos, blog posts) in the relevant entity note — do not discard URLs found in source material.
- Prefer the most canonical/stable URL (official site > GitHub > Medium profile).
Note Structure
All notes must follow this structure:
---
# frontmatter: type, title/aliases, tags, source (for articles), website/blog/repo (for entities), related_concepts, related_topics, people, companies, created
---
# Title
Brief summary paragraph.
---
## [Content sections]
## Related Concepts
- [[Concept]]
## Related Articles
- [[Article]]
## People
- [[Person]]
Use Obsidian-compatible Markdown. Preserve source URLs in frontmatter (source:) for article notes.
Entity Frontmatter Fields
| Entity type | Key frontmatter fields |
|---|
| Article | type: article, source:, author:, published:, concepts:, topics: |
| Concept | type: concept, aliases:, tags: |
| Topic | type: topic, aliases:, related_concepts:, related_topics:, articles:, website: |
| Person | type: person, aliases:, website: or blog:, affiliation: |
| Company | type: company, website: |
| Tool | type: tool, website:, repo: |