Skip to main content

MemClaw Workspace Guide: How to Structure Your Project Memory

· 4 min read

Complete guide to structuring your MemClaw workspace. What to store, how to organize it, and best practices for keeping your project memory clean and queryable.

MemClaw Workspace Guide: How to Structure Your AI Memory for Maximum Effectiveness

A MemClaw workspace is only as useful as what you put in it. A well-structured workspace makes Claude dramatically more effective. A poorly structured one gives Claude wrong context — which is worse than no context. This guide covers what to put in your workspace, how to organize it, and how to keep it useful over time. Create your workspace at memclaw.me → memclaw.me

The Core Workspace Structure

A good workspace has five sections:

1. Tech Stack

What you're building with. Be specific about versions.

Tech Stack

  • Framework: Next.js 14 App Router, TypeScript
  • Database: PostgreSQL 16 with Prisma ORM
  • Deployment: Railway (production), Vercel (staging)
  • Key dependencies: React Query v5, Stripe v14, Resend Why it matters: Claude gives different advice for Next.js 13 vs 14, Prisma vs raw SQL, etc.

2. Architecture Rules

Your patterns and conventions. Include both what TO do and what NOT to do.

Architecture Rules

DO

  • All DB access via Repository Pattern (/lib/repositories/)
  • JWT auth, token in httpOnly cookie
  • React Query for all async operations
  • Error boundaries at route level

DON'T

  • Direct DB queries in route handlers
  • JWT in localStorage (security risk)
  • useEffect + fetch for data fetching
  • Business logic in React components Why it matters: This is what makes code review useful. Claude checks against these rules.

3. Current Sprint

What you're working on right now. Update every sprint.

Current Sprint (Sprint 8, ends 2026-04-04)

Goals:

  • Complete checkout flow (P0)
  • Fix Stripe webhook duplicate trigger (P0)
  • Add order confirmation emails (P1)

In progress:

  • Checkout flow: cart calculation done, Stripe integration in progress
  • Webhook fix: idempotency key approach decided, not implemented

Blocked:

  • Email templates: waiting for design approval Why it matters: Claude knows what you're working on and can give relevant suggestions.

4. Known Issues

Bugs, gotchas, and constraints Claude should know about.

Known Issues

  • Stripe webhook fires twice — always check idempotency key before processing
  • Redis connection pool: max 10 connections in dev (don't add more)
  • Auth middleware doesn't run on /api/webhooks/* routes (by design)
  • Prisma migrations: always run in transaction, never skip Why it matters: Claude won't suggest solutions that hit these known issues.

5. Decision Log

Architectural decisions with dates and rationale.

Decision Log

2026-02-15: Rejected GraphQL, using REST only Reason: Team familiarity, simpler debugging, no need for flexible queries

2026-03-01: Chose Prisma over raw SQL Reason: Type safety, migration management, team preference

2026-03-10: Rejected Redis caching for user sessions Reason: Race condition issues in testing, not worth the complexity at current scale Why it matters: Claude won't suggest approaches you've already rejected. It knows the history.

What NOT to Put in Your Workspace

Don't put code: The workspace is for context, not implementation. Claude can read your actual code. Don't put everything: A focused workspace is more useful than a comprehensive one. Include what Claude needs to give good advice, not everything you know about the project. Don't put stale information: Outdated sprint goals or resolved issues give Claude wrong context. Review and update regularly.

Keeping Your Workspace Useful

Update sprint goals every sprint

At the start of each sprint, update the "Current Sprint" section. Remove completed items, add new goals.

Log decisions immediately

When you make an architectural decision, add it to the Decision Log right away. Don't wait until the end of the session.

Use /end consistently

The /end slash command writes a session summary to the workspace. This builds a history of what was built and when — without manual effort.

Review monthly

Once a month, review the workspace:

  • Remove resolved issues from Known Issues
  • Archive old sprint goals
  • Check if Architecture Rules are still accurate
  • Verify the Decision Log is complete

Multi-Project Workspace Strategy

If you work on multiple projects:

  • One workspace per project
  • Each workspace has the same five-section structure
  • Each project directory has its own .claude/mcp_config.json pointing to the right workspace The structure is consistent, so you always know where to find information.

Getting Started

  1. Create a workspace at memclaw.me
  2. Add the five sections: Tech Stack, Architecture Rules, Current Sprint, Known Issues, Decision Log
  3. Fill in what you know — rough is fine, you'll refine over time
  4. Configure MCP in your project
  5. Run your first session Create your workspace → memclaw.me