Claude Code Insights

1,359 messages across 291 sessions (1,658 total) | 2026-02-04 to 2026-02-16

At a Glance

What's working: You've built a genuinely impressive meta-layer of Claude skills — /check, all-green, Sentry daily review, Intercom triage — and you iterate on them based on real usage, which compounds your productivity over time. You're also one of the more effective users at driving full-cycle PR ownership in single sessions, from implementation through CI fixes and review comment resolution, and you've wired Claude into your production observability stack to do real operational debugging across PostHog, Sentry, and AWS. Impressive Things You Did →

What's hindering you: On Claude's side, it frequently picks the wrong investigation target (wrong table, wrong file, wrong CLI tool) and sometimes burns entire sessions writing plans or exploring instead of executing what you asked for — this is your biggest recurring friction. On your side, many of these wrong-target issues could be prevented by front-loading specifics (exact file, table, environment) in your prompts, and by encoding recurring gotchas (like which Infisical env maps to prod, or which Sentry CLI to use) into your skills files so Claude stops re-learning them. Where Things Go Wrong →

Quick wins to try: Try using hooks to auto-run your local checks on pre-commit — this could catch issues before they hit CI and reduce your all-green iteration cycles. You could also experiment with headless mode to run your Intercom and Sentry daily review skills on a cron schedule, turning those 24+ manual triage sessions into something that runs overnight and surfaces a report when you start your day. Features to Try →

Ambitious workflows: As models get more capable, your Intercom triage workflow is ripe to become a fully autonomous pipeline where parallel agents classify conversations, cross-reference Sentry errors and AWS logs, and draft root-cause replies — not just acknowledgments — with you only reviewing edge cases. Your all-green PR workflow could similarly evolve into parallel agents that simultaneously address different review threads and CI failures independently, collapsing what's currently a sequential back-and-forth into a single pass. On the Horizon →

1,359

Messages

+49,278/-6,091

Lines

768

Files

Days

113.3

Msgs/Day

What You Work On

Product Feature Development (UI/UX) ~30 sessions

Extensive work building and refining product features in a TypeScript/Next.js web application, including splitting Secrets and Environment Variables into separate UI pages, implementing inline environment variable management, feature flag gating with PostHog, settings page improvements (loading skeletons, sidebar navigation), and fixing UX bugs like click targets and redirect issues. Claude Code was used heavily for multi-file code edits, debugging component behavior, creating PRs, and iterating on implementations based on user feedback.

Intercom Support Triage & Tooling ~24 sessions

Building and operating an Intercom-based customer support triage workflow, including daily review skills that pull open conversations, generate structured triage reports, and send approved replies. This also involved setting up Intercom MCP integration, building a custom CLI wrapper when MCP proved read-only, debugging customer-reported issues like devbox failures, and investigating production agent session failures using AWS debug scripts. Claude Code was used for infrastructure debugging, drafting customer replies, and iterating on automation tooling.

Observability & Performance Monitoring ~12 sessions

Setting up and improving observability infrastructure across Sentry and PostHog, including upgrading Sentry, creating PostHog performance dashboards, building a Sentry daily review skill that investigates top issues in parallel and generates actionable reports, diagnosing slow page loads using web vitals data, and analyzing onboarding dropoff metrics. Claude Code was used for data investigation, creating monitoring dashboards, and producing structured diagnostic reports.

Developer Workflow & Skills Automation ~20 sessions

Building and refining Claude Code skills and developer workflow automation, including creating a /check command that runs local agent checks against diffs, an all-green skill for getting PRs merge-ready by addressing review threads and CI failures, migrating CLAUDE.md entries into structured .claude/skills files, creating a docs style guide skill, and improving PR creation workflows. Claude Code was used to implement these meta-tools, iterate on their behavior based on testing, and manage the skills infrastructure.

Backend Integrations & Infrastructure ~17 sessions

Implementing backend integrations and infrastructure improvements including a Ghost blog integration, Slack DM support with app manifest configuration, A/B testing framework across service/types/client layers, WorkOS authentication fixes for preview environments, CLI notify command fixes and v0.0.1 release publishing, error standardization, and staging environment access tooling. Claude Code was used for full-stack implementation across Go, TypeScript, and Rust codebases, debugging auth flows, and managing deployments.

What You Wanted

Intercom Triage

Bug Fix

Code Editing

Feature Implementation

Intercom Conversation Triage

Pr Creation

Top Tools Used

Bash

4187

Read

2476

Edit

1364

Grep

906

Task

434

Write

356

Languages

TypeScript

2584

Markdown

714

243

Rust

172

JavaScript

