flonat-research 0.1.0

package/skills/context-status/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: context-status
+description: "Use when you need to check current context status and session health."
+allowed_tools:
+  - Read
+  - Glob
+  - Bash(ls*, cat*)
+---
+
+# Context Status: Session Health Check
+
+On-demand diagnostic showing context usage, preservation state, and open work items. Fast and lightweight — no vault queries.
+
+## What to Check
+
+### 1. Context Usage Estimate
+
+Read the context monitor state file to get the current tool call count:
+
+```
+~/.claude/sessions/{project-hash}/context-monitor-state.json
+```
+
+The project hash is a SHA-256 of `CLAUDE_PROJECT_DIR` (first 12 chars). If the state file doesn't exist, report "No context monitor data — hook may not be active."
+
+Calculate:
+- Tool calls so far
+- Estimated percentage (calls / 150)
+- Which thresholds have fired (from the `fired` array)
+- Time since last warning
+
+### 2. Active Plan
+
+Find the latest file in `log/plans/`:
+- If found: show filename, first 3 lines, and whether it contains "APPROVED" or is still "DRAFT"
+- If none: report "No active plan"
+
+### 3. Latest Session Log
+
+Find the latest non-compact `.md` file in `log/` (skip files with `-compact` in the name):
+- If found: show filename and first 3 lines
+- If none: report "No session log found"
+
+### 4. Focus Freshness
+
+Check when `.context/current-focus.md` was last modified:
+- Show the modification date
+- If older than 3 days: warn "Focus file is stale — consider running `/update-focus`"
+- Show the first 5 lines (headline)
+
+### 5. Preservation Hooks
+
+Verify these hooks are configured in `~/.claude/settings.json`:
+- `PreCompact` → `precompact-autosave.py` (pre-compact state save)
+- `SessionStart` compact → `postcompact-restore.py` (post-compact restore)
+- `PostToolUse` → `context-monitor.py` (this monitor)
+
+For each: report CONFIGURED or MISSING.
+
+### 6. Open Loops
+
+Count unchecked items (`- [ ]`) in `.context/current-focus.md`:
+- Report the count
+- If > 5: warn "Many open loops — consider triaging"
+
+## Output Format
+
+Present as a compact status panel:
+
+```
+## Session Health
+
+| Metric | Value |
+|--------|-------|
+| Context usage | ~XX% (N/150 tool calls) |
+| Thresholds fired | none / info / warning / critical |
+| Active plan | filename (DRAFT/APPROVED) / none |
+| Latest log | filename / none |
+| Focus freshness | N days ago / stale warning |
+| Open loops | N items |
+
+### Preservation Hooks
+
+| Hook | Status |
+|------|--------|
+| PreCompact auto-save | CONFIGURED / MISSING |
+| Post-compact restore | CONFIGURED / MISSING |
+| Context monitor | CONFIGURED / MISSING |
+
+### Recommendations
+
+[Only if there are issues — e.g., stale focus, missing hooks, high context usage]
+```
+
+### 7. Compaction Guidance
+
+When context is high (>60%), include these reference tables in the output:
+
+**When to compact:**
+
+| Phase Transition | Compact? | Why |
+|---|---|---|
+| Research to Planning | Yes | Research context is bulky; plan is the distilled output |
+| Planning to Implementation | Yes | Plan is in a file; free up context for code |
+| Implementation to Testing | Maybe | Keep if tests reference recent code |
+| Debugging to Next feature | Yes | Debug traces pollute context |
+| Mid-implementation | No | Losing file paths and partial state is costly |
+| After a failed approach | Yes | Clear dead-end reasoning |
+
+**What survives compaction:**
+
+| Persists | Lost |
+|---|---|
+| CLAUDE.md + rules | Intermediate reasoning |
+| Task list | File contents previously read |
+| MEMORY.md | Multi-step conversation context |
+| Git state | Tool call history |
+| Files on disk | Verbal preferences |
+| precompact-autosave state | — |
+
+## When to Use
+
+- When the context monitor fires a warning
+- Before starting a large task (to check remaining capacity)
+- After resuming a session (to verify state was preserved)
+- When unsure if preservation hooks are working

package/skills/creation-guard/SKILL.md

