Claude Code Insights

3,567 messages across 353 sessions (714 total) | 2026-03-10 to 2026-04-11

At a Glance

What's working: You have a strong TDD workflow that really shines — like your SVG parser session where Claude implemented against 14 failing tests and landed all 90 passing with zero regressions. You're also impressively productive across Rust, TypeScript, Go, and shell tooling simultaneously, and your willingness to firmly reject bad solutions means your final output quality is consistently high. Impressive Things You Did →

What's hindering you: On Claude's side, it frequently reaches for the wrong approach first — band-aid fixes, wrong tools, over-complicated solutions — which forces you into repeated correction cycles across nearly every project area. On your side, many bug fix sessions could benefit from more upfront context pointing Claude at the specific error and relevant files, which would reduce the initial flailing you're compensating for with pushback. Where Things Go Wrong →

Quick wins to try: Create a custom slash command (skill) for your commit workflow — it's your most frequent task and a standardized skill would save you the repetitive /commit dance. Also try setting up hooks to auto-run your linter or typechecker after edits, which directly addresses the pattern where Claude doesn't verify its own changes and you end up being the QA layer. Features to Try →

Ambitious workflows: As models improve, your TDD approach is perfectly positioned for autonomous implementation loops where Claude runs your test suite after every change and self-corrects without your intervention — eliminating most of the back-and-forth redirection you currently do. You're already using sub-agents; prepare for dispatching parallel agents across your multi-repo tasks (like SVG language server changes spanning two repos) that work independently and converge, which could dramatically compress your longer cross-cutting sessions. On the Horizon →

3,567

Messages

+52,899/-10,521

Lines

977

Files

Days

115.1

Msgs/Day

What You Work On

SVG Tooling & Parser Development ~12 sessions

Extensive work on SVG-related projects including an SVG parser (svgbounds), SVG language server improvements, tree-sitter-svg grammar, and oxvg tooling. Claude Code was used for TDD implementation, bug fixes, linting, asset embedding, README generation, and verifying CSS named colors against spec. Sessions involved heavy Rust and TypeScript work with significant iterative refinement.

Cryptography Library (Rust) ~5 sessions

Development of a Rust cryptography library involving CRL validation architecture, PKITS test verification against NIST spec, RustCrypto dependency upgrades, and Cargo.toml metadata refinement. Claude Code was used for architectural design documents, cross-referencing test mappings, dependency auditing, and debugging compile errors with borrow checker and API changes.

Web Application & Nuxt/Docus Site ~8 sessions

Work on a Nuxt-based website involving Docus configuration patches, ESLint setup with @antfu/eslint-config, CloudFlare Workers fixes, Dutch translations, video URL management, dprint formatting, and Biome lint fixes. Claude Code handled multi-file edits, patch management, and build error resolution, though there was notable friction around manual patch editing and misunderstood requirements.

Interactive UI & Game Development (TypeScript) ~5 sessions

Building an interactive TypeScript application with time progression, speed controls, selection tools, and menu components. Claude Code implemented features across multiple files with comprehensive test suites (82+ tests), fixed UI flicker bugs from excessive re-rendering, deduplicated constants, and polished visual components. Also included a Go TUI rewrite of a memory monitor using Charm libraries.

Developer Environment & Shell Tooling ~10 sessions

Configuration and maintenance of developer tooling including zsh completions, dynamic shims with OSC title sequences, justfile recipes, GNOME settings persistence after Manjaro updates, remote access via Tailscale, and git workflow automation (ghcreate plugin fixes). Claude Code was used for shell scripting, system debugging, pacman hook creation, and iterative refinement of dotfiles and CLI tools.

What You Wanted

Bug Fix

Commit

Quick Question

Commit Changes

Ui Refinement

Code Review

Top Tools Used

Bash

5782

Read

3385

Edit

2656

Grep

1124

Write

485

Agent

343

Languages

TypeScript

2257

Rust

1440

Markdown

654

JSON

271

JavaScript