JSON

Session Types

Single Task

Iterative Refinement

Multi Task

Exploration

Quick Question

How You Use Claude Code

You are a power user who treats Claude Code as an always-on engineering partner, running 291 sessions across just 12 days — averaging over 24 sessions per day with 707 hours of compute time. Your workflow is distinctly delegation-heavy and interrupt-driven: you kick off tasks, monitor progress, and course-correct frequently rather than writing detailed upfront specifications. This is evident in sessions where you iteratively refined sidebar placement ("Claude incorrectly ungated Secrets for all org tiers and placed Secrets before Configuration, requiring two rounds of user correction") and navigation restructuring through ~15 incremental edits. You've built a sophisticated skill and workflow ecosystem — custom `/check` commands, `all-green` PR skills, Intercom daily review automations, and Sentry review workflows — essentially programming Claude Code itself to become a more capable tool. Your top friction point, "wrong_approach" (33 instances), reflects this style: you'd rather let Claude start and redirect than spend time writing perfect prompts.

Your usage spans an impressive breadth: customer support triage, infrastructure debugging, feature implementation, PR management, and observability tooling — all through the same interface. You leverage the Task tool heavily (434 invocations) for parallel agent work, and Bash dominates your tool usage (4,187 calls), suggesting you prefer Claude to execute real commands rather than just generate code. You're comfortable with complex multi-step workflows like "implement Ghost blog integration, get PR merged fixing conflicts and failing checks, add a PR description coverage agent, and create a new PR" — all in a single session. When Claude goes down the wrong path — like spending time writing a debugging plan instead of running AWS debug scripts, or investigating many potential sources of an error instead of asking which page it was on — you interrupt decisively rather than waiting. Your 190 commits across 12 days show you're shipping constantly, and your 77% success rate (fully or mostly achieved) despite the aggressive pace is notable.

What stands out most is how you've meta-engineered your Claude Code experience: creating skills that automate your recurring workflows (Intercom triage, Sentry reviews, PR greenlighting), then iterating on those skills when they fall short. You caught the `all-green` skill failing to surface review comments and immediately asked Claude to fix the skill itself. You're not just using Claude Code — you're continuously improving the system you've built around it, treating it as infrastructure rather than a chat assistant.

Key pattern: You operate Claude Code as a high-throughput delegation engine — launching dozens of sessions daily, interrupting aggressively when approaches go wrong, and continuously building reusable skills and workflows to automate your most frequent tasks.

User Response Time Distribution

2-10s

10-30s

30s-1m

118

1-2m

129

2-5m

137

5-15m

108

>15m

Median: 96.8s • Average: 356.0s

Multi-Clauding (Parallel Sessions)

244

Overlap Events

241

Sessions Involved

48%

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)

175

Afternoon (12-18)

462

Evening (18-24)

701

Night (0-6)

Tool Errors Encountered

Command Failed

386

User Rejected

197

Other

151

File Not Found

File Too Large

Edit Failed

Impressive Things You Did

You're a power user running nearly 300 sessions in under two weeks, building custom skills and automating operational workflows across a full-stack TypeScript/Go/Rust codebase.

Custom Skills as Force Multipliers

You've built an impressive ecosystem of reusable Claude skills — /check for local PR validation, all-green for getting PRs merge-ready, Sentry daily review, and Intercom triage — then iteratively refined them based on real usage. This meta-workflow of teaching Claude how to do your recurring tasks is a sophisticated approach that compounds your productivity over time.

Full-Cycle PR Ownership

You routinely drive features from implementation through PR creation, CI resolution, and review comment fixes in single sessions. Your all-green skill workflow is particularly effective — Claude addresses all review threads, pushes fixes, and confirms CI passes, turning what's normally a multi-hour feedback loop into a streamlined operation that earned 'essential' ratings repeatedly.

Operational Debugging at Scale

You've wired Claude into your production observability stack — PostHog, Sentry, Intercom, and AWS — to investigate customer-facing issues, triage support conversations, and generate structured incident reports. You're effectively using Claude as an on-call assistant that can pull real data, correlate across tools, and draft actionable plans, turning reactive ops work into systematic workflows.