@@ -0,0 +1,230 @@
+---
+name: creation-guard
+description: "Use when you need a pre-flight duplicate check before creating new skills or agents."
+allowed_tools:
+  - Read
+  - Glob
+  - Grep
+  - AskUserQuestion
+---
+
+# Creation Guard: Pre-Flight Duplicate Check
+
+Prevent duplicate functionality by analysing existing skills and agents before creating new ones. Intercepts creation intent, searches for overlap, and recommends one of 5 actions.
+
+## When to Use
+
+Invoke **before** creating ANY new:
+- Skill (`skills/*/SKILL.md`)
+- Agent (`.claude/agents/*.md`)
+
+Trigger phrases:
+- "Create a skill for..."
+- "I want a new skill that..."
+- "Let's add an agent for..."
+- Any intent to create new automation/tooling
+
+## Process
+
+### Step 1: Identify the Proposal
+
+Extract from the request:
+- **Name**: Proposed name (kebab-case)
+- **Type**: skill | agent
+- **Purpose**: What it does (one sentence)
+- **Key Functions**: 3-5 main capabilities
+- **Keywords**: Searchable terms related to functionality
+
+### Step 2: Search Existing Artifacts
+
+Run these searches in parallel:
+
+1. **Read [`skills/shared/skill-index.md`](../shared/skill-index.md)** — scan the categorised table for potential duplicates by name and purpose
+2. **Keyword search** — grep skills and agents for each keyword:
+
+```
+Grep for each keyword across:
+  - skills/*/SKILL.md (frontmatter + body)
+  - .claude/agents/*.md (frontmatter + body)
+```
+
+3. **Agent scan** — read frontmatter of each agent to check purpose overlap:
+
+```
+Glob: .claude/agents/*.md
+Read first 20 lines of each match
+```
+
+### Step 3: Analyse Overlap
+
+For each potentially related artifact, assess:
+
+| Criterion | Question |
+|-----------|----------|
+| Functional overlap | Does it do the same thing? (0-100%) |
+| Naming confusion | Could names be confused? |
+| Extension potential | Could the proposal extend this instead? |
+| Composition | Could existing artifacts compose to achieve this? |
+
+### Step 4: Generate Recommendation
+
+Based on analysis, recommend ONE of:
+
+| Recommendation | Criteria | Action |
+|----------------|----------|--------|
+| **PROCEED** | <20% overlap, genuinely new capability | Create new artifact |
+| **EXTEND** | 50%+ overlap with single existing artifact | Modify existing instead |
+| **COMPOSE** | Multiple artifacts cover 80%+ combined | Create thin wrapper or document workflow |
+| **ITERATE** | 20-50% overlap, proposal needs refinement | Refine proposal to differentiate |
+| **BLOCK** | Would create problematic duplication | Do not create |
+
+### Step 5: Present and Confirm
+
+Display the analysis and wait for explicit user approval before proceeding.
+
+## Output Format
+
+```
+════════════════════════════════════════════════════════════════
+CREATION GUARD ANALYSIS
+════════════════════════════════════════════════════════════════
+
+PROPOSAL:
+  Type: [skill|agent]
+  Name: [proposed-name]
+  Purpose: [one sentence]
+
+EXISTING ARTIFACTS ANALYSED: [count]
+
+RELATED ARTIFACTS FOUND:
+
+1. [artifact-name] ([type])
+   Purpose: [what it does]
+   Overlap: [X]% - [explanation]
+
+2. [artifact-name] ([type])
+   Purpose: [what it does]
+   Overlap: [X]% - [explanation]
+
+RECOMMENDATION: [PROCEED|EXTEND|COMPOSE|ITERATE|BLOCK]
+
+RATIONALE:
+[2-3 sentences explaining the recommendation]
+
+SUGGESTED ACTION:
+[Specific next step based on recommendation]
+
+════════════════════════════════════════════════════════════════
+```
+
+## Recommendation Details
+
+### PROCEED
+- Artifact is genuinely new
+- No significant overlap found
+- Clear differentiation from existing tools
+- Go ahead and create
+
+### EXTEND
+Present extension proposal:
+```
+Instead of creating [new-name], extend [existing-name]:
+
+Current capabilities:
+- [existing feature 1]
+- [existing feature 2]
+
+Proposed additions:
+- [new feature 1]
+- [new feature 2]
+```
+
+### COMPOSE
+Present composition approach:
+```
+The proposed functionality can be achieved by combining:
+
+1. [artifact-1] — handles [aspect]
+2. [artifact-2] — handles [aspect]
+
+Options:
+A) Document this workflow (no new code)
+B) Create thin orchestration skill
+C) Add to existing skill's integration section
+```
+
+### ITERATE
+Present refinement questions:
+```
+Overlap detected with [existing-artifact].
+
+Differentiation needed:
+1. [question about scope]
+2. [question about use case]
+3. [question about implementation]
+
+Please clarify to proceed.
+```
+
+### BLOCK
+Explain why creation should not proceed:
+```
+BLOCKED: Would create problematic duplication.
+
+Existing artifact: [name]
+- Already does: [capabilities]
+- Your request: [same capabilities]
+
+Alternatives:
+1. Use existing: /[skill-name]
+2. If missing features, extend the existing artifact
+3. If different use case, explain how this differs
+```
+
+## Post-Match Action Table
+
+When overlap IS found, use this table to decide the specific action:
+
+| Situation | Action |
+|-----------|--------|
+| Nothing related found | Create new artifact |
+| Same trigger + same fix as existing | Update existing (bump version, improve docs) |
+| Same trigger, different root cause | Create new + add cross-links in both |
+| Partial overlap (same domain, different trigger) | Add variant subsection to existing |
+| Same domain, different problem | Create new + add "See also" references |
+| Existing is stale or wrong | Mark deprecated + create replacement |
+
+This complements the PROCEED/EXTEND/COMPOSE/ITERATE/BLOCK recommendation above. The recommendation decides *whether* to create; this table decides *how* to handle the relationship with existing artifacts.
+
+## Self-Check Questions
+
+Before creating ANY new artifact, ask:
+
+1. Does something similar already exist?
+2. Could this be added to an existing artifact?
+3. Would a user know to look for this vs the existing one?
+4. Am I creating this because it's needed or because it's easier than finding what exists?
+
+## Naming Convention Enforcement
+
+When creating a new skill, **always** name the definition file `SKILL.md` (uppercase). Never `skill.md`, `Skill.md`, or any other casing.
+
+- The MCP server's skill discovery scans for `SKILL.md` explicitly
+- Documentation generators and `/system-audit` use `find -name 'SKILL.md'`
+- On case-insensitive filesystems (macOS APFS), lowercase files appear to work locally but fail in case-sensitive contexts (Linux CI, Docker, MCP server pattern matching)
+
+**Check before writing:** If the target directory already contains a `skill.md` (lowercase), rename it to `SKILL.md` first.
+
+## Anti-Patterns
+
+| Anti-Pattern | Problem | Instead |
+|--------------|---------|---------|
+| Skip the check | "It's obviously new" — famous last words | Always run the analysis |
+| Name-only matching | Names differ but functions overlap | Search by purpose and keywords |
+| Create then merge | Merge debt accumulates fast | Check first, create once |
+| Over-splitting | Two skills that always run together | Consider a single skill with phases |
+| Lowercase `skill.md` | Invisible to MCP server, audit tools, and case-sensitive systems | Always use `SKILL.md` (uppercase) |
+
+## Integration
+
+This skill is invoked by `/learn` in Phase 2 to replace the old subset/partial/no-overlap check. When called from `/learn`, return the recommendation label (PROCEED/EXTEND/COMPOSE/ITERATE/BLOCK) so `/learn` can branch accordingly.

