first commit
This commit is contained in:
@@ -0,0 +1,42 @@
|
||||
# Literature Canvas Workflow
|
||||
|
||||
## Default output
|
||||
|
||||
- `Maps/literature.canvas`
|
||||
|
||||
## Purpose
|
||||
|
||||
Provide a default Obsidian literature graph that:
|
||||
- keeps `Sources/Papers/` as the canonical paper-note surface,
|
||||
- keeps `Knowledge/` as the canonical synthesis surface,
|
||||
- visualizes paper-to-paper and paper-to-knowledge relationships,
|
||||
- stays lightweight enough to refresh after each major Zotero ingestion.
|
||||
|
||||
## Default behavior
|
||||
|
||||
- Use paper-note frontmatter and wikilinks as the primary graph source.
|
||||
- Use `Sources/Papers/*.md` and relevant `Knowledge/*.md` as file nodes.
|
||||
- Create `.canvas` by default for literature ingestion and review workflows.
|
||||
- Treat Mermaid or markdown graph notes as optional legacy companions, not the default graph artifact.
|
||||
- Prefer argument-map structure with `paper`, `claim`, `method`, and `gap` nodes over raw all-to-all paper linking.
|
||||
- Thin edges aggressively; keep only the main reasoning chain and a small number of explicit semantic paper-to-paper relations.
|
||||
- Hide or down-rank side branches when they clutter the display graph.
|
||||
|
||||
## Refresh triggers
|
||||
|
||||
Refresh the literature canvas when:
|
||||
- new Zotero-sourced paper notes are added,
|
||||
- paper notes gain new `linked_knowledge` edges or meaningful wikilinks,
|
||||
- knowledge synthesis notes are updated after a literature pass,
|
||||
- a batch Zotero review or note-ingestion pass finishes,
|
||||
- a full-collection normalization pass changes many paper-note relationships.
|
||||
|
||||
## Recommended command
|
||||
|
||||
```bash
|
||||
python3 "${CLAUDE_PLUGIN_ROOT}/skills/obsidian-literature-workflow/scripts/build_literature_canvas.py" --cwd "$PWD"
|
||||
```
|
||||
|
||||
## Display rule
|
||||
|
||||
- If a second lightweight showcase graph is useful, maintain `Maps/literature-main.canvas` as a filtered presentation copy rather than bloating the default working canvas.
|
||||
@@ -0,0 +1,45 @@
|
||||
# CLAIM EXTRACTION
|
||||
|
||||
Claim extraction should produce reusable literature notes, not vague summaries.
|
||||
|
||||
## Extract at least these fields
|
||||
|
||||
For each paper or source note, identify:
|
||||
- **Claim** — what the paper says it achieves or establishes
|
||||
- **Claim type** — author claim, community consensus, or project interpretation
|
||||
- **Claim strength** — speculative, observed, supported, or strong
|
||||
- **Evidence** — the concrete support for that claim (dataset, metric, experiment, analysis)
|
||||
- **Method** — the approach or mechanism behind the claim
|
||||
- **Limitation** — where the claim may not hold
|
||||
- **Contradicts / weakens** — evidence or conditions that reduce confidence in the claim
|
||||
- **Project relevance** — why this matters for the current project
|
||||
|
||||
## Writing rules
|
||||
|
||||
- Write claims in plain, reusable language.
|
||||
- Distinguish the author claim from your project interpretation.
|
||||
- Do not copy entire abstract sentences when a shorter paraphrase is clearer.
|
||||
- Pair every durable claim with at least one evidence anchor.
|
||||
- Do not promote a claim strength without naming the evidence that justifies the stronger level.
|
||||
|
||||
## Minimal output shape
|
||||
|
||||
This `Key Claims` block is a paper-note projection of the shared Evidence Record contract. Preserve the same evidence anchor, limitation, contradiction, project relevance, and claim strength so downstream synthesis can map it back to the canonical evidence record.
|
||||
|
||||
```md
|
||||
## Key Claims
|
||||
- Claim: ...
|
||||
- Claim type: author claim | community consensus | project interpretation
|
||||
- Claim strength: speculative | observed | supported | strong
|
||||
- Evidence: ...
|
||||
- Method: ...
|
||||
- Limitation: ...
|
||||
- Contradicts / weakens: ...
|
||||
- Project relevance: ...
|
||||
```
|
||||
|
||||
## Promotion rule
|
||||
|
||||
If a claim is reusable across multiple papers or sources, promote it from a paper note into `Knowledge/` instead of leaving it stranded in `Sources/Papers/`.
|
||||
|
||||
Only promote claims that include both an evidence anchor and a claim strength. If the evidence is weak or indirect, keep the claim as `speculative` or `observed` and preserve the uncertainty.
|
||||
@@ -0,0 +1,26 @@
|
||||
# Legacy Literature Map Workflow
|
||||
|
||||
This reference is kept for backwards compatibility only.
|
||||
|
||||
## Legacy output
|
||||
|
||||
- `Knowledge/Literature-Map.md`
|
||||
|
||||
## Current default
|
||||
|
||||
- Use `CANVAS-WORKFLOW.md` for the current default literature graph artifact.
|
||||
- The default graph is now `Maps/literature.canvas`, not a Mermaid note.
|
||||
- Keep this markdown workflow only when a note-based map is specifically requested or needed for compatibility.
|
||||
|
||||
## Refresh triggers
|
||||
|
||||
Refresh the markdown map only when:
|
||||
- new Zotero-sourced paper notes are added,
|
||||
- paper-note links or metadata materially change,
|
||||
- a batch literature review finishes.
|
||||
|
||||
## Recommended command
|
||||
|
||||
```bash
|
||||
python3 "${CLAUDE_PLUGIN_ROOT}/skills/obsidian-literature-workflow/scripts/build_literature_graph.py" --cwd "$PWD"
|
||||
```
|
||||
@@ -0,0 +1,3 @@
|
||||
# LITERATURE CANVAS
|
||||
|
||||
The default literature canvas lives at Maps/literature.canvas and should stay sparse, argument-oriented, and source-backed.
|
||||
@@ -0,0 +1,3 @@
|
||||
# LITERATURE OVERVIEW
|
||||
|
||||
Literature overview notes summarize the current field view for the project and must link source paper notes.
|
||||
@@ -0,0 +1,3 @@
|
||||
# METHOD TAXONOMY
|
||||
|
||||
Method taxonomy notes group methods across papers and should link each taxonomy entry back to supporting paper notes.
|
||||
@@ -0,0 +1,3 @@
|
||||
# PAPER NOTE SCHEMA
|
||||
|
||||
Use a strong paper schema with metadata, project relevance, summary, claims, methods, evidence, limitations, connections, and open questions.
|
||||
@@ -0,0 +1,3 @@
|
||||
# RESEARCH GAPS
|
||||
|
||||
Research gap notes must state the gap, why it matters, and which paper notes support it.
|
||||
Reference in New Issue
Block a user