Every time you open Claude Code in a new project, it starts cold. It doesn't know your domain terminology. It has no idea why you made certain architectural decisions last month. It doesn't remember the workaround you discovered for that tricky API edge case that took you three hours. You end up re-explaining the same context over and over, session after session.
And when the session ends, everything you figured out — all the reasoning, the dead ends, the "we tried X and it didn't work because Y" — evaporates. It exists in a .jsonl file buried somewhere in ~/.claude/projects/, readable by no one and referenced by nothing.
We think there's a better model, and two features in Synthadoc v1.1 are the first concrete steps toward it.
The Model We're Building Toward
Here's the opinion we want to stand behind clearly: your wiki should be the persistent memory layer for every AI agent you work with. Not just a README. Not a pile of docs. A structured, queryable, self-maintaining knowledge base that your agents read from, and that their sessions feed back into.
The two features in this post form a loop:
The agent starts informed. The session ends with the knowledge captured. Each cycle makes the next one better. Let's walk through both sides of this loop.
Part 1: Teach Your Agent Before It Starts
The problem
Open Claude Code in your project folder and it picks up context from whatever code is in the directory. But it doesn't know your domain unless you tell it. If you're working on a financial research wiki, the agent doesn't know whether "CAC" means Customer Acquisition Cost or Canada, or that you always cite Bank of Canada sources over secondary news articles.
You can write a one-off instruction prompt. But it disappears when the session ends. You can maintain a CLAUDE.md file manually, but now you're maintaining two things, the wiki and the instructions file, and they drift.
The solution
When you run synthadoc scaffold, it generates three files at your wiki root:
| File | Loaded by |
|---|
CLAUDE.md | Claude Code (automatic, highest-priority instruction source) |
GEMINI.md | Gemini CLI (automatic) |
AGENTS.md | Codex CLI, OpenCode, generic OpenAI agents |
All three carry identical content, domain guidelines derived from your actual wiki pages, a full CLI quick-reference table pre-filled with your wiki name and port, and a table of available MCP tools if you're using the MCP server.
The key word is "derived." The scaffold agent looks at what's actually in your wiki and writes guidelines that reflect your domain. It doesn't produce generic filler. For the History of Computing wiki, it produces guidelines about computing history terminology and citation standards. For a financial due-diligence wiki, it produces guidelines about financial terminology, document types, and source hierarchy.
And because scaffold regenerates these files every time you run it, they stay in sync with your wiki as it grows. You don't maintain them, the system does.
Try it with the demo wiki
# Install the History of Computing demo
synthadoc install history-of-computing --target ~/wikis --demo
If you already have a Claude Code or Opencode subscription, you don't need a separate LLM API key. Open ~/wikis/history-of-computing/.synthadoc/config.toml and set your provider before starting the server:
[agents]
default = { provider = "claude-code" } # no API key — uses your Claude Code subscription
# default = { provider = "opencode" } # no API key — uses your Opencode subscription
Then start the server:
synthadoc serve -w history-of-computing
In a separate terminal window, open the wiki folder in Claude Code:
cd ~/wikis/history-of-computing
claude
Claude Code picks up CLAUDE.md automatically. Ask it something like:
> What pages are in this wiki?
> Can you run a lint check and tell me what issues exist?
> Ingest this URL: https://www.computerhistory.org/timeline/computers/
Claude Code knew to look in the wiki/ directory, understood that pages carry lifecycle states (active, archived), and organized the results by category, because CLAUDE.md told it the wiki's structure and conventions. It ran two shell commands and read two files on its own; you typed one question.
The agent already knows how to run synthadoc lint report, what the lifecycle states mean, and how to manage background jobs, because CLAUDE.md told it. You didn't have to explain any of that.
The ingest completed and updated the existing computing-history-timeline page, but the more interesting moment is what the agent said next. It remembered that the lint report from two prompts earlier had flagged two specific adversarial warnings on that exact page (the FORTRAN "first compiler" claim and the GNU→Linux lineage overstatement), and suggested re-running lint to see whether the new source cleared those up or introduced new contradictions. You didn't ask it to connect those dots. It held the context across the session and acted on it.
The problem
Every Claude Code, Gemini CLI, or Codex session writes a transcript to disk when it ends. Inside that file is everything the agent figured out: why it chose one approach over another, what it tried that didn't work, what edge cases it discovered along the way. But the file sits in a hidden folder, no tool reads it, and the next session starts with no memory of it.
The knowledge existed. It just didn't go anywhere.
The solution
In v1.1.0, .jsonl session files are first-class ingest sources. Point Synthadoc at a session file and it becomes a wiki page — searchable, cross-linked with your other knowledge, citable in future queries.
Not everything in the transcript is worth keeping. Synthadoc filters it down to what matters: the questions you asked and the agent's substantive answers. File reads, shell commands, internal tool calls, and anything that looks like credentials are all dropped. What ends up in the wiki is the reasoning — decisions made, approaches tried, things discovered — not the raw execution log.
You're still inside the Claude Code session from Part 1. Before closing it, ask the agent directly:
> What is the path to the current session file (.jsonl)?
> Ingest this session file into the wiki.
Because CLAUDE.md already told the agent how to run synthadoc ingest, it runs the command itself, no terminal switching needed. Notice that it also flags the new page as meta-content (about running lint and ingesting URLs) rather than computing history, and offers to recategorize or archive it. It knows your domain well enough to recognize when something doesn't belong.
Then keep going in the same session:
> What did we discuss about linting the wiki?
> Why did we ingest the Computer History Museum timeline?
The first answer is a full recall of the lint findings from earlier in the session — specific page names, specific factual errors, the open decision about whether to fix them directly. It read that from the ingested transcript, not from memory.
The second answer is more interesting. No reason was ever given for ingesting the CHM URL. But the agent pieced it together: Wikipedia was blocked, CHM covered similar ground, and the page it updated happened to be one of the pages flagged in the lint report. It stated clearly that this was inference, not fact — "that's inference on my part, not something you stated" — and offered to verify whether the update actually resolved the lint warnings.
That's the loop working. The session is now a wiki page. The next time you open Claude Code on this wiki, it can search that page and pick up exactly where this session left off.
Two things are worth noting about what landed in Obsidian.
The page name is the session UUID. The slug comes straight from the .jsonl filename. It's not pretty, but it's honest, you can always ask the agent to rename it to something descriptive, or just archive it if the session was operational rather than knowledge-producing.
The page is in wiki/candidates/, not wiki/. When staging is enabled, every ingest goes through a review queue before appearing in query results. This is intentional, it lets you review auto-generated content before it influences future answers. To promote it:
> Promote the ingested session page to the wiki.
One command. The agent found the candidate, ran the promotion, confirmed index.md was updated
under "Recently Added", and then immediately flagged that the page will likely appear as an orphan on the next lint pass, because a session transcript about running lint and ingesting URLs doesn't fit the computing history type schema and has no natural cross-links to other pages. It offered to fix the frontmatter before that happens.
That's the same domain awareness from Part 1 carrying through to the end: the agent isn't just executing commands, it's evaluating the results against what it knows about this wiki.
Or if it's noise rather than knowledge, discard it instead:
> Discard the session candidate — it's just operational meta-content.
The agent knows the staging workflow from CLAUDE.md. If a page ever seems to disappear after ingest, the candidates queue is the first place to check.
The Skill Works Standalone: No Full Synthadoc Required
This is worth calling out explicitly. If you want to use the session ingestion skill without installing the full Synthadoc engine, you can install it directly into Claude Code:
npx -y skills add axoviq-ai/synthadoc --skill session --agent claude-code
This registers the session skill with Claude Code's skill system. Claude Code can then extract and summarize your past sessions without Synthadoc running at all. It's a lighter-weight entry point if you want to start experimenting without the full setup.
Full Session Skill documentation
Why This Matters Beyond the Demo
We've had tools that help AI agents complete tasks for a while now. What's been missing is the layer underneath, a knowledge base that persists across sessions, keeps domain context current, and captures the reasoning that comes out of each session for the next one.
The pattern of generating agent context files from actual wiki content, rather than having humans maintain them, is something we think is underexplored. The closer the agent's understanding is to what's actually in the knowledge base, the less time you spend on repeated explanation and the more the agent can actually build on prior work.
Session ingestion closes the other half of that loop. Every time the agent figures something out — why a decision was made, what didn't work, what sources it drew from — that reasoning gets captured as a wiki page. The next session can find it and build on it instead of starting over.
That's the loop we're trying to build. v1.1.0 is the first full turn of it.