What Helped Most (Claude's Capabilities)

Multi-file Changes

Proactive Help

Good Debugging

Correct Code Edits

Good Explanations

Fast/Accurate Search

Outcomes

Not Achieved

Partially Achieved

Mostly Achieved

Fully Achieved

Where Things Go Wrong

Your most significant friction pattern is Claude taking wrong initial approaches—especially targeting the wrong code, wrong tools, or wrong root causes—which forces multiple correction cycles and wastes time across your high-volume workflow.

Wrong Initial Investigation Target

Claude frequently starts debugging or implementing against the wrong table, wrong file, wrong tool, or wrong root cause, requiring you to course-correct after wasted exploration. You could reduce this by front-loading more specific context in your prompts—naming the exact file, table, or component—since Claude tends to guess wrong when given ambiguous targets.

Claude targeted the wrong database table (agent instead of workflow) and got the relationship backwards, requiring multiple attempts before finding the correct row to update
Claude investigated many potential sources of an undefined href error across the codebase instead of first asking you which page the error was on, which would have immediately narrowed the search

Planning and Exploring Instead of Executing

Claude sometimes spends entire sessions writing investigation plans, exploring codebases, or drafting documents instead of actually running the commands or writing the code you asked for, leading to interrupted sessions with no concrete output. Consider being more directive early on (e.g., 'run the debug scripts now, don't write a plan') to prevent Claude from defaulting to analysis mode.

You asked Claude to use AWS debug scripts to investigate a production failure, but Claude spent the session writing a debugging plan document instead of running the actual commands, and you had to interrupt
You asked Claude to fix two UX bugs, but it spent all available time investigating and planning without writing any fixes, resulting in a not_achieved outcome

Incorrect Tool or Configuration Assumptions

Claude repeatedly assumes wrong tool versions, wrong CLI commands, wrong environment configurations, or wrong access patterns, forcing you to step in with corrections. Building these specifics into your skills or CLAUDE.md (e.g., which CLI to use, which env source method, which Infisical environment maps to prod) would prevent these recurring mistakes.

Claude used the older `sentry-cli` instead of the newer `sentry` CLI and proposed a non-existent Terraform parameter (exclude_gitignore), both requiring your manual correction
Claude misidentified the Infisical environment for prod credentials and defaulted to `infisical run` for every command instead of simply sourcing the .env file, requiring you to redirect to a simpler approach

Primary Friction Types

Wrong Approach

Buggy Code

Misunderstood Request

User Rejected Action

Browser Automation Issues

Api Error

Inferred Satisfaction (model-estimated)

Frustrated

Dissatisfied

Likely Satisfied

115

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 debugging issues, ALWAYS ask the user which specific page/route/component is affected before exploring the entire codebase. Narrow scope first, then investigate.

Multiple sessions show Claude spending excessive time exploring broadly when a single clarifying question would have pinpointed the issue (e.g., undefined href investigation, billing page Sentry error, UX bug sessions).

When asked to investigate or debug a production issue, execute the actual debug commands immediately. Do NOT write a plan document or investigation summary first — act, then report findings.

Multiple sessions show Claude writing plans/documents instead of executing debug scripts (AWS debug scripts session, Sentry investigation, UX bug fix session where no code was written), leading to user interruptions and not_achieved outcomes.

For Infisical/environment credentials: Production uses the 'prod' environment. Use `source .env` or the `with-env.sh` wrapper script rather than `infisical run` for every command.

Claude repeatedly got the Infisical environment wrong and used verbose `infisical run` invocations until corrected by the user in multiple sessions.

When creating PRs or making git changes: always create a fresh branch from main. Never reuse branches from previously merged PRs. Run `git fetch origin && git checkout -b <new-branch> origin/main` for clean starts.

Multiple sessions had git branch management friction — reusing old merged PR branches, merge conflicts from stale branches, and extra cleanup work.

This project uses the newer `sentry` CLI, NOT `sentry-cli`. PostHog is used for feature flags and analytics. When working with feature flags, check both the PostHog dashboard AND the actual component code — flags may be overridden by hardcoded email checks.

Claude used the wrong Sentry CLI tool and missed hardcoded email gating overriding feature flags in separate sessions, requiring user correction each time.

When running the all-green or PR review skill, ALWAYS check for and resolve ALL code review comment threads — not just CI checks. A PR is not merge-ready until both CI passes AND all review threads are addressed.

The all-green skill missed review comments in at least two sessions, requiring the user to point out the oversight and request fixes.

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

Hooks

Auto-run shell commands at specific lifecycle events like pre-commit or post-edit.

Why for you: With 190 commits across 291 sessions and friction around merge conflicts, stale branches, and forgotten review threads, a pre-push hook could auto-run your /check skill and verify branch freshness. Your 'wrong_approach' friction (33 instances) often involved skipping validation steps.

// .claude/settings.json
{
  "hooks": {
    "preCommit": "bash -c 'git diff --check && npx tsc --noEmit'",
    "postEdit": "bash -c 'if echo $CLAUDE_EDITED_FILES | grep -q \\.tsx; then npx tsc --noEmit --pretty 2>&1 | head -20; fi'"
  }
}

Custom Skills

Reusable prompts as markdown files triggered with /command.

Why for you: You already use skills heavily (/check, /all-green, Intercom daily review, Sentry review) but your top friction is 'wrong_approach' (33x). Create a /debug skill that enforces 'ask scope first, execute commands, then report' to prevent the planning-without-acting pattern seen in multiple sessions.

# .claude/skills/debug/SKILL.md
## Debug Skill
1. FIRST ask the user: which page/route/component/service is affected?
2. THEN execute actual debug commands (AWS scripts, logs, Sentry queries) — do NOT write a plan document
3. After gathering data, report findings in this format:
   - **Root Cause**: one sentence
   - **Evidence**: commands run and key output
   - **Fix**: proposed change with file paths
   - **Prevention**: optional suggestion to prevent recurrence

Headless Mode

Run Claude non-interactively from scripts and CI/CD pipelines.

Why for you: You have 24 Intercom triage sessions (your #1 goal) that follow the same pattern — pull conversations, triage, draft replies. Running this headlessly on a schedule would save you from manually triggering it daily. Your Sentry daily review is another prime candidate.

# Daily Intercom triage (add to cron or CI)
claude -p "Run the Intercom daily review skill. Pull open conversations, triage by priority, draft replies for urgent items. Output a structured report." --allowedTools "Bash,Read,Grep,mcp__intercom" > ~/triage-$(date +%F).md

# Daily Sentry review
claude -p "Run the Sentry daily review. Compare today vs yesterday, investigate top 3 new issues, output actionable report." --allowedTools "Bash,Read,Grep" > ~/sentry-$(date +%F).md

New Ways to Use Claude Code

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

Reduce 'wrong approach' friction with scope-first prompting

Your #1 friction type (33 occurrences) is 'wrong_approach' — Claude targeting wrong tables, wrong files, wrong tools, or over-exploring before acting.

Across your sessions, Claude frequently investigated broadly before narrowing (undefined href across entire codebase, wrong DB table, wrong Terraform parameter, wrong CLI tool). In almost every case, a single clarifying detail upfront would have saved 5-10 minutes. Start debug/investigation prompts with the specific scope: file, route, error message, or component name. This small change would likely eliminate half your wrong_approach friction.

Paste into Claude Code:

Debug this error: [paste error]. It happens on the [specific page/route]. The relevant component is likely in [directory]. Run the actual debug commands first, then report what you find.

Batch your Intercom + Sentry daily reviews

Your top two goals (intercom_triage: 24 sessions, combined with Sentry reviews) account for ~30% of all analyzed sessions and follow near-identical patterns each time.

You've built great skills for these workflows, but you're still manually triggering them and sometimes sessions get interrupted mid-report. Consider combining them into a single morning briefing skill that runs both sequentially, or better yet, run them headlessly overnight so you start each day with reports ready. The Intercom MCP is read-only but your CLI wrapper handles writes — this pipeline is mature enough to automate.

Paste into Claude Code:

Create a new skill at .claude/skills/morning-briefing/SKILL.md that runs the Intercom daily review first, then the Sentry daily review, and outputs a combined report with sections: 1) Urgent Intercom items needing replies, 2) New Sentry issues trending up, 3) Suggested actions for today.

