Knowledge Synthesis

---
name: knowledge-synthesis
description: Synthesize knowledge from multiple sources — including a conversation, PR, or investigation — into Zettelkasten notes for a personal Logseq wiki. Use when creating wiki pages, integrating academic research, building interconnected knowledge with [[links]] and #[[tags]], or whenever the user says "synthesize this to my wiki" / "add this to my wiki" / "synthesize this to my personal wiki" / "write this up in my notes."
---

# Knowledge Synthesis

Synthesize knowledge from multiple sources into interconnected Zettelkasten notes.

## When to Use This Skill

**Complex topics requiring**:
- Multi-source research (3+ authoritative sources)
- Academic literature integration
- Book zettels with author information
- Systematic concept mapping
- Both supporting and contradicting perspectives

**Simple topics** (single source, straightforward): Handle directly without full workflow

## Core Workflow

> For systematic web research before synthesizing, apply the `meta-research-workflow` skill.

### 1. Research Phase

- Search multiple source types (academic, books, authoritative sites)
- Find foundational works and key authors
- Identify supporting AND contradicting evidence
- Cross-reference across sources

### 2. Synthesis Phase

- Create main page with comprehensive coverage
- Create supporting pages for related concepts
- Create book zettels for referenced works
- Integrate with existing knowledge network

### 3. Integration Phase

