flonat-research 0.1.0

package/skills/shared/venue-guides/venue_writing_styles.md

@@ -0,0 +1,321 @@
+# Venue Writing Styles: Master Guide
+
+This guide provides an overview of how writing style varies across publication venues. Understanding these differences is essential for crafting papers that read like authentic publications at each venue.
+
+**Last Updated**: 2024
+
+---
+
+## The Style Spectrum
+
+Scientific writing style exists on a spectrum from **broadly accessible** to **deeply technical**:
+
+```
+Accessible ◄─────────────────────────────────────────────► Technical
+
+Nature/Science    PNAS    Cell    IEEE Trans    NeurIPS    Specialized
+   │                │       │         │            │         Journals
+   │                │       │         │            │            │
+   ▼                ▼       ▼         ▼            ▼            ▼
+General           Mixed   Deep     Field      Dense ML      Expert
+audience         depth  biology   experts    researchers    only
+```
+
+## Quick Style Reference
+
+| Venue Type | Audience | Tone | Voice | Abstract Style |
+|------------|----------|------|-------|----------------|
+| **Nature/Science** | Educated non-specialists | Accessible, engaging | Active, first-person OK | Flowing paragraphs, no jargon |
+| **Cell Press** | Biologists | Mechanistic, precise | Mixed | Summary + eTOC blurb + Highlights |
+| **Medical (NEJM/Lancet)** | Clinicians | Evidence-focused | Formal | Structured (Background/Methods/Results/Conclusions) |
+| **PLOS/BMC** | Researchers | Standard academic | Neutral | IMRaD structured or flowing |
+| **IEEE/ACM** | Engineers/CS | Technical | Passive common | Concise, technical |
+| **ML Conferences** | ML researchers | Dense technical | Mixed | Numbers upfront, key results |
+| **NLP Conferences** | NLP researchers | Technical | Varied | Task-focused, benchmarks |
+
+---
+
+## High-Impact Journals (Nature, Science, Cell)
+
+### Core Philosophy
+
+High-impact multidisciplinary journals prioritize **broad significance** over technical depth. The question is not "Is this technically sound?" but "Why should a scientist outside this field care?"
+
+### Key Writing Principles
+
+1. **Start with the big picture**: Open with why this matters to science/society
+2. **Minimize jargon**: Define specialized terms; prefer common words
+3. **Tell a story**: Results should flow as a narrative, not a data dump
+4. **Emphasize implications**: What does this change about our understanding?
+5. **Accessible figures**: Schematics and models over raw data plots
+
+### Structural Differences
+
+**Nature/Science** vs. **Specialized Journals**:
+
+| Element | Nature/Science | Specialized Journal |
+|---------|---------------|---------------------|
+| Introduction | 3-4 paragraphs, broad → specific | Extensive literature review |
+| Methods | Often in supplement or brief | Full detail in main text |
+| Results | Organized by finding/story | Organized by experiment |
+| Discussion | Implications first, then caveats | Detailed comparison to literature |
+| Figures | Conceptual schematics valued | Raw data emphasized |
+
+### Example: Same Finding, Different Styles
+
+**Nature style**:
+> "We discovered that protein X acts as a molecular switch controlling cell fate decisions during development, resolving a longstanding question about how stem cells choose their destiny."
+
+**Specialized journal style**:
+> "Using CRISPR-Cas9 knockout in murine embryonic stem cells (mESCs), we demonstrate that protein X (encoded by gene ABC1) regulates the expression of pluripotency factors Oct4, Sox2, and Nanog through direct promoter binding, as confirmed by ChIP-seq analysis (n=3 biological replicates, FDR < 0.05)."
+
+---
+
+## Medical Journals (NEJM, Lancet, JAMA, BMJ)
+
+### Core Philosophy
+
+Medical journals prioritize **clinical relevance** and **patient outcomes**. Every finding must connect to practice.
+
+### Key Writing Principles
+
+1. **Patient-centered language**: "Patients receiving treatment X" not "Treatment X subjects"
+2. **Evidence strength**: Careful hedging based on study design
+3. **Clinical actionability**: "So what?" for practicing physicians
+4. **Absolute numbers**: Report absolute risk reduction, not just relative
+5. **Structured abstracts**: Required with labeled sections
+
+### Structured Abstract Format (Medical)
+
+```
+Background: [1-2 sentences on problem and rationale]
+
+Methods: [Study design, setting, participants, intervention, outcomes, analysis]
+
+Results: [Primary outcome with confidence intervals, secondary outcomes, adverse events]
+
+Conclusions: [Clinical implications, limitations acknowledged]
+```
+
+### Evidence Language Conventions
+
+| Study Design | Appropriate Language |
+|-------------|---------------------|
+| RCT | "Treatment X reduced mortality by..." |
+| Observational | "Treatment X was associated with reduced mortality..." |
+| Case series | "These findings suggest that treatment X may..." |
+| Case report | "This case illustrates that treatment X can..." |
+
+---
+
+## ML/AI Conferences (NeurIPS, ICML, ICLR, CVPR)
+
+### Core Philosophy
+
+ML conferences value **novelty**, **rigorous experiments**, and **reproducibility**. The focus is on advancing the state of the art with empirical evidence.
+
+### Key Writing Principles
+
+1. **Contribution bullets**: Numbered list in introduction stating exactly what's new
+2. **Baselines are critical**: Compare against strong, recent baselines
+3. **Ablations expected**: Show what parts of your method matter
+4. **Reproducibility**: Seeds, hyperparameters, compute requirements
+5. **Limitations section**: Honest acknowledgment (increasingly required)
+
+### Introduction Structure (ML Conferences)
+
+```
+[Paragraph 1: Problem motivation - why this matters]
+
+[Paragraph 2: Limitations of existing approaches]
+
+[Paragraph 3: Our approach at high level]
+
+Our contributions are as follows:
+• We propose [method name], a novel approach to [problem] that [key innovation].
+• We provide theoretical analysis showing [guarantees/properties].
+• We demonstrate state-of-the-art results on [benchmarks], improving over [baseline] by [X%].
+• We release code and models at [anonymous URL for review].
+```
+
+### Abstract Style (ML Conferences)
+
+ML abstracts are **dense and numbers-focused**:
+
+> "We present TransformerX, a novel architecture for long-range sequence modeling that achieves O(n log n) complexity while maintaining expressivity. On the Long Range Arena benchmark, TransformerX achieves 86.2% average accuracy, outperforming Transformer (65.4%) and Performer (78.1%). On language modeling, TransformerX matches GPT-2 perplexity (18.4) using 40% fewer parameters. We provide theoretical analysis showing TransformerX can approximate any continuous sequence-to-sequence function."
+
+### Experiment Section Expectations
+
+1. **Datasets**: Standard benchmarks, dataset statistics
+2. **Baselines**: Recent strong methods, fair comparisons
+3. **Main results table**: Clear, comprehensive
+4. **Ablation studies**: Remove/modify components systematically
+5. **Analysis**: Error analysis, qualitative examples, failure cases
+6. **Computational cost**: Training time, inference speed, memory
+
+---
+
+## CS Conferences (ACL, EMNLP, CHI, SIGKDD)
+
+### ACL/EMNLP (NLP)
+
+- **Task-focused**: Clear problem definition
+- **Benchmark-heavy**: Standard datasets (GLUE, SQuAD, etc.)
+- **Error analysis valued**: Where does it fail?
+- **Human evaluation**: Often expected alongside automatic metrics
+- **Ethical considerations**: Bias, fairness, environmental cost
+
+### CHI (Human-Computer Interaction)
+
+- **User-centered**: Focus on humans, not just technology
+- **Study design details**: Participant recruitment, IRB approval
+- **Qualitative accepted**: Interview studies, ethnography valid
+- **Design implications**: Concrete takeaways for practitioners
+- **Accessibility**: Consider diverse user populations
+
+### SIGKDD (Data Mining)
+
+- **Scalability emphasis**: Handle large data
+- **Real-world applications**: Industry datasets valued
+- **Efficiency metrics**: Time and space complexity
+- **Novelty in methods or applications**: Both paths valid
+
+---
+
+## Adapting Between Venue Types
+
+### Journal → ML Conference
+
+When converting a journal paper to conference format:
+
+1. **Condense introduction**: Remove extensive background
+2. **Add contribution list**: Explicitly enumerate contributions
+3. **Restructure results**: Organize as experiments, add ablations
+4. **Remove separate discussion**: Integrate interpretation briefly
+5. **Add reproducibility section**: Seeds, hyperparameters, code
+
+### ML Conference → Journal
+
+When expanding a conference paper to journal:
+
+1. **Expand related work**: Comprehensive literature review
+2. **Detailed methods**: Full algorithmic description
+3. **More experiments**: Additional datasets, analyses
+4. **Extended discussion**: Implications, limitations, future work
+5. **Appendix → main text**: Move important details up
+
+### Specialized → High-Impact Journal
+
+When targeting Nature/Science/Cell from a specialized venue:
+
+1. **Lead with significance**: Why does this matter broadly?
+2. **Reduce jargon by 80%**: Replace technical terms
+3. **Add conceptual figures**: Schematics, models, not just data
+4. **Story-driven results**: Narrative flow, not experiment-by-experiment
+5. **Broaden discussion**: Implications beyond the subfield
+
+---
+
+## Voice and Tone Guidelines
+
+### Active vs. Passive Voice
+
+| Venue | Preference | Example |
+|-------|-----------|---------|
+| Nature/Science | Active encouraged | "We discovered that..." |
+| Cell | Mixed | "Our results demonstrate..." |
+| Medical | Passive common | "Patients were randomized to..." |
+| IEEE | Passive traditional | "The algorithm was implemented..." |
+| ML Conferences | Active preferred | "We propose a method that..." |
+
+### First Person Usage
+
+| Venue | First Person | Example |
+|-------|-------------|---------|
+| Nature/Science | Yes (we) | "We show that..." |
+| Cell | Yes (we) | "We found that..." |
+| Medical | Sometimes | "We conducted a trial..." |
+| IEEE | Less common | Prefer "This paper presents..." |
+| ML Conferences | Yes (we) | "We introduce..." |
+
+### Hedging and Certainty
+
+| Claim Strength | Language |
+|---------------|----------|
+| Strong | "X causes Y" (only with causal evidence) |
+| Moderate | "X is associated with Y" / "X leads to Y" |
+| Tentative | "X may contribute to Y" / "X suggests that..." |
+| Speculative | "It is possible that X..." / "One interpretation is..." |
+
+---
+
+## Common Style Errors by Venue
+
+### Nature/Science Submissions
+
+❌ Too technical: "We used CRISPR-Cas9 with sgRNAs targeting exon 3..."
+✅ Accessible: "Using gene-editing technology, we disabled the gene..."
+
+❌ Dry opening: "Protein X is involved in cellular signaling..."
+✅ Engaging opening: "How do cells decide their fate? We discovered that..."
+
+### ML Conference Submissions
+
+❌ Vague contributions: "We present a new method for X"
+✅ Specific contributions: "We propose Method Y that achieves Z% improvement on benchmark W"
+
+❌ Missing ablations: Only showing full method results
+✅ Complete: Table showing contribution of each component
+
+### Medical Journal Submissions
+
+❌ Missing absolute numbers: "50% reduction in risk"
+✅ Complete: "50% relative reduction (ARR 2.5%, NNT 40)"
+
+❌ Causal language for observational data: "Treatment caused improvement"
+✅ Appropriate: "Treatment was associated with improvement"
+
+---
+
+## Quick Checklist Before Submission
+
+### All Venues
+- [ ] Abstract matches venue style (flowing vs. structured)
+- [ ] Voice/tone appropriate for audience
+- [ ] Jargon level appropriate
+- [ ] Figures match venue expectations
+- [ ] Citation style correct
+
+### High-Impact Journals (Nature/Science/Cell)
+- [ ] Broad significance clear in first paragraph
+- [ ] Non-specialist can understand abstract
+- [ ] Story-driven results narrative
+- [ ] Conceptual figures included
+- [ ] Implications emphasized
+
+### ML Conferences
+- [ ] Contribution list in introduction
+- [ ] Strong baselines included
+- [ ] Ablation studies present
+- [ ] Reproducibility information complete
+- [ ] Limitations acknowledged
+
+### Medical Journals
+- [ ] Structured abstract (if required)
+- [ ] Patient-centered language
+- [ ] Evidence strength appropriate
+- [ ] Absolute numbers reported
+- [ ] CONSORT/STROBE compliance
+
+---
+
+## See Also
+
+- `nature_science_style.md` - Detailed Nature/Science writing guide
+- `cell_press_style.md` - Cell family journal conventions
+- `medical_journal_styles.md` - NEJM, Lancet, JAMA, BMJ guide
+- `ml_conference_style.md` - NeurIPS, ICML, ICLR, CVPR conventions
+- `cs_conference_style.md` - ACL, CHI, SIGKDD guide
+- `reviewer_expectations.md` - What reviewers look for by venue
+
+