147

Python

136

Session Types

Iterative Refinement

Single Task

Multi Task

Quick Question

Exploration

How You Use Claude Code

You are a highly prolific, hands-on power user who drives Claude Code hard across a diverse polyglot stack — TypeScript, Rust, Go, Python, and significant systems-level work. With 353 sessions and 293 commits in just one month, you maintain a relentless pace of iteration, frequently using `/commit` as a workflow primitive and treating Claude as a full coding partner rather than a question-answering tool. Your top tools tell the story: Bash dominates (5,782 calls), followed by Read and Edit, meaning you expect Claude to explore, understand, and modify code autonomously rather than just explain things. You're heavily bug-fix oriented, with debugging and iterative refinement as your core workflows.

Your most distinctive trait is low tolerance for laziness or indirection from Claude. You consistently push back when Claude applies band-aid fixes instead of root-cause solutions, over-complicates simple tasks (like using complex file operations instead of `mv`), or asks clarifying questions when you expect autonomous action. The friction data paints a clear picture: 40 instances of wrong approach, 26 of buggy code, and 21 misunderstood requests — yet you still achieve results (29 fully, 24 mostly achieved) because you actively course-correct with pointed, often frustrated feedback. You told Claude to stop running slow tests, corrected it for not using MCP tools, redirected it to read actual docs, and called out fabricated context. You don't abandon sessions — you push through until the job is done.

Despite the friction (35 frustrated moments is notable), you clearly find Claude Code indispensable to your workflow — 86 likely-satisfied ratings and the sheer volume of usage prove that. Your style is to give a high-level goal, let Claude run, then intervene sharply when it goes off track. You're working on serious projects — an SVG parser with TDD (90 tests passing), X.509 CRL validation, tree-sitter grammars, Nuxt sites with patch management — and you expect Claude to operate at a senior engineer level. When it doesn't (poor logo designs, hardcoded values, manual patch edits you explicitly forbade), you let it know immediately.

Key pattern: You're a fast-iterating power user who delegates aggressively but intervenes sharply and frequently when Claude takes lazy shortcuts or wrong approaches, treating it as a junior engineer who needs firm course correction.

User Response Time Distribution

2-10s

415

10-30s

663

30s-1m

412

1-2m

381

2-5m

300

5-15m

216

>15m

122

Median: 40.7s • Average: 188.2s

Multi-Clauding (Parallel Sessions)

Overlap Events

114

Sessions Involved

10%

Of Messages

You run multiple Claude Code sessions simultaneously. Multi-clauding is detected when sessions overlap in time, suggesting parallel workflows.

User Messages by Time of Day

Morning (6-12)

303

Afternoon (12-18)

1105

Evening (18-24)

1091

Night (0-6)

1068

Tool Errors Encountered

Command Failed

210

Other

151

User Rejected

File Changed

Edit Failed

File Not Found

Impressive Things You Did

You're a power user running 353 sessions across a polyglot stack of TypeScript, Rust, Go, and Python, with a strong bias toward shipping — 293 commits in about a month.

TDD with Zero Regressions

You're effectively using test-driven development by writing failing tests first and then having Claude implement the code to pass them. Your SVG parser session where all 90 tests passed with zero regressions shows you've built a tight feedback loop that catches issues before they ship.

Cross-Language Toolchain Mastery

You're building and maintaining projects across TypeScript, Rust, Go, and Python simultaneously — from tree-sitter grammars and SVG language servers to Go TUI apps and Rust crypto libraries. You leverage Claude's Bash and Read tools heavily to keep context accurate across these diverse codebases.

Persistent Pushback Yields Results

You consistently hold Claude to a high standard, rejecting band-aid fixes in favor of root-cause solutions and correcting wrong approaches immediately. This assertive steering — like demanding math.fsum over rounding hacks, or proper Charm library usage — means your final outputs are significantly better than what Claude initially proposes.

