Give Claude Desktop a Memory

Name: Libragen
Author: Libragen

Help Claude understand your codebase, projects, and context with a personal knowledge library

You’ve just joined a new team. The codebase is massive, the wiki is a maze, and everyone keeps saying “oh, that’s in the ADRs somewhere.” You need answers, but Claude doesn’t know anything about your specific project.

In this tutorial, you’ll build a knowledge library from your project’s documentation and connect it to Claude Desktop. By the end, Claude will answer questions like “Why did we choose Postgres over MongoDB?” or “What’s the deployment process for staging?” using your actual docs.

Time required: ~15 minutes

The scenario: You’ve inherited a codebase called “Nexus” — a payments platform with years of history, dozens of services, and tribal knowledge scattered across READMEs, ADRs, wiki exports, and onboarding docs.

What You’ll Build

A searchable library containing:

Architecture Decision Records (ADRs)
Service READMEs
Wiki/Confluence exports
Onboarding documentation
Team conventions and standards

Once connected, you can ask Claude things like:

“What’s the retry logic for failed payments?”

And get answers grounded in your actual documentation:

Based on the payment-service README and ADR-015, failed payments use exponential backoff with a maximum of 5 retries over 24 hours. The retry intervals are 1min, 5min, 30min, 2hr, and 24hr. After exhausting retries, the payment is marked as FAILED_PERMANENT and triggers an alert to the on-call engineer…

Prerequisites

Node.js 20 or later
Claude Desktop installed
A folder of project documentation (we’ll create sample docs if you don’t have any)

Step 1: Gather Your Documentation

Create a folder structure for your project knowledge:

mkdir -p nexus-docs/{adrs,services,wiki,onboarding}

Architecture Decision Records

ADRs capture the “why” behind technical decisions. Create a sample:

cat > nexus-docs/adrs/ADR-015-payment-retry-strategy.md << 'EOF'
# ADR-015: Payment Retry Strategy

## Status
Accepted (2023-06-15)

## Context
Failed payments need automatic retry logic. We considered:
1. Fixed interval retries
2. Exponential backoff
3. Smart retry based on failure type

## Decision
We'll use exponential backoff with failure-type awareness:
- Retry intervals: 1min, 5min, 30min, 2hr, 24hr
- Network errors: full retry sequence
- Card declined: no retry (immediate permanent failure)
- Insufficient funds: retry at 24hr intervals only

## Consequences
- Reduces unnecessary retries for permanent failures
- Improves success rate for transient issues
- Requires failure classification in payment processor integration
EOF

Service Documentation

Add a service README:

cat > nexus-docs/services/payment-service-README.md << 'EOF'
# Payment Service

Core service handling all payment processing for Nexus.

## Overview
- **Language:** Go 1.21
- **Database:** PostgreSQL 15
- **Message Queue:** RabbitMQ
- **External APIs:** Stripe, PayPal, Adyen

## Key Endpoints

### POST /api/v1/payments
Creates a new payment intent.

```json
{
  "amount": 1000,
  "currency": "USD",
  "customer_id": "cust_123",
  "payment_method": "card"
}
```

### GET /api/v1/payments/:id
Retrieves payment status and history.

## Retry Logic
See ADR-015 for retry strategy. Key points:
- Max 5 retries over 24 hours
- Exponential backoff: 1m, 5m, 30m, 2h, 24h
- Permanent failures skip retry queue

## Local Development
```bash
make dev        # Start with hot reload
make test       # Run test suite
make migrate    # Run database migrations
```

## Deployment
Deployed via ArgoCD. See wiki/deployment-process.md for details.
EOF

Wiki Export

Add some wiki-style documentation:

cat > nexus-docs/wiki/deployment-process.md << 'EOF'
# Deployment Process

