I built a local-first tool for turning research material into a maintained markdown wiki.
The idea is simple: instead of repeatedly querying raw notes or documents, sources get ingested into a structured wiki with source pages, concept pages, entity pages, and synthesis pages. Then questions are asked against that wiki, and useful answers get written back as new pages.
Everything stays file-based and Obsidian-friendly. There’s also a local dashboard and a macOS menubar app so it can keep running in the background.
I was trying to build something that feels more cumulative than chat, but much lighter than setting up a full RAG stack.
The original inspiration was Andrej Karpathy’s “LLM Wiki” idea. I also took some UI/product inspiration from wiki-os.
Curious if other people here have found wiki-first or markdown-first workflows more useful than pure retrieval for personal research and project memory.
Nice trick for making OpenAPI changes much easier to review in Git.
Instead of reading raw YAML/JSON diffs, you can plug `oasdiff changelog` in as a custom `git diff` driver so `git diff` shows a human‑readable summary of API changes (added/removed endpoints, changed fields, etc).
The setup is:
- a small wrapper script that detects added/removed files and otherwise calls `oasdiff changelog old new --color always`
- a `.gitattributes` entry pointing a specific OpenAPI file to a custom `diff=oasdiff` driver
- a `[diff "oasdiff"]` section in `.git/config` pointing to the wrapper script path
One gotcha: because this uses an external diff driver, you need `git log --patch --ext-diff` to see it in logs, and the filenames you see in the output are Git’s temp paths. There’s also a plan to propose a first‑class diff‑driver option upstream in `oasdiff` to make this smoother.
This is a broader pattern I keep seeing with agent plugins/extensions — the permission model is "all or nothing." Once you install a plugin, it gets full context on every session, every prompt.
Compare this to how we think about OAuth scopes or container sandboxing — you'd never ship a CI integration that gets read access to every repo in your org just because it needs to lint one. But that's essentially what's happening here with the token injection across all sessions.
The real problem isn't Vercel specifically, it's that Claude Code's plugin architecture doesn't have granular activation scopes yet. Plugins should declare which project types they apply to and only activate in matching contexts. Until that exists, every plugin author is going to make this same mistake — or exploit it.