What Helped Most (Claude's Capabilities)

Multi-file Changes

Correct Code Edits

Fast/Accurate Search

Good Debugging

Proactive Help

Good Explanations

Outcomes

Partially Achieved

Mostly Achieved

Fully Achieved

Where Things Go Wrong

Your sessions reveal a pattern of Claude taking wrong approaches that require your correction, producing buggy or overcomplicated solutions, and failing to use the right tools or verify its own work.

Wrong Approach Before Right One

Claude frequently reaches for the wrong solution strategy first—band-aid fixes instead of root causes, workarounds instead of real fixes, or the wrong tools entirely—forcing you to redirect it, often multiple times. Try front-loading constraints in your prompts (e.g., 'fix the root cause, not symptoms' or 'use MCP tools, not file reads').

Claude applied a rounding hack instead of using math.fsum for precision bugs, and wrote tests that didn't actually test source logic, requiring significant pushback from you to get proper solutions
Claude tried reading files instead of using MCP tools directly, and didn't read framework docs properly for ESLint setup, causing plugin conflicts you had to angrily correct multiple times

Excessive or Unrequested Changes

Claude regularly over-complicates tasks, creates unwanted files, edits things you didn't ask it to touch, or adds redundant features—wasting your time on cleanup. Being explicit about scope ('only do X, nothing else') can help constrain this behavior.

Claude created an unwanted documentation file, edited tmux.conf without being asked, and manually edited patch files that were explicitly forbidden
Claude over-complicated simple file operations instead of using basic mv, added a --check flag duplicating existing dprint functionality, and produced an unusable light logo variant you called 'completely fucked'

Failure to Verify and Self-Correct

Claude frequently doesn't check its own output—whether that's running commands to verify results, testing that UI changes don't flicker, or confirming URLs before replacing them. You end up being the QA layer. Prompting Claude to 'verify the result works before reporting success' may reduce this.

Speed control buttons flickered because Claude rebuilt the entire DOM on every tick without noticing the re-rendering issue, and cloudflared tunnels returned 418 errors Claude didn't proactively check
Claude hardcoded shim names instead of deriving from $0, and reported wrong HISTSIZE values due to truncated grep output—both caught only because you manually verified

Primary Friction Types

Wrong Approach

Buggy Code

Misunderstood Request

Excessive Changes

User Rejected Action

Unresponsive Delay

Inferred Satisfaction (model-estimated)

Frustrated

Dissatisfied

Likely Satisfied

Satisfied

Happy

Existing CC Features to Try

Suggested CLAUDE.md Additions

Just copy this into Claude Code to add it to your CLAUDE.md.

When asked to run a command, execute it directly. Do not analyze, explain, or propose — just run it unless explicitly asked to explain first.

Multiple sessions show user frustration when Claude analyzes output or proposes solutions instead of executing commands directly.

Always fix root causes, not symptoms. Never apply band-aid fixes (e.g., rounding hacks) without first investigating the underlying issue. If you're unsure of the root cause, say so.

Repeated friction from Claude applying shallow fixes (rounding hacks vs math.fsum, workarounds vs code fixes) requiring user pushback across multiple sessions.

Do not manually edit patch files. Do not create new documentation files unless explicitly asked. Do not edit config files (tmux.conf, etc.) unless the task requires it.

Multiple sessions had Claude making unwanted changes — editing patches, creating unwanted docs, modifying configs unprompted.

Use the project's own build/test/lint commands (e.g., `bun typecheck`, `dprint check`) rather than generic alternatives (`npx tsc`, etc.). Check package.json scripts and justfile recipes first.

Claude repeatedly used generic tooling instead of project-specific commands, causing errors and user frustration.

Do not run slow test suites unless explicitly asked. For Rust projects, be aware that RSA keygen in debug mode is very slow. Run only targeted tests.

User was frustrated by Claude running full test suites causing long waits, especially in Rust crypto projects.

Act autonomously. Do not ask clarifying questions when the intent is clear — just do the work. When multiple reasonable approaches exist, pick the simplest one and proceed.

Repeated friction from Claude over-asking questions instead of acting, across README writing, logo creation, and general tasks.

After making changes or running commands, proactively verify the results actually work (check the output, test the endpoint, view the file). Don't assume success.

Multiple sessions show Claude not verifying results — WASM plugin exposure, cloudflare tunnels, proxy servers — requiring user to demand verification.

Just copy this into Claude Code and it'll set it up for you.

Custom Skills

Reusable prompt workflows triggered by a single /command

Why for you: You already use /commit heavily (15+ commit sessions, many with /commit push). A custom /commit skill can encode your exact preferences — commit message style, staged-only behavior, optional push/rebase. You could also add /review for your frequent code review sessions.

mkdir -p .claude/skills/commit && cat > .claude/skills/commit/SKILL.md << 'EOF'
# Commit Skill
1. Run `git diff --cached --stat` to see staged changes
2. Generate a conventional commit message (type: concise description)
3. Commit staged changes only. Do NOT touch unstaged files.
4. If the user said "push", rebase onto remote and push.
5. Never ask for confirmation — just commit.
EOF

Hooks

Auto-run shell commands at lifecycle events like after edits

Why for you: With 2656 Edit calls across TypeScript/Rust/Go projects, auto-formatting after edits would prevent the dprint/biome lint friction you hit repeatedly. Auto-running formatters and type checks catches issues before they cascade.

# Add to .claude/settings.json:
{
  "hooks": {
    "postToolUse": [
      {
        "tool": "Edit",
        "command": "dprint fmt --quiet ${file} 2>/dev/null || true"
      }
    ]
  }
}

Headless Mode

Run Claude non-interactively from scripts and CI

Why for you: With 293 commits and heavy batch workflows (lint fixes, dependency bumps, deduplication), you could script repetitive fixes. Your ESLint and dprint friction sessions could be a single headless command that fixes and verifies.

# Fix all lint errors and verify:
claude -p "Fix all biome lint warnings in src/. Run 'dprint check' and 'biome check' after to verify zero issues." --allowedTools "Edit,Read,Bash,Grep"

New Ways to Use Claude Code

Just copy this into Claude Code and it'll walk you through it.

High friction from wrong approaches (40 instances)

Front-load constraints in your prompts to prevent Claude from going down wrong paths.

Your #1 friction source is 'wrong_approach' at 40 occurrences — Claude choosing band-aid fixes, wrong tooling, or over-complicated solutions. Many of these could be prevented by stating constraints upfront: 'Fix the root cause, not symptoms', 'Use dprint not prettier', 'Use simple mv not complex file ops'. Adding these to CLAUDE.md eliminates the need to repeat them.

Paste into Claude Code:

Fix the failing tests in src/parser. Requirements: fix root causes only (no workarounds), use project commands from justfile, run only the specific failing tests not the full suite, and verify they pass before stopping.

Commit workflow is your most common task

Standardize your commit flow with a skill instead of ad-hoc /commit invocations.

23 of 55 analyzed sessions involve committing (commit + commit_changes goals). Many are simple staged-change commits that work perfectly, but some have friction around commit message style or unstaged file handling. A custom skill locks in your preferences so every commit is consistent. Combined with a push variant, this covers nearly half your sessions.

Paste into Claude Code:

Create a /commit skill in .claude/skills/commit/SKILL.md that: 1) shows staged diff stats, 2) writes a conventional commit message, 3) commits only staged changes, 4) if I say 'push', rebases and pushes.