package/skills/devils-advocate/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: devils-advocate
+description: "Use when you need to challenge research assumptions or stress-test arguments."
+argument-hint: [paper-or-argument-description]
+---
+
+# Devil's Advocate Skill
+
+> Challenge research assumptions and identify weaknesses in your arguments.
+
+## Purpose
+
+Based on Scott Cunningham's Part 3: "Creating Devil's Advocate Agents for Tough Problems" - addressing the "LLM thing of over-confidence in diagnosing a problem."
+
+**For formal code audits with replication scripts and referee reports, use the Referee 2 agent instead (`.claude/agents/referee2-reviewer.md`).** This skill is for quick adversarial feedback on arguments, not systematic audits.
+
+## When to Use
+
+- Before submitting a paper
+- When stuck on a research problem
+- When you want to stress-test an argument
+- During paper revision planning
+
+## When NOT to Use
+
+- **Code audits** — use the Referee 2 agent instead
+- **Replication verification** — use the Referee 2 agent instead
+- **Quick proofreading** — just ask for a read-through
+- **When you want validation** — this skill is designed to challenge, not affirm
+
+## Workflow
+
+1. **Understand the claim** — Read the paper/argument being evaluated
+2. **Generate competing hypotheses** — If evaluating a research question or design, load `references/competing-hypotheses.md` and generate 3-5 rival explanations before critiquing
+3. **Run the debate** — Use the multi-turn debate protocol below (default) or single-shot mode for quick checks
+4. **Deliver the verdict** — Synthesize surviving critiques with severity ratings
+
+## Multi-Turn Debate Protocol (Default)
+
+Inspired by the simulated scientific debates in Google's AI Co-Scientist. A one-shot critique is easy for an LLM to produce but often superficial. Multi-turn debates force each critique to survive a defense, filtering out weak objections and sharpening the strong ones.
+
+### Round 1: Adversarial Critic
+
+Adopt the persona of a hostile but competent reviewer. Challenge on:
+1. **Theoretical foundations** — Are the assumptions justified?
+2. **Methodology** — Limitations? Alternative approaches?
+3. **Data** — Selection bias? Measurement issues? External validity?
+4. **Causal claims** — Alternative explanations? Confounders?
+5. **Contribution** — Novel enough? Does it matter?
+
+Produce **numbered critiques** (aim for 5-8), each with a concrete statement of the problem.
+
+### Round 2: Defense
+
+Switch persona to the paper's author. For each numbered critique, provide the strongest possible defense:
+- Cite evidence from the paper that addresses the concern
+- Explain design choices that mitigate the issue
+- Acknowledge limitations honestly where the defense is weak
+- Propose concrete fixes where the critique has merit
+
+### Round 3: Adjudication
+
+Switch to an impartial senior reviewer. For each critique-defense pair, rule:
+- **Critique stands** — the defense is insufficient; this is a real weakness
+- **Critique partially addressed** — defense has merit but issue remains
+- **Critique resolved** — the defense adequately addresses the concern
+
+### Final Synthesis
+
+Produce a structured report with only the surviving critiques (stands + partially addressed), ranked by severity:
+
+```markdown
+## Devil's Advocate Report
+
+### Critical (must fix before submission)
+1. [Critique] — [Why the defense failed] — [Suggested fix]
+
+### Major (reviewers will likely raise)
+2. [Critique] — [What remains after defense] — [Suggested fix]
+
+### Minor (worth acknowledging)
+3. [Critique] — [Residual concern] — [How to preempt]
+
+### Dismissed
+- [Critiques that were resolved in Round 2, listed briefly for transparency]
+```
+
+## Single-Shot Mode
+
+For quick checks (e.g., "just poke holes in this argument"), skip the multi-turn protocol and produce a direct critique. Use when the user says "quick", "just challenge this", or the input is a paragraph rather than a full paper.
+
+## Example Use
+
+"Play devil's advocate on my research paper about preference drift - specifically challenge my identification strategy and the assumptions about utility functions."
+
+---
+
+## Council Mode (Optional)
+
+For the highest-stakes arguments, run the devil's advocate debate across multiple LLM providers. Different models have genuinely different reasoning patterns — a critique that Claude finds weak, GPT may find devastating, and vice versa. This produces adversarial tension that a single model cannot replicate internally.
+
+**Trigger:** "Council devil's advocate" or "thorough challenge"
+
+**How it works:**
+1. Each model independently plays Adversarial Critic (Round 1) using the same paper/argument
+2. Cross-review: each model evaluates the others' critiques — identifying which challenges are strongest
+3. Chairman synthesis: produces a single report with surviving critiques ranked by cross-model agreement
+
+**Invocation (CLI backend):**
+```bash
+cd packages/cli-council
+uv run python -m cli_council \
+    --prompt-file /tmp/devils-advocate-prompt.txt \
+    --context-file /tmp/paper-content.txt \
+    --output-md /tmp/devils-advocate-council.md \
+    --chairman claude \
+    --timeout 180
+```
+
+See `skills/shared/council-protocol.md` for the full orchestration protocol.
+
+**Value:** High — the multi-turn debate protocol (Round 1→2→3) becomes genuinely adversarial when different models play different roles. A critique that survives cross-model scrutiny is almost certainly a real weakness.
+
+## Cross-References
+
+| Skill | When to use instead/alongside |
+|-------|-------------------------------|
+| `/interview-me` | To develop the idea further through structured interview |
+| `/multi-perspective` | For multi-perspective analysis with disciplinary diversity |
+| `/proofread` | For language/formatting review rather than argument critique |