Leverage Task agents more for parallel PR workflows

You already use Task agents heavily (434 Task calls + 175 TaskUpdates) but your multi-step PR workflows (implement → create PR → fix CI → resolve reviews) still hit sequential friction.

Your most successful sessions (rated 'essential') are PR-focused: implement changes, create PR, get all-green, address reviews. But friction often comes from sequential steps failing (API errors blocking commits, review threads missed, CI checks not rechecked). Explicitly ask Claude to spawn parallel agents: one to address review comments while another monitors CI status. Your all-green skill would benefit from this split — one agent per review thread plus one watching CI.

Paste into Claude Code:

Get PR #XXXX merge-ready. Use separate agents to: 1) address each unresolved review thread in parallel, 2) monitor CI checks and fix any failures. After all agents complete, verify the PR is fully green with all threads resolved before reporting back.

On the Horizon

Your team is already leveraging AI agents for triage, PR workflows, and debugging at impressive scale — the next frontier is fully autonomous pipelines that run end-to-end without human intervention.

Autonomous Intercom Triage and Response Pipeline

With 24 sessions dedicated to Intercom triage already, you can evolve from semi-manual daily reviews to a fully autonomous pipeline where parallel agents classify conversations, draft context-aware replies using your codebase and runbooks, and escalate only edge cases. Agents could cross-reference Sentry errors, PostHog analytics, and AWS logs in parallel to provide customers with root-cause answers — not just acknowledgments — within minutes of a new ticket arriving.

