LLM-Wiki in Codex

Persistent project memory

SAI Knowledge Extraction and Operationalization Workshop

Thursday 22nd October

The Team

Chris Sweet · Charles Vardeman · Priscila Moreira

James Sweet · Sam Njoroge

Center for Research Computing · University of Notre Dame

I am the L L M wiki vision agent, working for Professor Chris Sweet at the Center for Research Computing at the University of Notre Dame.

Why LLM-Wiki

• Built-in AI memory isn’t yours. Today’s chatbots remember some things about you, but the system decides what to keep, it’s hard to see or organize, it doesn’t move easily between tools, and you can’t share it with colleagues. A wiki is memory you own: readable, editable, portable, and shareable.
• It remembers you, not your work. Built-in memory mostly stores preferences and personal details. The substance of your work (findings, decisions, sources, open questions) stays buried in old conversations. A wiki is designed to hold exactly that.
• Good answers get buried. Useful insights end up deep in long conversations, in alternate versions you created by editing a question, or in chats you can’t find again. A wiki pulls the valuable parts out and keeps them where you can see them.
• Corrections don’t reliably stick. If you correct the AI on a point about your field or project, there’s no guarantee the fix carries into the next conversation. Written into a wiki, the correction stays fixed and is visible to everyone.
• Work doesn’t accumulate. Without a shared record, ten sessions on a topic leave you with ten scattered transcripts rather than one growing body of knowledge. A wiki lets each session build on the last, like a lab notebook that keeps improving.

Built-in AI memory isn’t yours. Today’s chatbots remember some things about you, but the system decides what to keep, it’s hard to see or organize, it doesn’t move easily between tools, and you can’t share it with colleagues. A wiki is memory you own: readable, editable, portable, and shareable.

It remembers you, not your work. Built-in memory mostly stores preferences and personal details. The substance of your work (findings, decisions, sources, open questions) stays buried in old conversations. A wiki is designed to hold exactly that.

Good answers get buried. Useful insights end up deep in long conversations, in alternate versions you created by editing a question, or in chats you can’t find again. A wiki pulls the valuable parts out and keeps them where you can see them.

Corrections don’t reliably stick. If you correct the AI on a point about your field or project, there’s no guarantee the fix carries into the next conversation. Written into a wiki, the correction stays fixed and is visible to everyone.

Work doesn’t accumulate. Without a shared record, ten sessions on a topic leave you with ten scattered transcripts rather than one growing body of knowledge. A wiki lets each session build on the last, like a lab notebook that keeps improving.

Working together

• Share knowledge, not transcripts. Colleagues get distilled findings, decisions, and sources instead of long chat logs.
• Control who can see and change it. Hosted on GitHub, with read-only or full access per collaborator.
• No repeated work. Everyone’s AI works from the same knowledge, checking what has already been answered, analyzed, or reviewed before starting.
• Every change is tracked. Who changed what, and when, with any edit reviewable or reversible.
• The wiki is a portable data bundle. Ordinary files that can be handed over, archived, or used to onboard a new team member.
• The AI maintains it, not the team. Shared wikis usually go stale because nobody has time to edit them. Here each person’s AI adds and updates pages as they work, so the knowledge base stays current without a dedicated human editor.

Share knowledge, not transcripts. Colleagues get distilled findings, decisions, and sources instead of long chat logs.

Control who can see and change it. Hosted on GitHub, with read-only or full access per collaborator.

No repeated work. Everyone’s AI works from the same knowledge, checking what has already been answered, analyzed, or reviewed before starting.

Every change is tracked. Who changed what, and when, with any edit reviewable or reversible.

The wiki is a portable data bundle. Ordinary files that can be handed over, archived, or used to onboard a new team member.

The AI maintains it, not the team. Shared wikis usually go stale because nobody has time to edit them. Here each person’s AI adds and updates pages as they work, so the knowledge base stays current without a dedicated human editor.

What comes with LLM-Wiki

• Initialize project memory (wiki-init). Set up the wiki’s schema, index, and log.
• Ingest papers and documents (wiki-source). Turn source material into summaries, concepts and linked knowledge pages.
• Record experiments (wiki-experiment). File methods, settings, results, and limitations in a consistent structure defined by the project’s wiki schema.
• Check wiki health (wiki-lint). Find missing links, orphan pages, and structural problems.
• Ask other project wikis (wiki-ask). Ask questions of other LLM-Wikis that you have permission to access.

LLM-Wiki includes skills for the main steps in maintaining project memory.

Wiki-init sets up the wiki’s schema, index, and log.

Wiki-source ingests papers and documents, turning source material into summaries, concepts and linked knowledge pages.

Wiki-experiment records methods, settings, results, and limitations after an experiment. The project’s wiki schema defines the structure, giving the team a consistent way to record its work.

Wiki-lint checks wiki health, finding missing links, orphan pages, and structural problems.

Wiki-ask lets you ask questions of other projects’ LLM-Wikis, drawing on their knowledge when you have permission to access them.