package/skills/devils-advocate/references/competing-hypotheses.md

@@ -0,0 +1,83 @@
+# Competing Hypotheses Checklist
+
+Structured process for generating and evaluating rival explanations before locking a research design. Complements the `design-before-results` rule (`.claude/rules/design-before-results.md`) by specifying HOW to formulate competing explanations, not just that you should. Adapted from K-Dense's hypothesis-generation skill and quality criteria framework.
+
+## When to Use
+
+- Before locking a research design (pre-registration, analysis plan)
+- When `/devils-advocate` is invoked on a research question
+- During early-stage paper planning (idea -> literature review transition)
+- When reviewing a paper that presents only one explanation
+
+## The 3-Step Process
+
+### Step 1: Generate 3-5 Competing Hypotheses
+
+Each hypothesis must provide a **mechanistic explanation** -- specify HOW and WHY the effect occurs, not just WHAT happens.
+
+**Requirements:**
+- Each must be distinguishable from the others (different mechanisms, not different magnitudes)
+- Include at least one "null" or status-quo explanation (e.g., "observed pattern is an artefact of selection")
+
+**Generation strategies:**
+- Apply known mechanisms from analogous settings (e.g., anchoring from behavioural econ to MCDM)
+- Consider different levels of explanation: individual (cognitive) -> group (social) -> market (structural) -> institutional (regulatory)
+- Question existing assumptions: what if the causal direction is reversed? What if it is confounded?
+- Combine mechanisms in novel ways (e.g., bounded rationality + social conformity)
+
+### Step 2: Evaluate Against 7 Quality Criteria
+
+| Criterion | Definition | H1 | H2 | H3 | H4 | H5 |
+|-----------|-----------|----|----|----|----|-----|
+| **Testability** | Can it be empirically tested with available methods? | | | | | |
+| **Falsifiability** | What specific observations would disprove it? | | | | | |
+| **Parsimony** | Is it the simplest explanation consistent with evidence? | | | | | |
+| **Explanatory power** | How much of the phenomenon does it account for? | | | | | |
+| **Scope** | Does it generalise beyond the specific case? | | | | | |
+| **Consistency** | Does it align with established theory and evidence? | | | | | |
+| **Novelty** | Does it offer new insight beyond existing accounts? | | | | | |
+
+Rate each cell as **Strong** / **Moderate** / **Weak**.
+
+Hypotheses scoring Weak on Testability or Falsifiability should be revised or dropped.
+
+### Step 3: Design Distinguishing Tests
+
+- For each pair of hypotheses (H_i, H_j), identify at least one prediction where they diverge
+- Prioritise predictions that are most feasible to test (data availability, ethical constraints, cost)
+- Identify "critical experiments" that eliminate the most hypotheses simultaneously
+- Format: "If H1 is correct but H2 is not, we should observe X but not Y"
+
+## Common Pitfalls
+
+- **Just-so stories:** plausible narrative without testable predictions -- if you cannot specify what would falsify it, it is not a hypothesis
+- **Unfalsifiable claims:** built-in escape clauses ("it depends on context", "moderating factors may apply")
+- **Single-hypothesis lock-in:** committing to one explanation before considering alternatives, then seeking only confirmatory evidence
+- **Over-complexity:** invoking unnecessary mechanisms when a simpler account suffices (violates parsimony)
+
+## Worked Example
+
+**Research question:** Why do decision-makers deviate from optimal stopping rules in sequential search (e.g., hiring, investment screening)?
+
+**Competing hypotheses:**
+
+- **H1 (Cognitive load):** Tracking running optima exceeds working-memory capacity; DMs fall back on satisficing heuristics. Mechanism: individual-level cognitive constraint.
+- **H2 (Social accountability):** DMs stop early to justify choices to stakeholders ("I chose the best I saw") rather than risk continued search with uncertain payoff. Mechanism: group-level social pressure.
+- **H3 (Null -- rational adaptation):** Deviations reflect rational updating given non-stationary option quality or unknown distributions; no bias is present. Mechanism: Bayesian learning under uncertainty.
+
+| Criterion | H1 | H2 | H3 |
+|-----------|-----|-----|-----|
+| Testability | Strong | Strong | Moderate |
+| Falsifiability | Strong | Strong | Weak |
+| Parsimony | Strong | Moderate | Strong |
+| Explanatory power | Moderate | Moderate | Moderate |
+| Scope | Strong | Moderate | Strong |
+| Consistency | Strong | Strong | Strong |
+| Novelty | Weak | Moderate | Weak |
+
+**Distinguishing predictions:**
+
+- **H1 vs H2:** Manipulate accountability (solo vs committee decision). If H1 dominates, deviation rates are unchanged; if H2, deviations decrease when accountability is removed.
+- **H1 vs H3:** Vary cognitive load (dual-task paradigm). If H1, higher load increases deviation; if H3, load is irrelevant.
+- **H2 vs H3:** Provide full distributional information. If H3, deviations disappear with known distributions; if H2, they persist because the social motive remains.
+- **Critical test:** Dual-task + no-accountability + known-distribution condition -- eliminates all three simultaneously.

