A spoonful of source-traced code context. Living domain docs your coding agent keeps in sync with every commit.
codespoon keeps small, curated, source-traced domain documents next to
your code and lets your coding agent maintain them. When you commit, a local
daemon hands the change to your agent (OpenCode, Claude Code, …) which edits
the affected node files directly. Validation gates the result before it lands.
The idea: don't feed the whole repo to the model. Don't trust a stale wiki. Keep a small set of human-readable knowledge nodes that always cite the code they describe — and let the agent maintain them, file by file, as you work.
| Tool | What it gives the agent |
|---|---|
grep / ripgrep |
Exact string matches across a tree |
| Repomix | The whole repo packaged for one big LLM input |
| aider repomap | Compressed signatures of the whole repo |
| graphify / codegraph | A queryable knowledge graph of symbols & calls |
| codespoon | A few hand-picked domain docs that stay in sync with the code, written in markdown for humans to read |
codespoon sits in a different niche from "index everything" tools. It targets the gap between:
- Wiki / hand-written docs — useful but go stale in weeks
- Full-repo graphs / packers — comprehensive but undifferentiated
The pitch is curation + auto-maintenance: a small number of high-value domain narratives with verifiable provenance, kept fresh automatically.
your commit
↓ git post-commit hook
↓
codespoon daemon
↓ maps changed files → affected knowledge nodes
↓ invokes your agent CLI (opencode run …)
↓
agent edits the node file directly using its own write tool
↓ codespoon validates the file
↓ if valid: auto-commit "docs(codespoon): auto-update for <sha>"
↓ if not: restore original, save broken content to .codespoon/runs/
Each knowledge node is a markdown file with YAML frontmatter:
---
id: chat-session-flow
kind: domain
status: auto-updated
confidence: medium
scope:
include:
- apps/web/app/chat
sources:
- path: apps/web/src/services/chat/core/chat-service.ts
symbols: [ChatService, createSession]
relations:
- target: app-bridge
kind: related
confidence: extracted
last_updated_commit: abc1234
last_updated_at: 2026-05-26
---
# Chat Session Flow
## Summary
…
## Entry Points
…
## Source Trace
- `apps/web/src/services/chat/core/chat-service.ts` :: ChatService, createSessionA graph.json is regenerated alongside it, so AI agents and tools can query
node relations and source paths machine-readably.
Key design choice: the agent writes the file via its own edit tool. We don't parse stdout, so preambles, reasoning, and tool traces in the agent's output are all ignored. The file on disk is the contract.
npm install -g codespoonRequirements:
- Node.js ≥ 20
- A coding agent CLI on
PATH(default:opencode) gitin the target repository
# 1. Scaffold in your repo
cd your-project
codespoon init
# 2. Detect candidate flows (no AI calls — pure static analysis)
codespoon bootstrap
# 3. Pick which candidates to create
$EDITOR .codespoon/runs/bootstrap-candidates.md
# Mark candidates with [x]
# 4. Let the agent fill them in
codespoon bootstrap --apply
# 5. Wire up auto-maintenance
codespoon install-hook
codespoon daemon startFrom now on, when you commit code, the daemon updates affected nodes behind the scenes.
To query nodes during a task:
codespoon spoon "chat session websocket"| Command | Purpose |
|---|---|
codespoon init |
Scaffold codespoon.config.yaml, docs/knowledge/, .codespoon/ |
codespoon bootstrap |
Generate domain candidates from framework heuristics |
codespoon bootstrap --apply |
Have the agent write knowledge nodes for selected candidates |
codespoon validate |
Check node format, source paths, sections |
codespoon build |
Regenerate graph.json from the node files |
codespoon install-hook |
Install the git post-commit hook and inject AGENTS.md guidance |
codespoon daemon start | stop | status |
Manage the local daemon |
codespoon spoon <query> |
Search nodes by keyword (title / id / sources / symbols / body) |
codespoon process <sha> |
Manually re-trigger processing for a commit (debugging) |
codespoon.config.yaml at the repo root:
knowledge_dir: docs/knowledge
state_dir: .codespoon
max_node_chars: 12000
retry_count: 3
ignore:
- node_modules/**
- .git/**
generated_paths:
- src/api/**
agent:
cli: opencode
model: synthetic/hf:zai-org/GLM-5.1
invoke_timeout_seconds: 300
framework_adapters:
- next-app-routerDefaults are sensible; the file is optional but recommended.
your-project/
├─ codespoon.config.yaml ← committed (team-shared)
├─ AGENTS.md ← committed (guidance for agents)
├─ docs/knowledge/ ← committed (the living docs)
│ ├─ nodes/<id>.md
│ └─ graph.json
└─ .codespoon/ ← NOT committed (local state)
├─ cache/
└─ runs/<sha>/
The auto-commit message format:
docs(codespoon): auto-update for abc1234
Affected nodes: chat-session-flow
Source commit: abc1234
Codespoon-Auto: true
The trailer prevents recursive hook firing.
MVP. The architecture has been validated end-to-end against a real Next.js codebase. The next step is longitudinal evaluation — does the loop hold accuracy and usefulness over weeks of real commits?
Things known to work:
- Bootstrap candidate detection for Next.js App Router (with tsconfig paths)
- File-write agent invocation via OpenCode
- Validation gate with retry feedback
- Auto-commit with recursion guard
- Multi-repo daemon
Things explicitly out of scope (for now):
- Vector / semantic search (
spoonuses keyword matching by design) - MCP server (the CLI surface is enough for current agent integrations)
- Multiple framework adapters beyond Next.js (Vite/Remix/etc. coming)
- Full impact tracking through
importgraphs (onlysources-declared files trigger updates)
See AGENTS.md for working principles. Short version:
- Core layer is pure; side effects live in adapters
- Commands are thin (return result objects)
- Agent writes files; we validate
- Validation rules are immune-system gates — every new rule needs a fixture + test
pnpm install
pnpm run build
pnpm run test
pnpm link --global # for local developmentMIT