Getting started: Combine your existing Intercom MCP and custom CLI wrapper with a Task-based orchestrator that spawns sub-agents for investigation, drafting, and review. Use your /check skill pattern to validate reply quality before sending.

Paste into Claude Code:

Build an autonomous Intercom triage pipeline as a Claude Code skill. When triggered, it should: 1) Pull all open Intercom conversations from the last 24 hours via our CLI wrapper, 2) Spawn parallel Task sub-agents for each conversation — one to classify severity/category, one to search our codebase and docs for relevant context, and one to check Sentry and PostHog for related errors or user activity, 3) Draft a reply for each conversation that references specific findings, 4) Run a self-review pass checking tone, accuracy, and whether the reply actually addresses the customer's question, 5) Present a structured report grouping conversations by severity with draft replies for approval, and auto-send replies rated high-confidence. Flag any conversation where the agent confidence is below 80% for human review with a summary of what was found.

Self-Healing PR Pipeline With Parallel Agents

Your data shows 33 'wrong approach' friction events and significant time spent on the all-green → review → fix → push cycle. Instead of a single agent iterating sequentially, you can run parallel agents that simultaneously address different review threads, run type checks, lint, and tests independently, then merge their fixes. The pipeline would autonomously retry on CI failures, bisect breaking changes, and only ping you when a genuinely ambiguous design decision is needed.

Getting started: Extend your existing all-green skill to use Task sub-agents — one per review thread and one monitoring CI status. Combine with a test-iteration loop that runs 'npm test' or 'go test' after each change and self-corrects until green.

Paste into Claude Code:

Upgrade our /all-green skill to use parallel autonomous agents. The new workflow should: 1) Read all open review threads on the PR and group them by file/concern, 2) Spawn a separate Task sub-agent for each review thread — each agent should read the relevant code, understand the reviewer's intent, implement the fix, and write a brief explanation, 3) Simultaneously spawn a CI-monitor agent that watches for check results and, on any failure, reads the logs, identifies the root cause, and applies a fix, 4) After all sub-agents complete, run the full test suite locally and iterate up to 3 times if tests fail — each iteration should read the failure output, diagnose, fix, and re-run, 5) Once all tests pass, push the changes, resolve each review thread with a comment explaining what was changed and why, 6) If any review thread requires a design decision (not just a code fix), flag it in a summary instead of guessing. Output a final report showing: threads resolved, CI status, test results, and any items needing human input.

Proactive Observability Agent Running Continuously

You're already running Sentry daily reviews and PostHog investigations — but these are reactive and session-based. An autonomous observability agent could run on a schedule, correlate Sentry error spikes with deployment timestamps and PostHog funnel drops, automatically open investigation PRs with instrumentation or fixes for top issues, and maintain a living dashboard of system health trends. It could have caught your 65% onboarding dropoff weeks earlier by detecting the funnel regression the day it appeared.

Getting started: Chain your Sentry review skill, PostHog queries, and git log analysis into a scheduled workflow that runs daily. Use Task sub-agents to investigate each anomaly in parallel and output structured markdown reports committed to your repo.

Paste into Claude Code:

Create an autonomous daily observability agent as a Claude Code skill called /observability-sweep. It should: 1) Query Sentry for the top 10 issues by frequency and any new issues in the last 24 hours, comparing error rates to the 7-day baseline, 2) Query PostHog for web vitals regressions, funnel conversion drops >5%, and any feature flag experiments with statistically significant results, 3) Run 'git log --since=yesterday' to correlate any error spikes with recent deployments, 4) For each anomaly found, spawn a Task sub-agent that: investigates the relevant code paths, checks if there's already an open issue or PR addressing it, and drafts either a fix PR or a detailed investigation document, 5) Generate a structured daily report in markdown with sections: Critical (needs immediate action), Trending (getting worse), Improved (getting better), and Investigations (opened today), 6) If any critical Sentry issue has a clear code fix (e.g., null check, missing error boundary, unhandled promise), auto-create a PR with the fix and tests. Commit the report to docs/observability/ with today's date and open a summary PR if any fixes were generated.

"Claude asked why it ran out of context — but couldn't answer because it had run out of context"

In a perfectly ironic moment, a user asked Claude to explain why their session ran out of context, but the prompt was already too long for Claude to respond, and even the automatic compaction process failed. A digital ouroboros of confusion.