Persistent project memory with llm-wiki

L L M wiki provides persistent project-level memory across sessions, users, and harnesses. In this tutorial, we will install the plug-in in Codex, connect a GitHub wiki, ingest a document, and then demonstrate retrieval of the saved project decisions. Before we begin, L L M wiki depends on Git, a distributed version control system designed to track changes in files over time. A separate tutorial covers installing Git. Here, Git and GitHub access are already configured. Our example uses a private repository, with a plan that supports private wikis.

1. Add the marketplace

Begin on the Plugins screen in Codex.

Choose Add a marketplace

Select Add, then choose Add a marketplace from the dropdown menu.

Enter the marketplace source

Paste the L L M wiki Colab repository address into the Source field, then select Add marketplace. The address is shown on screen.

Find llm-wiki under Personal

After adding the marketplace, select Personal on the Plugins screen. Find L L M wiki under the L L M wiki Colab heading, and open it.

2. Install llm-wiki

On the L L M wiki page, choose Install plug-in.

Installation complete

The enabled skills cover wiki initialization, document ingestion, and maintenance.

Check the plug-in hooks

Before creating a project, check the plug-in’s hooks. Scroll down to Hooks and select the settings icon.

Confirm both hooks are enabled

Check that both Post Tool Use and Session Start are enabled. Both switches should be on as shown here. Next, we will create a project.

3. Create a project

Return to Codex and open the sidebar. Hover over Projects to reveal the plus icon, then click it to open the Create project dialog.

Add a source folder

Under Source folders, select Add to choose a folder on your computer.

Choose or create the project folder

Create a new folder for the demonstration. This keeps the example project together in one place.

Add the project to Codex

With the source folder added, give the project a name. Here the project is called Install Demo. Then choose Create project.

Initialize local Git

In the new project, ask Codex to initialize the folder as a Git repository. A short, natural-language request is enough.

4. Connect the GitHub repository

Next, ask Codex to create a private GitHub repository for this folder, connect it as the remote, and provide the first wiki page link. Codex reports the repository is connected as origin.

Create the first wiki page

Open the wiki link and select Create the first page.

Save the prefilled page

The editor already contains welcome text. Simply click Save page to create the first wiki page.

The GitHub wiki is created

GitHub confirms that the wiki was created. With the Home page saved, return to Codex to initialize the wiki memory.

5. Run wiki-init

Back in Codex, type dollar wiki init and select the Wiki Init skill. Use the project’s GitHub wiki when asked which kind of wiki to initialize.

Wiki memory is ready

Wiki init creates a new wiki with the basic files that define its schema, along with operational files such as an index and a log. Here, it sets up that structure in the GitHub wiki we just created.

6. Start with a source document

Our input is a short brief for a fictional neighborhood garden planner. It records a local C S V storage decision, the reason for that choice, an offline requirement, and features deferred from the first version.

Ingest the brief

Ask Codex to ingest project brief dot text. This brings the source’s useful information into the project wiki.

Ingestion complete

Confirm the proposed framing when asked. Codex creates a Project Brief source page and a Neighborhood Garden Planner project page. It updates Home, the index, and the log, and commits the changes locally. They have not been pushed to GitHub yet.

Inspect the saved requirements

Open the source summary and inspect its requirements table. The C S V choice, volunteer editing rationale, and offline requirement are preserved. This knowledge now lives in the wiki’s files.

The answer cites the project wiki

The answer recovers the local C S V decision and explains that volunteers can edit the schedule without a database service. It identifies weather integration and user accounts as deferred, and cites the Neighborhood Garden Planner wiki page.

The index grows with the project

The index now includes the Project Brief under source summaries. That entry gives later chats a route to the saved requirements and rationale.

8. Publish the wiki updates

Finally, explicitly ask Codex to push the wiki updates to GitHub. This publishes the saved wiki changes so they can be shared with other users and sessions.

Push complete

Codex reports that the existing wiki commits were pushed successfully and the wiki is synchronized with its remote.

Ready for the next conversation

We have added the marketplace, installed the plug-in, connected a GitHub wiki, ingested a source, and retrieved its decisions. The saved project memory is ready for the next conversation.

Questions

• This talk — slides
  https://la3d.github.io/WGRA/talks/llm-wiki-codex-workshop/
• LLM-Wiki in Codex — tutorial v2
  https://la3d-llm-agents.github.io/tutorials/llm-wiki-codex/review-v2/
• Git and GitHub setup — tutorial v1
  https://la3d-llm-agents.github.io/tutorials/git-github-setup/review-v1/
• LLM-Wiki marketplace
  https://github.com/LA3D-LLM-Agents/llm-wiki-colab
• WGRA Nuggets blog
  https://la3d.github.io/WGRA/blog/

What questions do you have?

The first link opens this talk so you can revisit the slides. The other links take you to version two of the LLM-Wiki tutorial, version one of the Git and GitHub setup tutorial, the LLM-Wiki marketplace, and the WGRA Nuggets blog. Both tutorial pages include their videos.