package/skills/split-pdf/SKILL.md

@@ -0,0 +1,172 @@
+---
+name: split-pdf
+description: "Use when you need to download, split, and deeply read an academic PDF."
+allowed-tools: Bash(python*), Bash(uv*), Bash(curl*), Bash(wget*), Bash(mkdir*), Bash(ls*), Read, Write, Edit, WebSearch, WebFetch, mcp__refpile__parse_pdf_fulltext, mcp__refpile__parse_pdf_metadata
+argument-hint: [pdf-path-or-search-query]
+---
+
+# Split-PDF: Download, Split, and Deep-Read Academic Papers
+
+**CRITICAL RULE: Never read a full PDF. Never.** Only read the 4-page split files, and only 3 splits at a time (~12 pages). Reading a full PDF will either crash the session with an unrecoverable "prompt too long" error — destroying all context — or produce shallow, hallucinated output. There are no exceptions.
+
+## When This Skill Is Invoked
+
+The user wants you to read, review, or summarize an academic paper. The input is either:
+- A file path to a local PDF (e.g., `./articles/smith_2024.pdf`)
+- A search query or paper title (e.g., `"Gentzkow Shapiro Sinkinson 2014 competition newspapers"`)
+
+**Important:** You cannot search for a paper you don't know exists. The user MUST provide either a file path or a specific search query — an author name, a title, keywords, a year, or some combination that identifies the paper. If the user invokes this skill without specifying what paper to read, ask them. Do not guess.
+
+## Step 1: Acquire the PDF
+
+**Determine the download directory:**
+- **Inside a research project** (has `CLAUDE.md`, `data/`, `paper/`, etc.): use `./articles/` in the project directory (create if needed).
+- **Outside a project** (e.g., ad-hoc reading from Task Management root or general context): use `to-sort/downloads/` in the Task Management folder. This ensures downloaded files persist across sessions.
+
+**If a local file path is provided:**
+- Verify the file exists
+- If the file is NOT already inside the download directory, copy it there (do not move — preserve the original location)
+- Proceed to Step 2
+
+**If a search query or paper title is provided:**
+1. Use WebSearch to find the paper
+2. If WebSearch doesn't yield a direct PDF link, try the bibliography MCP `scholarly_search` tool first (cross-source search). Fallback to Python OpenAlex client:
+   ```python
+   import sys
+   sys.path.insert(0, ".scripts/openalex")
+   from openalex_client import OpenAlexClient
+   client = OpenAlexClient(email="user@example.edu")
+   results = client.search_works(search="paper title here", per_page=5)
+   # Check open_access.oa_url in results for direct PDF links
+   ```
+3. Use WebFetch or Bash (curl/wget) to download the PDF
+4. Save it to the download directory determined above
+5. Proceed to Step 2
+
+**CRITICAL: Always preserve the original PDF.** The downloaded or provided PDF in the download directory must NEVER be deleted, moved, or overwritten at any point in this workflow. The split files are derivatives — the original is the permanent artifact. Do not clean up, do not remove, do not tidy. The original stays.
+
+## Step 2: Split the PDF
+
+Create a subdirectory for the splits and run the splitting script:
+
+```python
+from PyPDF2 import PdfReader, PdfWriter
+import os, sys
+
+def split_pdf(input_path, output_dir, pages_per_chunk=4):
+    os.makedirs(output_dir, exist_ok=True)
+    reader = PdfReader(input_path)
+    total = len(reader.pages)
+    prefix = os.path.splitext(os.path.basename(input_path))[0]
+
+    for start in range(0, total, pages_per_chunk):
+        end = min(start + pages_per_chunk, total)
+        writer = PdfWriter()
+        for i in range(start, end):
+            writer.add_page(reader.pages[i])
+
+        out_name = f"{prefix}_pp{start+1}-{end}.pdf"
+        out_path = os.path.join(output_dir, out_name)
+        with open(out_path, "wb") as f:
+            writer.write(f)
+
+    print(f"Split {total} pages into {-(-total // pages_per_chunk)} chunks in {output_dir}")
+```
+
+**Directory convention (in-project):**
+```
+articles/
+├── smith_2024.pdf                    # original PDF — NEVER DELETE THIS
+└── split_smith_2024/                 # split subdirectory
+    ├── smith_2024_pp1-4.pdf
+    ├── smith_2024_pp5-8.pdf
+    ├── smith_2024_pp9-12.pdf
+    └── ...
+```
+
+**Directory convention (ad-hoc / outside project):**
+```
+to-sort/downloads/
+├── smith_2024.pdf                    # original PDF — NEVER DELETE THIS
+└── split_smith_2024/                 # split subdirectory
+    └── ...
+```
+
+The original PDF remains in the download directory permanently. The splits are working copies. If anything goes wrong, you can always re-split from the original.
+
+If PyPDF2 is not installed, install it: `uv pip install PyPDF2`
+
+## Step 3: Read in Batches of 3 Splits
+
+Read **exactly 3 split files at a time** (~12 pages). After each batch:
+
+1. **Read** the 3 split PDFs using the Read tool
+2. **Update** the running notes file (`notes.md` in the split subdirectory)
+3. **Pause** and tell the user:
+
+> "I have finished reading splits [X-Y] and updated the notes. I have [N] more splits remaining. Would you like me to continue with the next 3?"
+
+4. **Wait** for the user to confirm before reading the next batch
+
+Do NOT read ahead. Do NOT read all splits at once. The pause-and-confirm protocol is mandatory.
+
+## Step 4: Structured Extraction
+
+As you read, collect information along these dimensions and write them into `notes.md`:
+
+1. **Research question** — What is the paper asking and why does it matter?
+2. **Audience** — Which sub-community of researchers cares about this?
+3. **Method** — How do they answer the question? What is the identification strategy?
+4. **Data** — What data do they use? Where precisely did they find it? What is the unit of observation? Sample size? Time period?
+5. **Statistical methods** — What econometric or statistical techniques do they use? What are the key specifications?
+6. **Findings** — What are the main results? Key coefficient estimates and standard errors?
+7. **Contributions** — What is learned from this exercise that we didn't know before?
+8. **Replication feasibility** — Is the data publicly available? Is there a replication archive? A data appendix? URLs for the underlying data?
+
+These questions extract what a researcher needs to **build on or replicate** the work — a structured extraction more detailed and specific than a typical summary.
+
+## The Notes File
+
+The output is `notes.md` in the split subdirectory:
+
+```
+articles/split_smith_2024/notes.md
+```
+
+This file is **updated incrementally** after each batch. Structure it with clear headers for each of the 8 dimensions. After each batch, update whichever dimensions have new information — do not rewrite from scratch.
+
+By the time all splits are read, the notes should contain specific data sources, variable names, equation references, sample sizes, coefficient estimates, and standard errors. Not a summary — a structured extraction.
+
+## Structured Mode (GROBID)
+
+If the paper is a **Zotero item** (user provides a key), try GROBID-powered extraction before splitting:
+
+1. Call `mcp__refpile__parse_pdf_metadata(key=KEY)` — get title, authors, abstract, affiliations
+2. Call `mcp__refpile__parse_pdf_fulltext(key=KEY)` — get sections with headings and paragraphs
+
+If GROBID succeeds, you get **semantically structured sections** (Introduction, Methods, Results, etc.) instead of arbitrary 4-page chunks. This is better for reading notes because:
+- Sections don't split mid-paragraph
+- Headings give natural structure for `notes.md`
+- Figures and tables are identified with captions
+
+**Use structured mode when:** the paper is in Zotero and GROBID returns sections. Still write to `notes.md` with the same 8-dimension extraction.
+
+**Fall back to page splits when:** GROBID is unavailable, returns an error, or the paper isn't in Zotero (local PDF only). The 4-page split workflow remains the default for local-only PDFs.
+
+## When NOT to Split
+
+- Papers shorter than ~15 pages: read directly (still use the Read tool, not Bash)
+- Policy briefs or non-technical documents: a rough summary is fine
+- Triage only: read just the first split (pages 1-4) for abstract and introduction
+
+## Quick Reference
+
+| Step | Action |
+|------|--------|
+| **Acquire** | Download to `./articles/` (in-project) or `to-sort/downloads/` (ad-hoc) |
+| **Split** | 4-page chunks into `./articles/split_<name>/` |
+| **Read** | 3 splits at a time, pause after each batch |
+| **Write** | Update `notes.md` with structured extraction |
+| **Confirm** | Ask user before continuing to next batch |
+
+For detailed explanation of why this method works, see [methodology.md](methodology.md).