package/skills/init-project/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: init-project
+description: "Bootstrap a new research project. Interview for details, scaffold directory structure, create Overleaf symlink, initialise git, and create project context files."
+allowed-tools: Bash(mkdir*), Bash(ln*), Bash(git*), Bash(ls*), Read, Write, Edit, Glob, Grep, AskUserQuestion
+argument-hint: (no arguments — starts an interview)
+---
+
+# Init Project — Research Project Scaffolder
+
+> Interactive project setup: answer questions, get a ready-to-use research project directory.
+
+## Protocol
+
+### Phase 1: Interview
+
+Ask the user these questions using `AskUserQuestion` (adapt based on what's already known):
+
+1. **Project name** — short name for the directory (e.g., `nudge-experiment`)
+2. **Paper title** — working title for the paper
+3. **Research question** — one sentence
+4. **Target journal/venue** — where you plan to submit
+5. **Co-authors** — names and affiliations (if any)
+6. **Parent directory** — where to create the project (default: `~/Research/`)
+7. **Overleaf path** — path to Overleaf-synced directory for symlink (optional)
+8. **Methodology** — experimental, observational, theoretical, simulation, mixed
+
+### Phase 2: Scaffold
+
+Create the directory structure:
+
+```
+<project-name>/
+├── CLAUDE.md               # Project-specific Claude instructions
+├── README.md               # Project overview
+├── MEMORY.md               # Knowledge base (seeded with template)
+├── paper/                  # → Overleaf symlink (or empty dir)
+├── code/
+│   ├── python/             # Python scripts
+│   └── R/                  # R scripts
+├── data/
+│   ├── raw/                # Original data (never modified)
+│   └── processed/          # Cleaned/transformed data
+├── results/                # Analysis outputs
+├── figures/                # Generated figures
+├── docs/                   # Project documentation
+├── correspondence/         # Referee reports, cover letters
+│   └── referee2/           # Referee 2 agent reports
+├── log/                    # Session logs
+│   └── plans/              # Saved plans
+└── .gitignore
+```
+
+### Phase 3: Populate Files
+
+**CLAUDE.md** — project-specific instructions:
+- Paper title and research question
+- Co-authors and target venue
+- Methodology and key conventions
+- Pointer to project context files
+
+**README.md** — human-readable overview:
+- Project title and description
+- Directory structure explanation
+- How to compile the paper
+- Co-author information
+
+**MEMORY.md** — seeded with research project template:
+- Notation Registry (empty)
+- Estimand Registry (empty)
+- Key Decisions (empty)
+- Citations (empty)
+- Anti-Patterns (empty)
+- Code Pitfalls (empty)
+
+**.gitignore** — standard research project ignores:
+- Build artifacts (`out/`, `*.aux`, `*.log`)
+- Data files (`data/raw/*.csv`, `data/raw/*.xlsx`)
+- Python/R artifacts (`__pycache__/`, `.Rhistory`)
+- OS files (`.DS_Store`)
+
+### Phase 4: Git & Symlinks
+
+1. **Overleaf symlink** — if a path was provided:
+   ```bash
+   ln -s /path/to/overleaf/dir paper
+   ```
+2. **Git init** — initialise the repository:
+   ```bash
+   git init
+   git add .
+   git commit -m "Initial project scaffold"
+   ```
+
+### Phase 5: Context Update
+
+Update the central context library:
+1. Add the project to `.context/projects/_index.md`
+2. Create `.context/projects/papers/<project-name>.md` with metadata
+
+## Output
+
+Print a summary of what was created:
+
+```
+Project created: ~/Research/<project-name>/
+  Directories: 12
+  Files: 4 (CLAUDE.md, README.md, MEMORY.md, .gitignore)
+  Overleaf: linked / not configured
+  Git: initialised with initial commit
+
+Next steps:
+  1. Start writing in paper/ (or link Overleaf)
+  2. Add code to code/python/ or code/R/
+  3. Run /session-log when you finish working
+```