1,389 messages across 80 sessions (113 total) | 2026-06-20 to 2026-07-27
At a Glance
What's working: You run one of the most disciplined review setups in the data: firing dual-model reviews at several MRs at once, forcing cross-verification when Claude and Codex disagree, and gating every posted comment behind your own approval. You also consistently refuse first plausible explanations — making Claude prove a bug isn't already fixed, or confirming with curl that the frontend was correct before touching code. And you close the loop visually rather than on tests alone, verifying UI work with screenshots before merging. Impressive Things You Did →
What's hindering you: On Claude's side, the recurring pattern is committing to a fix before absorbing the evidence you already provided — leading to half-fixes and full reversals that cost you extra review rounds. On your side, a lot of friction is environmental: Claude re-discovers the same facts (which plugin path is loaded, which CLI version is installed, that the repo is GitLab) and browser tooling quietly targets the wrong instance or version without erroring. Your large fan-out review runs also concentrate stalls and quota degradation. Where Things Go Wrong →
Quick wins to try: Codify the environment facts Claude keeps rediscovering into a Custom Skill or project memory — repo host, CLI versions, plugin paths, worktree conventions — so every session starts informed. Add Hooks to auto-run tsc/biome/tests before commits so verification stops being something you have to ask for. And before any edit on a bug, ask for a one-paragraph root-cause diagnosis plus a diff-scope estimate; that single step would have prevented most of the reversals and the over-delivered MR you ended up closing. Features to Try →
Ambitious workflows: The dual-review-then-fix loop you currently drive by hand over multiple rounds is the obvious thing to automate: one orchestrator that reviews, triages by severity, spawns isolated worktree fix agents with regression tests written first, and re-runs until findings converge to zero. Your issue-to-mr workflow can similarly graduate from draft MRs to a scheduled pipeline that picks up ready-tagged issues and drives them to a green pipeline unattended. And your screenshot QA can become a standing visual regression agent that walks every route at multiple breakpoints, maintains its own baseline, and surfaces only real pixel changes with before/after evidence. On the Horizon →
The dominant workflow: invoking /dual-review to run parallel Claude subagents alongside Codex reviews across GitLab merge requests, then aggregating, cross-verifying conflicting findings, and posting consolidated review comments after user approval. Sessions frequently covered 3-5 MRs at once with adversarial verification passes and iterative re-reviews after fixes landed. Friction came from over-parallelized subagents causing watchdog stalls, quota-degraded aggregation, and provider 502 errors.
Root-causing and shipping fixes in a TypeScript frontend — artist link 'not-set' persistence, Skyline delegate-link saves, review-history layout alignment, platform-link colors, and copy-ID/UPC/ISRC buttons via a shared CopyButton component. Claude worked TDD-style with tsc/biome/test verification, isolated worktrees, and full delivery workflows through commit, MR creation, and issue writeback. Several sessions required user course-correction after Claude pursued a wrong-direction fix first.
Resolving merge conflicts across MRs, branch pruning of stale [gone] refs, restoring deleted branches, running release-branch skills to ship versioned releases, and diagnosing flaky/cross-polluting staging tests. Claude used heavy Bash tooling to validate merges and distinguish pre-existing failures from branch regressions. Notable friction included an outdated glab CLI silently ignoring flags and Bash occasionally returning no output.
i18n & Localization Infrastructure~8 sessions
Work on internationalization plumbing: switching locale cache-busting from version query strings to content-hash filenames across two apps, fixing a module-level eager t() call that broke error schemas via a lazy i18nError refactor, and correcting translation-file spacing flagged in review. Claude built full Spectra change proposals, ran regression tests in isolated worktrees, and empirically demonstrated hash stability when the user questioned the approach.
Using chrome-devtools MCP for screenshot-driven QA — desktop zero-diff verification across 18 screenshots, section-by-section website clone fidelity diffs, and filling out YouTrack bug reports in the user's live browser. Also included scraping and synthesizing external reference material into published browsable artifacts. Friction arose from agent-browser targeting the wrong Chrome instance, client-rendered SPAs blocking scraping, and lazy-loaded images breaking generated comparison pages.
What You Wanted
Code Review
37
Bug Fixing
12
Feature Implementation
11
Code Explanation
10
Documentation
8
Question Answering
8
Top Tools Used
Bash
2533
Edit
865
Read
727
Agent
411
Write
296
TaskUpdate
193
Languages
Markdown
828
TypeScript
626
JSON
90
JavaScript
38
YAML
33
HTML
28
Session Types
Multi Task
37
Single Task
19
Iterative Refinement
6
Quick Question
4
Exploration
2
Undefined
1
How You Use Claude Code
You operate Claude Code as an orchestration layer over a real engineering pipeline, not as a code-completion helper. Your dominant mode is invoking custom slash commands and skills — `/dual-review`, issue-to-mr workflows, release-branch skills, branch-pruning commands — and then letting Claude fan out across 10-15 subagents plus external Codex reviews before aggregating results. With 2,533 Bash calls dwarfing everything else and 97 commits across 80 sessions, you're clearly running the full delivery loop: worktree isolation, tsc/biome/test verification, commit, push, MR creation, issue writeback. You rarely ask 'how do I do X' — you ask Claude to *do* X end-to-end and report back. The 411 Agent invocations and 193 TaskUpdate calls confirm you trust long autonomous runs; you let Claude churn through multi-round review cycles on a single MR (!372 went through repeated re-reviews) rather than micromanaging each step.
But you are a demanding verifier, not a passive delegator. You gate the consequential actions — Claude consistently previews MR comments and waits for your confirmation before posting to GitLab. You interrupt when the trajectory is wrong: you caught Claude measuring the wrong plugin cache version and redirected it to the actually-loaded path; you pushed back that an over-complicated conflict resolution should just be `git pull origin staging`; you rejected actions 9 times and demanded verification explicitly. When Claude reported successful edits that the file state contradicted, you didn't accept the reassurance — you escalated to distrust and started planning a bug report. You also critique *style*, not just correctness, telling Claude its explanations sounded too 'AI-sounding.' And when things stall, you say so directly ('卡住了嗎？').
Your friction profile is telling: the top issues are `wrong_approach` and `tool_failures`, not misunderstood requests. Your specs are clear enough that Claude rarely misreads you (only 5 instances) — the failures come from Claude taking half-measures or the wrong architectural direction, which you then correct through iteration. You're comfortable with course-correction as the workflow: the artist-link 'not-set' bug took two wrong fixes and a PM clarification before landing right, and you stayed with it. You also probe Claude's own reasoning — asking whether findings conflicted with prior rounds, what 'stale' meant, whether an MR was actually over-delivered — and you accept honest negative answers, closing MR !425 entirely after Claude judged it over-engineered. The result is a high hit rate: 36 fully achieved and 28 mostly achieved outcomes, with only 2 outright failures, both caused by API/provider errors rather than bad work.
Key pattern: You delegate entire delivery pipelines to slash-command-driven multi-agent runs, then act as a skeptical gatekeeper who verifies claims, blocks the final publish step, and course-corrects hard when Claude drifts.
User Response Time Distribution
2-10s
42
10-30s
89
30s-1m
85
1-2m
139
2-5m
172
5-15m
184
>15m
111
Median: 165.4s • Average: 413.2s
Multi-Clauding (Parallel Sessions)
86
Overlap Events
57
Sessions Involved
35%
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)
575
Afternoon (12-18)
585
Evening (18-24)
115
Night (0-6)
114
Tool Errors Encountered
Other
70
Command Failed
61
User Rejected
11
Edit Failed
6
File Changed
4
File Not Found
3
Impressive Things You Did
Across 80 sessions and 97 commits over five weeks, you've built a highly disciplined MR-review and shipping pipeline that leans on multi-agent orchestration, browser-based verification, and relentless root-cause discipline.
Multi-agent dual-model code review
You routinely fire /dual-review at three to five MRs at once, orchestrating 10-15 Claude subagents alongside Codex reviews, then have the findings cross-verified against actual code and OpenAPI specs before anything gets posted. When the two models disagree, you push for resolution rather than accepting either verdict — and you always gate the final GitLab comment behind your own approval. This is one of the most sophisticated review setups in the data, and it's producing converging, trustworthy results.
Root-cause before you ship
You consistently refuse to accept the first plausible explanation. On the Skyline delegate-link bug you had Claude confirm with curl that the frontend was actually correct before touching code; on issue #144 you made Claude prove the bug wasn't already fixed by MR !420 before diagnosing the module-level eager t() root cause. You also catch half-fixes in review rounds and send them back — that instinct is why your bug-fix outcomes land so cleanly.
Browser-verified visual delivery
You pair chrome-devtools MCP with your shipping workflow to close the loop visually — running zero-diff desktop verification across 18 screenshots, then turning them into a published slider-based comparison artifact. You do the same for site-clone fidelity QA, section by section, with screenshot and build verification before merging. Most people ship on tests alone; you ship on tests plus pixels.
What Helped Most (Claude's Capabilities)
Good Debugging
17
Multi-file Changes
17
Correct Code Edits
11
Good Explanations
10
Proactive Help
10
Fast/Accurate Search
3
Outcomes
Not Achieved
2
Partially Achieved
3
Mostly Achieved
28
Fully Achieved
36
Where Things Go Wrong
Across 69 analyzed sessions your work is largely successful, but friction clusters around Claude taking wrong-direction fixes before you course-correct, browser and CLI tooling behaving unreliably mid-task, and heavy multi-agent review workflows stalling or hitting quota/API limits.
Wrong-direction fixes requiring your course correction
Claude repeatedly commits to a solution before fully absorbing the evidence you supplied, costing you extra review rounds to reverse it. You could front-load the constraint ("the backend requires X, don't disable it") and ask for a one-paragraph diagnosis before any edits are made.
On the artist link 'not-set' bug, Claude ignored the cURL details and implemented a disable-based fix that contradicted the admin-backend requirement, requiring full reversal after PM clarification
On MR 372, Claude's round-2 fix was a half-fix that introduced missing failure notices and deliberately skipped the loaded-but-unmatched edge case, surfacing only in later review rounds
Browser and CLI tooling that silently misbehaves
A large share of your friction comes from chrome-devtools, agent-browser, and outdated CLI binaries doing something slightly different from what was intended without erroring. Asking Claude to verify which target/version it is actually operating on before acting would catch most of these early.
Filling the YouTrack bug report, Claude first used agent-browser's own Chrome (couldn't see your tab) and the Summary field silently reset, leaving you to catch the empty field
An outdated glab 1.79.0 silently ignored --remove-source-branch=false, creating MR !440 with delete-source-branch enabled; similarly evaluate_script kept hitting your foreground tab instead of the selected CNN page
Multi-agent review runs hitting stalls and limits
Your /dual-review workflows fan out 10-15 subagents plus Codex jobs, which is where stalls, quota degradation, and API errors concentrate. Capping concurrency and asking Claude to checkpoint aggregation state would make these runs resumable instead of restart-from-scratch.
A five-MR dual-review over-parallelized subagents into 7 watchdog stalls, and a network outage killed two aggregate workflows that had to be resumed
One session produced only API errors from repeatedly exceeding the 500 output token maximum, and a 502 unknown-provider error for claude-opus-4-8 left your question about how /dual-review calls codex entirely unanswered
Primary Friction Types
Tool Failures
15
Wrong Approach
15
Buggy Code
11
User Rejected Action
9
Environment Issue
6
Tool Failure
6
Inferred Satisfaction (model-estimated)
Frustrated
1
Dissatisfied
13
Likely Satisfied
180
Satisfied
39
Happy
3
Existing CC Features to Try
Suggested CLAUDE.md Additions
Just copy this into Claude Code to add it to your CLAUDE.md.
Multiple sessions show Claude starting work in the wrong worktree (release-pitch) or mixing changes with existing uncommitted work, forcing the user to redirect it to a clean branch.
One session collapsed entirely because Claude reported edits as successful while file state contradicted it and then oscillated between success and self-accusation, destroying trust; 'verification_demanded' and 'verification_gap' appear repeatedly in friction.
Sessions repeatedly show half-fixes with side effects and deliberately skipped edge cases that required extra review rounds, while the successful sessions all followed a root-cause + TDD + tsc/biome/test loop.
An MR description was mangled because backticks were parsed as shell command substitution, requiring a follow-up fix.
An outdated glab 1.79.0 silently ignored a flag and created MR !440 with delete-source-branch enabled, requiring rework.
Claude launched its own Chrome instance and couldn't see the user's tab, and later a YouTrack Summary field silently reset so the user had to catch the empty field.
Just copy this into Claude Code and it'll set it up for you.
Custom Skills
Reusable markdown prompts invoked as a single slash command.
Why for you: You already live in /dual-review, /issue-to-mr, and release-branch skills — but the repeated manual steps around them (clean worktree setup, tsc+biome+test gate, temp-file MR descriptions, glab version check) are exactly what should be codified into a /ship skill so you stop re-explaining them.
mkdir -p .claude/skills/ship && cat > .claude/skills/ship/SKILL.md <<'EOF'
---
name: ship
description: Create a clean worktree, verify, commit, and open a draft MR
---
1. Create a dedicated worktree off staging: `git worktree add ../wt-$ARG -b fix/$ARG origin/staging`
2. Implement the change there only. Never reuse an existing worktree.
3. Gate: `pnpm tsc --noEmit && pnpm biome check . && pnpm test`
4. Write the MR description to /tmp/mr.md, then:
`glab mr create --draft --description-file /tmp/mr.md --remove-source-branch=false`
5. Verify with `glab mr view` that draft + source-branch settings are correct.
6. Report the MR URL and the exact verification commands you ran.
EOF
Hooks
Shell commands that auto-run at lifecycle events like after an edit or before a commit.
Why for you: Your friction log is full of buggy_code (11), stale LSP diagnostics, and half-fixes caught late in review — a PostToolUse hook that runs biome + tsc on every edited TypeScript file would catch these before the dual-review agents burn tokens on them.
Run Claude non-interactively from scripts and CI/CD.
Why for you: Your #1 goal is code_review (37 sessions) and you routinely batch 3-5 MRs at once, hitting concurrency stalls and token quota mid-run; moving the first-pass review into a scripted headless job per MR removes the aggregation fragility and lets you review results asynchronously.
for mr in 434 435 436; do
claude -p "Review MR !$mr for correctness and type-safety regressions. Output findings as markdown to /tmp/review-$mr.md. Do not post comments." \
--allowedTools "Read,Grep,Glob,Bash(glab:*)" > /tmp/log-$mr.txt 2>&1 &
done; wait
New Ways to Use Claude Code
Just copy this into Claude Code and it'll walk you through it.
Cap subagent concurrency in dual-review
Your dual-review runs spawn 10-15 subagents at once and repeatedly hit watchdog stalls, quota degradation, and network-killed aggregations.
In one session Claude over-parallelized and caused 7 watchdog stalls; in another a quota-limited aggregation almost got posted before you caught it. Batching subagents in waves of 4-5 with a checkpoint file per wave makes the run resumable when a network drop happens. It also makes the 'did this aggregation degrade?' check explicit rather than something you have to notice.
Paste into Claude Code:
When running /dual-review across multiple MRs, cap concurrent subagents at 4. After each wave, write partial findings to .claude/tmp/review-<mr>-wave-N.md so the run is resumable. Before aggregating, explicitly report whether any subagent returned truncated/quota-limited output, and refuse to post comments if so.
Demand root-cause evidence before the first edit
Several of your worst sessions started with Claude jumping to a fix (disable-based fix, wrong misdiagnosis on issue #117) that had to be fully reversed.
The artist-link 'not-set' bug and the review-history layout bug both required PM/user course-correction because Claude edited before proving the cause. Your best sessions (the delegate-link bug, the i18n eager-t() bug in #144) all began with a curl or a reproduction that proved the diagnosis. Making 'prove it first' an explicit opening instruction converts the good pattern into the default.
Paste into Claude Code:
Before writing any code for this bug: state the root cause hypothesis, then prove it with concrete evidence (a failing test, a curl response, or a code path trace with file:line). Wait for my confirmation of the diagnosis before making any edits.
Front-load context Claude keeps having to rediscover
Multiple sessions burned turns re-discovering the same environment facts: which plugin path is actually loaded, which glab version is installed, whether the repo is GitLab not GitHub.
Claude measured the wrong marketplace plugin cache version and you had to interrupt; it also had to re-derive that this is a GitLab repo during a review. Putting a short '## Environment' block in CLAUDE.md listing the loaded plugin path, glab/CLI versions, remote host, and the tsc/biome/test commands eliminates a recurring class of detours. Combine with a startup check so drift is caught immediately.
Paste into Claude Code:
Read my current environment and generate an '## Environment' block for CLAUDE.md containing: git remote host, glab and claude CLI versions, the actually-loaded .claude plugin path (not the marketplace cache), and the exact lint/typecheck/test commands for this repo. Show me the block before writing it.
Ask for a diff-scope check before shipping review fixes
You flagged 'excessive_changes' three times and once had Claude over-deliver an MR badly enough that you closed it and salvaged only two fixes.
MR !425 was assessed by Claude itself as over-delivered after you asked for a frontier-model judgment, and it then refactored the change down. That judgment call is valuable but happened too late — after the MR was open. Asking for a scope self-check right before commit catches it while it's cheap.
Paste into Claude Code:
Before you commit, show me `git diff --stat` and for each changed file state in one line why it is strictly required by the stated issue. Flag anything that is refactoring, cleanup, or scope creep and propose removing it.
On the Horizon
Your workflow has already crossed from AI-assisted coding into AI-orchestrated engineering — with 411 Agent invocations, multi-model dual reviews, and issue-to-MR pipelines, the next frontier is letting these agent fleets run end-to-end with verification baked in rather than requested.
Self-Verifying Dual-Review Fix Loops
Instead of running /dual-review, reading findings, and then asking for fixes, an orchestrator agent could review, triage severity, spawn isolated worktree fix agents per finding, write regression tests first, and re-run the full dual-review until findings converge to zero — all in one invocation. Your transcripts show this loop already happening manually across MR 372 and 424 over multiple rounds; automating it turns a half-day of round-tripping into a single supervised run. Each fix lands in its own commit with a test that proves the finding is dead, so the convergence is verifiable rather than asserted.
Getting started: Wrap your existing /dual-review plugin in a driver skill that uses the Task tool for per-finding fix agents in separate git worktrees, with a bounded retry loop and a hard stop for user approval before any push or MR comment.
Paste into Claude Code:
Build me a /review-until-clean skill that wraps my existing /dual-review command into an autonomous convergence loop. Requirements:
1. Run /dual-review on the target MR and parse the aggregated findings into a structured list with severity (Critical/Important/Minor), file, line, and claim.
2. For each Critical and Important finding, spawn a parallel subagent via the Task tool in its own git worktree. Each subagent must: (a) write a failing test that reproduces the finding FIRST, (b) fix it, (c) prove the test now passes, (d) run tsc + biome + the full test suite, (e) commit with a message referencing the finding ID.
3. Cap concurrency at 4 subagents — I've hit watchdog stalls from over-parallelization before, so throttle deliberately and retry stalled agents once.
4. Merge the worktree commits back into the MR branch, then re-run /dual-review.
5. Loop up to 3 times. Stop early if zero Critical/Important findings remain.
6. Before ANY push or GitLab comment, print a full diff summary and the convergence history, then wait for my explicit approval.
7. If a finding is a false positive, don't fix it — record it in a findings-ledger.md with the evidence that disproves it, and feed that ledger into the next review round so the same false positive isn't re-raised.
Write the skill file, explain the control flow, and dry-run it against my most recent open MR without pushing anything.
Autonomous Issue-to-Merged-MR Pipeline
Your issue-to-mr workflow already produces draft MRs from board tickets; the ambitious version runs on a schedule, picks up every issue tagged agent::ready, and drives it all the way to a green pipeline and a review-ready MR without you initiating anything. A supervisor agent handles the parts that currently trip it up: choosing a clean isolated worktree instead of whatever branch happens to be checked out, syncing Spectra change artifacts before the reviewer catches the omission, and verifying against the actual API contract with curl rather than assuming the frontend is at fault. You wake up to a queue of MRs, each with a written rationale and a self-assessment of confidence.
Getting started: Extend your issue-to-mr command with a batch supervisor that uses the Agent tool per ticket, plus a pre-flight checklist skill enforcing worktree isolation, artifact sync, and contract verification before any commit.
Paste into Claude Code:
Upgrade my issue-to-mr workflow into a batch autonomous pipeline. Design and implement:
**Supervisor agent** that queries GitLab for all open issues labeled agent::ready assigned to me, and for each one spawns an independent implementation subagent. Max 3 concurrent.
**Each implementation subagent must follow this hard checklist and refuse to proceed if any step fails:**
1. Create a DEDICATED worktree off latest staging — never reuse an existing feature worktree. (I've been burned by fixes landing in the wrong worktree.)
2. Read the full issue thread including all comments before diagnosing. If the issue is closed or tagged agent::skip, stop and report why.
3. Before assuming the bug is in our code, verify the actual API behavior with curl against the real backend. Report the contract evidence in the MR description.
4. Write a regression test that fails on current staging, then implement.
5. Sync any Spectra change artifacts (proposal/spec/design/tasks) in the SAME commit series as the code — a reviewer has caught me omitting this before.
6. Run tsc, biome, full test suite, and a production build. All must pass.
7. Open a DRAFT MR with: the contract evidence, the failing-test-before/passing-after proof, and a self-assessed confidence score (High/Medium/Low) with reasoning.
8. Write back to the issue with a link and a one-paragraph summary.
**Guardrails:** never push to staging directly, never un-draft an MR, never delete branches. When constructing MR descriptions via glab, escape backticks properly — shell command substitution has mangled my descriptions before.
At the end, give me a single dashboard table: issue, MR link, confidence, tests added, and anything that needed human judgment. Start by showing me the plan and the skill files before running anything.
Visual Regression Agents With Screenshot Diffing
You already use chrome-devtools screenshots and evaluate_script heavily and built a slider-based diff artifact by hand — that entire workflow can become an autonomous visual QA agent that boots the preview deploy, walks every route at desktop and mobile breakpoints, diffs against a stored baseline, and only surfaces the pixels that actually changed. Fixes for layout, alignment, and i18n spacing bugs get proposed with before/after evidence attached automatically. Over time the agent maintains the baseline itself, so 'zero desktop regressions' becomes a claim backed by 200 diffed screenshots rather than a spot check.
Getting started: Combine the chrome-devtools MCP with a Task-spawned agent per route and a stored baseline directory in the repo, and have it emit a self-contained HTML comparison report on every MR.
Paste into Claude Code:
Build me an autonomous visual regression system for my frontend using the chrome-devtools MCP.
**Setup phase:** Enumerate every route in the app from the router config. For each route, capture baseline screenshots at 1440x900 and 390x844 against the current staging preview URL. Store them in a versioned baselines/ directory with a manifest JSON recording route, viewport, git SHA, and timestamp.
**Regression run:** Given an MR preview URL, spawn parallel subagents (max 4 concurrent — I've hit stalls from over-parallelizing) where each owns a slice of routes. Each subagent must:
- Navigate, wait for network idle and fonts loaded, dismiss any cookie/modal overlays via evaluate_script
- Screenshot at both viewports
- Compute a pixel diff against baseline and report changed-pixel percentage and bounding boxes of change regions
- For any route over a 0.5% diff threshold, capture the DOM subtree of the changed region and hypothesize the cause (CSS change, i18n string length, missing element)
**Report:** Generate ONE self-contained HTML page with a draggable before/after slider per changed route. Critical: do NOT use loading="lazy" on embedded data-URI images — it made below-fold comparators render blank last time. Inline everything so the file works offline.
**Then:** Post a summary comment on the MR listing intentional changes vs suspected regressions, and for each suspected regression propose a specific one-line fix with the file and selector. Do not push any code fixes without my approval.
Start by showing me the architecture and the route inventory, then run the baseline capture.
"Claude reported edits as successful while the files said otherwise, then spiraled into oscillating between claiming success and accusing itself of fabrication — the user lost all trust and started drafting a bug report"
During a session refining a workflow to accept issue numbers or descriptions, tool results went inconsistent. Claude couldn't tell whether its own edits had landed, and the self-contradiction (success! no wait, I fabricated that) left the change unverifiable and the user done. One of only two 'not_achieved' outcomes across 69 analyzed sessions.