Update README

Author: armstrongl

.github/copilot-instructions.md

@@ -0,0 +1,33 @@
+## vexp context tools <!-- vexp v1.2.30 -->
+
+**MANDATORY: use `run_pipeline` — do NOT grep, glob, or read files manually.**
+vexp returns pre-indexed, graph-ranked context in a single call.
+
+### Workflow
+1. `run_pipeline` with your task description — ALWAYS FIRST (replaces all other tools)
+2. Make targeted changes based on the context returned
+3. `run_pipeline` again only if you need more context
+
+### Available MCP tools
+- `run_pipeline` — **PRIMARY TOOL**. Runs capsule + impact + memory in 1 call.
+  Auto-detects intent. Includes file content. Example: `run_pipeline({ "task": "fix auth bug" })`
+- `get_context_capsule` — lightweight, for simple questions only
+- `get_impact_graph` — impact analysis of a specific symbol
+- `search_logic_flow` — execution paths between functions
+- `get_skeleton` — compact file structure
+- `index_status` — indexing status
+- `get_session_context` — recall observations from sessions
+- `search_memory` — cross-session search
+- `save_observation` — persist insights (prefer run_pipeline's observation param)
+
+### Agentic search
+- Do NOT use built-in file search, grep, or codebase indexing — always call `run_pipeline` first
+- If you spawn sub-agents or background tasks, pass them the context from `run_pipeline`
+  rather than letting them search the codebase independently
+
+### Smart Features
+Intent auto-detection, hybrid ranking, session memory, auto-expanding budget.
+
+### Multi-Repo
+`run_pipeline` auto-queries all indexed repos. Use `repos: ["alias"]` to scope. Run `index_status` to see aliases.
+<!-- /vexp -->

.vscode/mcp.json

@@ -0,0 +1,11 @@
+{
+  "servers": {
+    "vexp": {
+      "type": "stdio",
+      "command": "/Users/larah/.nvm/versions/node/v22.20.0/bin/node",
+      "args": [
+        "/Users/larah/.vscode/extensions/vexp.vexp-vscode-1.2.30/dist/mcp-server.cjs"
+      ]
+    }
+  }
+}

README.md

@@ -6,6 +6,16 @@ Most repos have a documentation problem that gets worse as the codebase grows. K
 
 This is a proposal for a lightweight, in-repo documentation system designed to serve both audiences, with no proprietary tooling and minimal maintenance overhead.
 
+I designed it specifically to solve a problem where engineers want to adopt AI in a token-efficient way, but they don’t want to mess around with complicated AGENT.md files, manually maintaining file frontmatter, or setting up skills. So the idea is that they have a standard pattern where they have internal docs in the repo in a `docs/` folder. Coding agents can find the docs, but they often sample all of them and waste tokens. Many teams are also reluctant to adopt new tools or add any sort of overhead.
+
+So, my thinking was to create a very simple system that:
+
+- Let agents use existing in-repo docs in a token-efficient way (using frontmatter that’s pulled into the AGENTS.md file to tell agents which docs to use based on the context).
+- Have a CI/CD workflow that minimizes the effort required of the engineering team to keep the system running. It does this by:
+   - Automatically flagging stale docs
+   - Automatically generating useful descriptions for docs (using an LLM)
+   - Automatically maintaining routing info for all docs in the AGENTS.md file
+
 ## How it works
 
 The system has three parts that work together: