bootstrap

Infrastructure

Session initialization with memory loading, service startup, and context synthesis.

Overview

Bootstrap is an infrastructure skill that initializes Claude Code sessions. It loads cross-session memory, starts required services, and synthesizes context for the session.

Invocation

/bootstrap                 # Full bootstrap (memory + services)
/bootstrap --secondary     # Secondary session (no services)
/bootstrap --quick         # Quick bootstrap (skip services)

Also triggers on: start session, initialize

What Bootstrap Does

1. Load Memory

• Primary CLAUDE.md from current repository
• Cross-session files: active-work.md, todos.md, architecture-decisions.md
• Discover additional CLAUDE.md files across repos

2. Check Command Approvals

• Scan flagged directory for pending approvals
• Prompt for approval of flagged commands
• Update permission grants

3. Start Services

• PostgreSQL (verify running)
• Redis (auto-start if needed)
• Next.js dev server (auto-start)
• BullMQ worker (auto-start)
• Docker services (optional)

4. Synthesize Context

• Combine loaded memory
• Highlight recurring items and blockers
• Generate session summary

Memory Architecture

Bootstrap loads memory from four layers:

Layer	Path	Purpose
1. Global Public	~/.claude/CLAUDE.md	Skill governance, gate handling
2. Global Private	catalystrl-claude-data/	Private session notes
3. Parent	/code/CLAUDE.md	Cross-cutting workspace rules
4. Repository	{repo}/CLAUDE.md	Repo-specific rules

Services Configuration

config.json (excerpt)

"services": [
  {
    "name": "PostgreSQL",
    "check": "pg_isready",
    "auto_start": false
  },
  {
    "name": "Redis",
    "check": "redis-cli ping",
    "start": "redis-server --daemonize yes",
    "auto_start": true
  },
  {
    "name": "Next.js Dev Server",
    "check": "curl -s http://localhost:3000",
    "start": "npm run dev",
    "auto_start": true
  }
]

Gates

Gate	Mode	Description
memory_integrity	STRICT	Memory files must not be corrupted
service_startup	PERMISSIVE	Services should start, warns if not
repository_access	PERMISSIVE	Repos should be accessible

Patterns Demonstrated

Four-Layer Memory - Global, parent, repo-specific
Service Management - Health checks, auto-start
Workflow Variants - default, secondary, quick modes
Gate Modes - STRICT vs PERMISSIVE enforcement