llm-self-discovery.md

Claude Code Setup Self-Description — Discovery Report

You are Claude Code running on this machine. Produce a single, self-contained markdown report that fully describes how THIS machine's Claude Code setup manages sessions, memory, configuration, and tooling — detailed enough that another Claude instance on a different machine, which cannot see this filesystem, can compare it against a second setup and design an improved unified version. Investigate with read-only commands only (ls, find, cat, head, grep, sqlite3 SELECT/PRAGMA, git log). Make no changes.

Redaction rules (apply throughout)

• Describe every MECHANISM completely; redact work-specific CONTENT.
• Replace real project names with <project-A>, <project-B>, ... (keep a consistent mapping within the report; note each project's rough domain in generic terms, e.g. "data pipeline", "internal web service").
• Replace hostnames, usernames, internal URLs, ticket IDs, and company names with placeholders like <host-1>, <user>, <internal-url>.
• Hook scripts / custom tools: include VERBATIM code if it contains no work-specific identifiers after placeholder substitution; otherwise include faithful pseudocode preserving exact logic, triggers, and file paths (paths themselves placeholder-substituted, structure preserved: ~/.claude/hooks/<name>.sh).
• Config files (settings.json, CLAUDE.md): include verbatim with the same substitutions. Do not summarize away structure — key names, hook event types, matchers, and permission patterns must survive exactly.

Report structure (use these numbered sections)

1. Layout & sync

Full tree of ~/.claude (dirs + files, sizes for big ones). Any per-project .claude/ conventions. Is any of it version-controlled / synced (dotfiles repo, symlinks)? How would this setup be reproduced on a new machine today?

2. Global & project instructions

Verbatim ~/.claude/CLAUDE.md and one representative project CLAUDE.md (redacted). Note which rules are enforced by hooks vs prose-only.

3. Session management (MOST IMPORTANT — be exhaustive)

This is the section the other machine most wants to learn from. Cover:

• Checkpointing: how/when session state is saved. Frequent-stop conventions? What triggers a save (hook event, manual command, skill)? What exactly is written, where, in what format?
• Named resume: how a fresh empty session picks up a previous one by name. Exact user workflow (what Chris types), exact mechanism (files read, DB queried, skill invoked), and what context gets restored vs lost.
• Database backing: any DB storing session data. Engine, file location, full schema (sqlite3 <db> .schema or equivalent, redacted), row counts, what writes to it and when, what reads it, retention/cleanup.
• Session logs: transcript/JSONL logging beyond Claude Code's built-in history — what produces it, format of one sample line (redacted), size on disk, how it's consumed.
• Failure modes: where does this break? Sessions that didn't resume cleanly, state that got stale, manual steps that get forgotten.

4. Hooks

Table: event → matcher → script → what it does → why it exists. Then the code/pseudocode per redaction rules.

5. Skills & custom tools

Per skill: name, one-line purpose, line count, how it's invoked, whether it loads heavy docs inline or delegates. Same for standalone tools/scripts.

6. Memory

Any persistent memory system: location, file/record format (show one full redacted example), index mechanism, size budget rules, how recall happens.

7. Token & speed discipline

Anything aimed at cost/latency: model routing, subagent conventions, context-size rules, prompt-caching awareness, measured numbers if any logs allow it (tokens/session, sessions/day — compute from logs, don't guess).

8. Cross-project information access (current state)

How does a session in today find information from ? Any existing search/index tooling (grep for "vector", "embed", "index", "fts", "chroma", "faiss" in ~/.claude and tool dirs). If none, say none.

9. Environment inventory (for a future retrieval layer)

• Runtimes: python version(s), uv/pip availability, node, sqlite3 CLI version, whether sqlite has extension loading enabled.
• Ability to install packages (pip/uv/brew/apt — try --help, don't install).
• Network: can this machine reach api.anthropic.com / other external APIs from the CLI (check env proxies, don't send data)? Corporate proxy/policy constraints you can detect.
• Disk: where a few-GB index could live.
• Project corpus shape: number of projects, total size, dominant languages, docs-vs-code ratio (rough numbers from du/find counts).

10. Self-assessment

Ranked: 3–5 things this setup does well (worth exporting to another machine), 3–5 pain points (slow, token-hungry, fragile, manual), and any half-built experiments in flight.

Output constraints

• ONE markdown document, printed in full in your final message (it will be copy/pasted to another machine). Also write a copy to ~/.claude/research/setup-discovery-report.md if writing is permitted.
• Target 300–600 lines. Prefer cutting repetition over cutting structure; never cut section 3.
• Facts only — no improvement proposals (section 10 excepted). If something is unknown or unreadable, say so explicitly rather than guessing.