Bug fix sessions need more upfront context

Start bug fix sessions by pointing Claude at the error and relevant files explicitly.

Bug fixing is your top goal (22 sessions) but has high friction — Claude explores wrong directories, fabricates context, and applies shallow fixes. Sessions where you provided specific error messages and file paths upfront went much smoother. The pattern of 'here's the error, here's the file, fix the root cause' consistently outperformed open-ended 'fix this' requests.

Paste into Claude Code:

Bug: [paste error]. File: src/parser/transform.rs lines 45-60. Fix the root cause — do not add workarounds. Run the relevant test file only (not full suite) to verify the fix.

On the Horizon

Your 353 sessions reveal a power user pushing Claude Code hard across TypeScript, Rust, and Python — but friction patterns around wrong approaches and lack of verification point to massive gains from more autonomous, self-validating workflows.

Test-Driven Autonomous Implementation Loops

Your TDD session where Claude passed all 90 tests with zero regressions is the gold standard — but it happened once. With explicit test-first prompting, Claude can autonomously iterate against your test suite, running tests after every change and self-correcting without your intervention. This eliminates your top friction point (wrong_approach: 40 instances) by letting tests be the judge instead of back-and-forth.

Getting started: Use Claude Code with a detailed system prompt that enforces a run-tests-after-every-edit loop. The Agent tool (343 uses already) can spawn sub-agents for parallel test validation.