- Update journal with synthesis summary, using this exact nested-bullet shape (established in the personal-wiki repo's CLAUDE.md, reused across every synthesis skill so the journal reads the same regardless of which skill wrote it):
  ```markdown
  - Asked/discussed <topic>; <one-line summary of what was written>
  	- ## Created Pages
  		- [[New Page]] — one-line description
  	- ## Updated Pages
  		- [[Existing Page]] — what changed on it
  ```
- Link to related existing pages
- Ensure bidirectional connections

## Zettelkasten Structure

Every note should include:

1. **Core Definition** - Brief, clear explanation
2. **Background/Context** - Origins, key figures
3. **Key Characteristics** - Essential features
4. **Applications/Usage** - Use cases
5. **Related Concepts** - `[[links]]` to other concepts
6. **Significance** - Why it matters
7. **Related Topics** - `#[[Tag1]] #[[Tag2]]`

## Atomicity — Keep Notes Small

One page = one concept, one fact-set, or one point-in-time snapshot. This is the difference between a wiki that stays useful and a pile of sprawling documents that get stale and unreadable.

**Split, don't accumulate.** If a page starts covering more than one distinct concept, or mixes durable facts with numbers that will change (a balance, a market estimate, a return calculation), split it *before* it grows further — don't wait for a cleanup pass:
- **Static facts** (a purchase, a decision, a one-time event) → their own page, written once.
- **Time-varying data** (account balances, valuations, running totals) → a **dated snapshot page** (`<Topic> Snapshot - YYYY-MM-DD.md` or `<Topic> - YYYY-MM-DD.md`), never edited after the fact — a new snapshot gets a new page, linked in order from a `## Snapshots` list on the hub page. See `Financial Snapshot - 2026-06-23.md` for the pattern already in use in this wiki.
- **General, reusable concepts** (a tax rule, a financial framework, a methodology) → their own page, separate from any specific person/property/event that happens to illustrate it. The specific instance links to the concept page as a worked example; the concept page doesn't hold the instance's numbers.
- **A hub/index page** ties the pieces together: a couple of sentences of orientation plus a `## Related Pages` (and `## Snapshots`, if applicable) list with one-line descriptions — it should not itself contain the detailed content.

**When asked to "add" analysis to an existing page**, check first whether the addition is really a new atomic note that should link back, rather than a new section bolted onto the existing page. A page that's accumulated several unrelated `## Section` headers over a session is a signal it should have been split as you went.

**Test before you write**: could this page's title alone tell someone what's on it, without opening it? If the honest title would need "and" or "part 2" to cover the contents, split it.

## Linking Strategy

| Type | Format | Examples |
|------|--------|----------|
| People | `[[Name]]` | `[[Alan Turing]]` |
| Concepts | `[[Concept]]` | `[[Machine Learning]]` |
| Technologies | `[[Tech]]` | `[[Kubernetes]]` |
| Retailers | `[[Name]]` | `[[Lowe's]]`, `[[IKEA]]`, `[[Amazon]]` |
| Products/Parts | `[[Product Name]]` | `[[IKEA VIDGA Curtain Track]]` |
| Tags | `#[[Tag]]` | `#[[Computer Science]]` |

## Tagging Guidelines

Use 3-7 tags per note:
- **Disciplinary**: `#[[Computer Science]]`, `#[[Philosophy]]`
- **Methodological**: `#[[Design Patterns]]`, `#[[Best Practices]]`
- **Categorical**: `#[[Tools]]`, `#[[Concepts]]`, `#[[Theories]]`
- **Contextual**: `#[[Business]]`, `#[[Open Source]]`

## Quality Standards

- Accurate attribution with source URLs
- Meaningful bidirectional links (not link spam)
- Multi-source validation for complex topics
- Both supporting and critical perspectives
- Comprehensive coverage of major aspects

## Wiki Root Resolution

**Don't ask the user where their wiki is or what format it's in** ("Obsidian?", "Confluence?", "Google Doc?") — this skill's trigger phrases ("synthesize this to my wiki" etc.) always mean the local Logseq/markdown vault resolved below. Resolve it fresh each time, silently:

1. If `$WIKI_PATH` is set in the environment, use it as the wiki root.
2. Else, if a `wiki_path` shell function is available (defined in dotfiles' `.shell/functions.sh`), run it (`wiki_path`) and use its output as the root.
3. Else, fall back to `~/Documents/personal-wiki` if it exists, then `~/Documents/notes`.
4. **The `pages/` and `journals/` hierarchy is always relative to the resolved root — never assume an extra `logseq/` nesting.** Some machines' graphs put content directly at `<root>/pages/` and `<root>/journals/`; others nest it at `<root>/logseq/pages/` and `<root>/logseq/journals/` (e.g. a graph opened as `~/Documents/personal-wiki/logseq`). Check which one actually exists (`Glob`) before writing — don't guess. If it's a brand-new graph with neither present, create `<root>/pages/` and `<root>/journals/` directly (no `logseq/` nesting) unless the user says otherwise.
5. Do this resolution once per session and reuse the result — don't re-resolve per page.

## File Locations

- **Pages**: `<resolved root>/pages/*.md` (or `<resolved root>/logseq/pages/*.md` if that's the layout already in use on this machine — see Wiki Root Resolution above)
- **Journals**: `<resolved root>/journals/YYYY_MM_DD.md` (or `.../logseq/journals/...`, same caveat)

---

## Related Skills

| Skill | When to apply |
|-------|--------------|
| `knowledge-literature-review` | Survey a research area and build a citation graph before synthesizing |
| `meta-research-workflow` | Systematic multi-source web research before writing notes |
| `notebooklm` | Query source-grounded answers from uploaded documents |
| `knowledge-confluence-sync` | Publish synthesized notes to a Confluence wiki |
| `mermaid-diagrams` | Create concept maps or knowledge-graph diagrams |
| `home:2-research` / `home:full` | Research phase uses the Product & Retailer Zettel Template below when surfacing materials |
| `product-selection` | Uses the Product & Retailer Zettel Template for candidates and the Decision Write-Back Pattern to record the final pick |

## Book Zettel Template

For referenced books, create dedicated pages:
- Title as page name
- Author with credentials
- Key concepts covered
- Cross-references to related concepts
- Tags: `#[[Books]]`, `#[[Authors]]`

**Verify structural facts, don't recall them.** A book's table of contents, chapter/section names, and publication year are exactly the kind of precise detail that erodes in trained memory. Before writing a chapter list or part structure into the page, confirm it against a real source (publisher page, a chapter-by-chapter review, the book itself) — the same "run it, don't read it" standard CLAUDE.md applies elsewhere.

**Don't inline-create an author stub.** If the author doesn't have a page yet, leave `[[Author Name]]` as a redlink rather than spinning up a bio page as a side effect of the book zettel — that's out of scope for a single synthesis pass. Wiki-wide redlink/stub creation is handled separately by the `knowledge:maintain` maintenance pass.

## Product & Retailer Zettel Template

For physical products, parts, and retailers encountered during research (e.g. home project planning, purchases):

**Check first, don't duplicate.** Before creating a page, `Grep`/`Glob` the resolved `pages/` directory (see Wiki Root Resolution) for an existing page on that retailer/product/part. If one exists, read it and only append genuinely new information (a better price, a new source, a caveat) — never write a redundant duplicate page. Skip creating a page at all for one-off consumables (a single tube of caulk) that won't recur across future research.

Create a page when the retailer/product/part is distinctive and likely to come up again:
- **Retailer pages** (`<pages dir>/<Retailer Name>.md`): what they carry, price positioning, any recurring pros/cons noted across projects.
- **Product/part pages** (`<pages dir>/<Product Name>.md`): core definition, price/quality tier, why recommended (or not), at least one **source URL** — never state a price or quality claim without attribution.
- Link every product page to its retailer (`[[Retailer]]`) and to related products/concepts.
- Tags: `#[[Products]]`, plus a category tag (e.g. `#[[Home Improvement]]`, `#[[Tools]]`).
- Link back to the context that surfaced it (e.g. a house/location page, project page) so the page is discoverable from both directions.

## Decision Write-Back Pattern

When a synthesis or research process ends in the user picking one option (a product, a method, an approach), record that choice back to the relevant wiki page rather than letting the decision live only in a chat transcript or a one-off comparison table. Any skill that produces a decision should use this pattern instead of inventing its own logging format:

1. **Locate or create the relevant page** — the project/room/topic page the decision belongs to (e.g. a kitchen remodel page, a `home_plans/<project>/plan.md`).
2. **Update or add a `## Decisions Made / Locked` section**:
   ```markdown
   ## Decisions Made / Locked
   - **[Category]**: [[Chosen Option]] — [key differentiator, e.g. finish match, price, longevity] — [rationale in one sentence] — [ ] Approved / [ ] Ordered
   ```
3. **Move the item out of any "outstanding" or "options under consideration" list** it was previously tracked in, so the page doesn't show the same decision as both pending and resolved.
4. **Link the chosen option** to its Product & Retailer Zettel (above) if one exists, so the decision and the product knowledge stay connected.
5. **Record the rationale in one sentence** — why this option won, not a restatement of its specs (those live on the product page).

Used by: `product-selection` (recording a chosen product), `home:3-plan` (recording a chosen method/approach in a plan's Decisions & Open Questions section).