Remember Codebase

Build a persistent inventory of your development context — repositories, architecture decisions, key dependencies, and team knowledge — in Neotoma memory.

When to use

When a developer wants their agent to persistently understand their codebase context across sessions, without re-prompting project structure, conventions, or architectural decisions each time.

Prerequisites

Run the ensure-neotoma skill first if Neotoma is not yet installed or configured in your current harness.

Workflow

Phase 0: Verify Neotoma

Confirm Neotoma MCP is connected (call get_session_identity).

Phase 1: Inventory the current repo

1. Read project metadata:
   • package.json / pyproject.toml / Cargo.toml (name, version, dependencies)
   • README.md (project description, purpose)
   • Git remote URL and branch structure
2. Scan for architectural signals:
   • Directory structure (src/, lib/, test/, docs/)
   • Configuration files (.env.example, docker-compose.yml, CI configs)
   • Framework and language markers
3. Present the inventory: project name, language, framework, key directories, dependency count.
4. Ask the user to confirm and add any context the scan missed.

Phase 2: Extract entities

1. Repository: create a repository entity with name, remote URL, language, framework, description.
2. Architectural decisions: if the repo has ADR files (docs/adr/) or architecture docs, extract each as a decision entity.
3. Dependencies: create entities for key dependencies that the user wants to track (not all — ask which matter).
4. Team context: if the user provides team member info, store as contact entities linked to the repo.
5. Conventions: if the repo has coding conventions docs, extract key rules as note entities.

Phase 3: Store with provenance

Store the repository entity and related entities with provenance:

• Set source_file for file-derived entities (README, package.json, ADR files).
• Use the combined store path for any files worth preserving as source.
• Link all entities to the repository entity via REFERS_TO.

Phase 4: Wire MCP for ongoing context

Guide the user to configure Neotoma MCP in the project so it is automatically available when working in this repo:

• The neotoma setup command handles this, but verify the project-level MCP config exists.
• Suggest adding the repo entity ID to project-level agent instructions for cross-session continuity.

Phase 5: Report results

Summarize:

• Repository entity created with key metadata
• Entities extracted (decisions, conventions, dependencies)
• MCP configuration status
• Suggest: "Next time you open this project, your agent will know its architecture, conventions, and team context."

Do not

• Store raw file contents (source code) as entity fields — store files via the combined store path when preservation is needed.
• Create entities for every dependency — focus on the ones the user cares about.
• Modify project code or configs without user approval.