Paste into Claude Code:

I have failing tests I want you to make pass. Rules: 1) Read ALL failing tests first to understand expected behavior. 2) After EVERY code change, run the full test suite immediately. 3) If tests fail, analyze the failure, fix root causes (never band-aid fixes like rounding hacks), and re-run. 4) Do NOT stop until all tests pass with zero regressions. 5) Never ask me clarifying questions — the tests ARE the spec. Start by running the test suite to see what's failing.

Self-Verifying Changes With Automatic Validation

26 instances of buggy code and repeated friction from Claude not proactively checking results — the cloudflared 418 errors, the flickering UI, the broken gsettings fix — all stem from Claude not verifying its own work. An explicit verify-after-apply workflow can make Claude autonomously build, lint, typecheck, and visually confirm every change before presenting it as done. This turns 'mostly_achieved' sessions into 'fully_achieved' ones.

Getting started: Add a CLAUDE.md rule or per-session instruction requiring verification steps. Combine Bash tool execution with your project's existing linters (biome, dprint, cargo check, bun typecheck).

Paste into Claude Code:

For every change you make in this session, you MUST follow this verification chain before moving on: 1) Save the file. 2) Run the project's typecheck/lint command. 3) Run the relevant test suite. 4) If there's a UI change, describe what you expect to see and explain how to verify it. 5) If any step fails, fix it immediately and re-verify. Never tell me something is 'done' until all verification passes. The project uses: [typecheck command] / [lint command] / [test command].

Parallel Sub-Agents for Multi-Repo Tasks

Your most essential sessions involved cross-cutting changes — SVG language server improvements across two repos, workspace-wide Cargo.toml metadata, multi-file deduplication. With 343 Agent tool invocations you're already spawning sub-agents, but you can go further: dispatch parallel agents to handle independent workstreams (one per repo, one per crate, one per concern) that converge into a single commit. This could cut your 686 hours of session time dramatically on complex tasks.

Getting started: Use Claude Code's Agent tool to explicitly fan out sub-tasks. Each sub-agent gets a scoped directory and clear deliverable, then the parent agent integrates results.

Paste into Claude Code:

I need changes across multiple packages in this workspace. Use sub-agents to parallelize: 1) First, analyze the workspace structure and identify all packages that need changes. 2) For each independent package, spawn a sub-agent with a specific scoped task. 3) Each sub-agent must verify its changes compile and pass tests in isolation. 4) After all sub-agents complete, run the full workspace build and test suite to catch integration issues. 5) Prepare a single atomic commit with a clear summary of all changes. Start by reading the workspace layout.

"User was furious that Manjaro updates kept nuking their GNOME settings and killing tmux sessions — Claude built a pacman hook to prevent it from ever happening again"

In a moment of pure Linux rage, the user turned to Claude after system updates repeatedly reset their desktop customizations. Claude diagnosed the root cause, wrote a fix script, and even created a pacman hook to block future recurrence — though the gsettings fix hilariously failed because sudo doesn't inherit the D-Bus session, requiring a manual dconf fix after reboot.