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
• 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]]

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:

   ## 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).