## Environments
| Environment | Branch | Auto-deploy |
|-------------|--------|-------------|
| Development | main | Yes |
| Staging | main | Yes (after dev) |
| Production | release/* | Manual approval |

## Staging Deployment
1. Merge PR to main
2. CI runs tests and builds Docker image
3. ArgoCD detects new image, deploys to dev
4. After 30min soak, auto-promotes to staging
5. Slack notification to #deployments

## Production Deployment
1. Create release branch: `release/v1.2.3`
2. CI builds and tags image
3. Create deployment PR in `nexus-infra` repo
4. Get approval from on-call engineer
5. Merge PR, ArgoCD deploys
6. Monitor dashboards for 15min

## Rollback
```bash
# Quick rollback to previous version
kubectl rollout undo deployment/payment-service -n payments

# Rollback to specific version
argocd app rollback payment-service <revision>
```

## Emergency Contacts
- On-call: #incident-response Slack channel
- Platform team: @platform-oncall
EOF

Onboarding Docs

cat > nexus-docs/onboarding/new-engineer-guide.md << 'EOF'
# New Engineer Onboarding

Welcome to Nexus! Here's what you need to know.

## First Week Checklist
- [ ] Get access to GitHub org
- [ ] Join Slack channels: #engineering, #deployments, #incidents
- [ ] Set up local dev environment (see below)
- [ ] Complete security training
- [ ] Shadow an on-call shift

## Local Setup

### Prerequisites
- Docker Desktop
- Go 1.21+
- Node 24+ (for frontend services)
- PostgreSQL client (`psql`)

### Getting Started
```bash
# Clone the monorepo
git clone git@github.com:nexus/platform.git
cd platform

# Start infrastructure
make infra-up  # Starts Postgres, Redis, RabbitMQ

# Run the service you're working on
cd services/payment-service
make dev
```

## Architecture Overview
Nexus is a microservices platform with ~30 services. Key services:
- **payment-service**: Core payment processing
- **customer-service**: Customer data and profiles
- **notification-service**: Email, SMS, push notifications
- **gateway**: API gateway and authentication

Services communicate via:
- REST APIs for synchronous calls
- RabbitMQ for async events
- gRPC for internal high-throughput paths

## Code Style
- Go: follow `go fmt` and our `.golangci.yml`
- TypeScript: Prettier + ESLint config in repo
- Commits: Conventional Commits format
- PRs: Require 1 approval, CI must pass

## Questions?
- Technical: Ask in #engineering or your team channel
- Process: Ask your onboarding buddy
- Urgent: #incident-response
EOF

Step 2: Build the Library

Now build a libragen library from all this documentation:

libragen build ./nexus-docs \
  --name nexus-knowledge \
  --description "Nexus platform documentation, ADRs, and tribal knowledge"

You’ll see:

Processing files...
  ✓ 4 files processed
  ✓ 28 chunks created
  ✓ Embeddings generated
  ✓ Full-text index built

Library saved: nexus-knowledge-1.0.0.libragen (1.2 MB)

Step 3: Connect to Claude Desktop

Install the libragen MCP server:

npx -y install-mcp @libragen/mcp

This automatically configures Claude Desktop. Restart Claude Desktop to load the new server.

Verify the Connection

In Claude Desktop, you should see “libragen” in the MCP tools list (click the hammer icon). You can also ask Claude:

“What libraries do you have access to?”

Claude should respond mentioning nexus-knowledge.

Step 4: Ask Claude About Your Project

Now the magic happens. Ask Claude questions and watch it search your actual docs:

Understanding Architecture

“How do services communicate in Nexus?”

Claude searches your library and responds with specifics from your onboarding doc:

Services in Nexus communicate through three mechanisms:

REST APIs for synchronous request/response calls

RabbitMQ for asynchronous event-driven communication

gRPC for internal high-throughput paths between services

The platform has about 30 microservices, with key ones being payment-service, customer-service, notification-service, and the API gateway…

Finding Tribal Knowledge

“Why do we use exponential backoff for payment retries instead of fixed intervals?”

Claude finds ADR-015:

According to ADR-015 (accepted June 2023), the team chose exponential backoff over fixed intervals for several reasons:

Reduces unnecessary retries for permanent failures like declined cards

Improves success rates for transient issues like network errors

Failure-type awareness — different retry strategies based on why the payment failed

For example, card declines don’t retry at all (immediate permanent failure), while network errors get the full sequence: 1min, 5min, 30min, 2hr, 24hr…

Deployment Questions

“How do I deploy to production?”

Claude walks you through the process from your wiki:

To deploy to production:

Create a release branch: release/v1.2.3

CI automatically builds and tags the Docker image

Create a deployment PR in the nexus-infra repo

Get approval from the on-call engineer

Merge the PR — ArgoCD handles the actual deployment

Monitor dashboards for 15 minutes post-deploy

For rollback, you can use: kubectl rollout undo deployment/payment-service -n payments

Onboarding Help

“I’m new here. What Slack channels should I join?”

Welcome! Based on the onboarding guide, you should join:

#engineering — General engineering discussions

#deployments — Deployment notifications and coordination

#incidents — Incident response and on-call communication

Your first week, you should also shadow an on-call shift and complete security training…

Step 5: Keep It Growing

As you learn more about the codebase, add to your library:

Add Meeting Notes

When you learn something important in a meeting:

cat > nexus-docs/wiki/payment-v2-migration.md << 'EOF'
# Payment v2 Migration Plan

From architecture review 2024-01-15:

We're migrating from the legacy payment processor to Stripe-only.
Timeline: Q2 2024

Key changes:
- Remove PayPal integration (< 2% of transactions)
- Migrate Adyen merchants to Stripe
- Update webhook handlers
- New reconciliation process

Contact: Sarah (payments team lead)
EOF

Rebuild:

libragen build ./nexus-docs \
  --name nexus-knowledge \
  --description "Nexus platform documentation, ADRs, and tribal knowledge"

Add Code Archaeology Notes

When you figure out why something weird exists:

cat > nexus-docs/wiki/why-dual-database-writes.md << 'EOF'
# Why We Have Dual Database Writes

Found this during investigation 2024-02-01.

The payment-service writes to both PostgreSQL AND the legacy Oracle database.
This looks like a bug but it's intentional.

**Reason:** The finance team's reporting system still reads from Oracle.
Migration was planned for 2022 but blocked by compliance requirements.

**Status:** Oracle writes can be removed after Project Phoenix completes (ETA Q3 2024).

**Code location:** `internal/repository/payment_repository.go`, line 142
EOF

Now when future-you (or a teammate) asks Claude “why does payment-service write to two databases?”, they’ll get the answer.

Tips for Maximum Value

1. Document the Undocumented

The most valuable additions are things that aren’t written down yet:

Why a workaround exists
Who to ask about specific systems
What that cryptic error message actually means
Historical context that explains current decisions

2. Use Consistent Language

If your team calls it “the payment service,” don’t call it “payments-svc” in your docs. Consistent terminology improves search accuracy.

3. Include Examples

Real examples (sanitized if needed) help Claude give better answers:

## Common Errors

### "PAYMENT_PROCESSOR_TIMEOUT"
Usually means Stripe is slow. Check status.stripe.com.
Typical during Black Friday / high-traffic events.
**Fix:** Usually resolves itself. If persistent, check our Stripe dashboard for rate limiting.

4. Update Regularly

Set a reminder to rebuild weekly:

# Add to your shell aliases
alias update-nexus='libragen build ~/work/nexus-docs --name nexus-knowledge --description "Nexus platform docs"'

What You’ve Accomplished

You now have:

✅ A searchable knowledge base of your project’s documentation
✅ Claude Desktop connected to your actual project context
✅ The ability to ask natural language questions and get grounded answers
✅ A system that grows smarter as you add more documentation

The next time someone asks “how does X work?”, you can either answer from your library or add the answer to it — building institutional knowledge that outlasts any individual team member.

Next Steps

MCP Integration — Advanced MCP configuration
Building Libraries — Chunking strategies for better search
CLI Reference — All command options