package/skills/split-pdf/methodology.md

@@ -0,0 +1,48 @@
+# Why PDF Splitting Works: The Methodology
+
+This document explains the reasoning behind the split-pdf skill. It is reference material for humans — the SKILL.md file contains the actual instructions Claude follows.
+
+---
+
+## The Problem
+
+Claude Code (currently Claude Opus 4.5, model ID `claude-opus-4-5-20251101`) can read PDFs, and it has a very large context window (200k tokens in). In principle, a 40-page academic paper should fit comfortably. In practice, it doesn't work well. Claude Code regularly chokes when asked to read long PDFs, and this manifests in two distinct ways:
+
+**Problem 1: Session-breaking "prompt too long" errors.** PDF rendering into tokens is expensive. PDFs are not plain text — they are containers for fonts, vector graphics, embedded images, multi-column layouts, mathematical notation, tables, and footnotes. When Claude Code ingests a PDF, it must convert this complex layout into a linear token stream. A long PDF can produce a token sequence that, combined with the rest of the conversation context, exceeds the model's input limit. When this happens, Claude Code returns a "prompt too long" error. There is no way to recover — the session is broken, and all context is lost unless it has been externalized to files.
+
+**Problem 2: Shallow, unreliable reading.** Even when the PDF does not trigger a hard failure, comprehension degrades badly for long documents. The model's attention over many tokens from a single dense document is not uniform — it attends more carefully to the beginning and end, and less carefully to the middle. The result is that Claude "skims" rather than "reads." It catches the abstract and introduction, gets fuzzy on the methodology, and often misses or fabricates details from the results and appendix. It truncates content silently, hallucinates details it didn't actually parse, or produces shallow summaries that miss critical methodological details.
+
+These are related but distinct problems. The first is a hard constraint — the session dies. The second is a soft degradation — the session continues but the output is unreliable. Splitting addresses both.
+
+## Why Batched Reading Works
+
+Reading 3 splits at a time (~12 pages) does several things:
+
+1. **Forces the model to focus.** With only 12 pages of content, Claude cannot skim. It has to engage with the material at a granular level — the specific equations, the exact data sources, the precise variable definitions.
+
+2. **Creates natural checkpoints.** After each batch, the model writes down what it has learned so far. This means its understanding is externalized into a markdown file. If it makes an error in batch 1, you can catch it before batch 2 builds on it.
+
+3. **Accumulates rather than summarizes.** When you ask Claude to read a full paper at once, it produces a summary — a lossy compression. When you ask it to read in batches and update running notes, it accumulates detail. The final notes are richer than any one-shot summary could be.
+
+4. **Controls for the "front-loading" problem.** Claude's attention is not uniform over a long document. It attends more carefully to the beginning and end. By splitting the paper, every section gets to be "the beginning" of some chunk.
+
+## Why 4-Page Chunks
+
+Four pages is a sweet spot:
+- Small enough that Claude attends carefully to every detail
+- Large enough that logical sections (a methodology subsection, a results table with discussion) stay together
+- Produces a manageable number of chunks (a 40-page paper = 10 chunks = 4 rounds of reading)
+
+## Why the Pause-and-Confirm Protocol
+
+The human pause between batches serves multiple purposes:
+- **Review intermediate output** — catch errors before they compound
+- **Redirect the reading** — ask follow-up questions, skip sections, or change focus
+- **Prevent context drift** — Claude doesn't lose track of where it is in a long session
+- **Control pacing** — some papers require more careful reading in specific sections
+
+## Limitations
+
+- **It is slow.** A 37-page paper split into 10 chunks, read 3 at a time, requires 4 rounds. Each round involves the user confirming "yes, continue." This is a 10-15 minute process rather than a 1-minute process.
+- **Notes can become repetitive** if the paper revisits themes. Some manual editing of the final notes may be useful.
+- **Assumes the paper is worth reading carefully.** For triage — quickly deciding whether a paper is relevant — reading just the first split (pages 1-4, which usually contains the abstract and introduction) is sufficient.

package/skills/sync-notion/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: sync-notion
+description: "Use when you need to sync the current project's state to the context library and Notion."
+allowed-tools: Read, Edit, Write, Glob, Grep, Bash(ls*), mcp__claude_ai_Notion__notion-search, mcp__claude_ai_Notion__notion-update-page, mcp__claude_ai_Notion__notion-fetch
+argument-hint: [optional: summary of what changed]
+---
+
+# Update Notion Skill
+
+> Sync the current project's state to the central task management context library and Notion Research Pipeline.
+
+## Purpose
+
+After working on a research project, this skill propagates the current state outward:
+- **Project CLAUDE.md** (source of truth) → **`.context/projects/_index.md`** (central registry)
+- **Recent session logs** → **`.context/current-focus.md`** (working memory)
+- **Project metadata** → **Notion Research Pipeline** (tracking database)
+
+This keeps all systems in sync without manual updates.
+
+## When to Use
+
+- At the end of a work session (often paired with `/session-log`)
+- After changing a project's target journal, status, or stage
+- When the user says "update project doc", "sync project", "update my project index"
+
+## MCP Pre-Check
+
+Before starting, probe Notion MCP availability with a lightweight search. If unavailable, skip Steps 3 and 5 and offer fallbacks per [`shared/mcp-degradation.md`](../shared/mcp-degradation.md).
+
+## Workflow
+
+### Step 1: Read the current project's CLAUDE.md
+
+Extract key metadata:
+- **Project name** (from header)
+- **Target journal** (from `Target:` field)
+- **Stage** (infer from content: Idea / Literature Review / Drafting / Data Collection / Analysis / Submitted / R&R / Published)
+- **Co-authors** (if listed)
+- **Working title**
+- **Key next steps** (from Research Design or recent session log)
+
+### Step 2: Read the most recent session log
+
+Look in the project's `log/` directory for the latest `YYYY-MM-DD-HHMM.md` file. Extract:
+- What was accomplished
+- Current blockers
+- Next steps
+
+### Step 3: Update `.context/projects/_index.md`
+
+Location: `$TM/.context/projects/_index.md`
+
+Find the project's row in the "Papers in Progress" table. If it exists, update the Stage, Target Journal, and Status columns. If it doesn't exist, add a new row.
+
+**Table format:**
+```
+| Project | Stage | Co-authors | Target Journal | Status |
+```
+
+### Step 4: Update `.context/current-focus.md`
+
+Location: `$TM/.context/current-focus.md`
+
+Update the "Recent Context" section with a brief summary of the latest session. Add any new open loops.
+
+> **Note:** For full session-level updates (session rotation, open loop management, mental state), defer to `/update-focus`. This skill adds a brief summary only.
+
+### Step 5: Update Notion Research Pipeline
+
+Search the Research Pipeline database (`collection://YOUR-PIPELINE-DATABASE-ID-HERE`) for the project name. If found, update:
+- **Status** (match to: Idea, Literature Review, Drafting, Submitted, R&R, Published)
+- **Target Journal**
+- **Priority** (if changed)
+
+If not found, inform the user (don't auto-create — they may want to set properties manually).
+
+### Step 6: Confirm
+
+Report what was updated:
+```
+Updated project docs for [Project Name]:
+- .context/projects/_index.md: [what changed]
+- .context/current-focus.md: [what changed]
+- Notion Research Pipeline: [what changed, or "no entry found"]
+```
+
+## Important Notes
+
+- This skill **reads** the project CLAUDE.md and session logs — it never modifies them.
+- It **writes** to the central context files and Notion only.
+- Always read before writing to preserve existing content.
+- If the user provides a summary argument, use that instead of inferring from logs.