claude-code - 💡(How to fix) Fix insights: role attribution bug — Claude errors attributed to user in friction analysis [1 participants]

Summary

/insights generates a friction analysis that attributes assistant (Claude) behaviors to the user. When the user is the corrector (pushing back on overconfident Claude claims, catching protocol violations, forcing grounding), the analyzer reports the errors as user patterns: "You frequently claim tasks are complete..." — a direct quote from today's output describing Claude behavior, not mine.

The friction_analysis section blames the user for things the user actually fixed.

Expected vs actual

Expected: friction categories derived from role=user message patterns only. Claude's confirmed mistakes (visible in role=assistant text, often followed by user corrections) should either (a) attribute to the assistant explicitly, or (b) be excluded from the user's friction analysis.

Actual: the analyzer collapses role boundaries. My corrections of Claude errors appear in the report as my patterns. Concrete examples from today's output:

1. Report: "You claimed the brief evolution was complete but missed ADR triple persistence and pulse candidate routing, forcing the user to push back with 'faz agora nao confio que o milestone esteja 100%'" — this quote captures Claude claiming completion + me correcting. Attributed to me.
2. Report: "You tried to implement inline instead of following the Rex protocol" — this is Claude attempting inline when my project's rules require agentic dispatch. I caught and corrected it. Attributed to me.
3. Report: "You assumed Antigravity ran Gemini CLI (not Claude Code) and dismissed maestro-orchestrate without grounding" — Claude assumption, my correction. Attributed to me.

All three 'friction categories' listed in my report describe assistant behavior, not mine.

Impact

• Users lose signal from /insights — the most interesting failure-mode analysis is misaddressed.
• For users who act as quality gates (heavy verifier style), the report can suggest they are the weak link when the opposite is true.
• Downstream use (personal review, team sharing, self-reflection) is misleading.

Steps to reproduce

1. Start a session where Claude repeatedly over-claims completion or skips protocols.
2. Push back each time with corrections (require evidence, force re-verification).
3. Run /insights after 5-10 such interactions.
4. Observe: friction categories describe the Claude behavior you corrected, attributed to you.

Suggested fix

In the analyzer prompt (the LLM that synthesizes friction patterns from transcripts), add an explicit role-attribution rule:

When deriving friction patterns, attribute behaviors by message role:
- role=user messages → user patterns (friction with the tool/workflow)
- role=assistant messages → assistant patterns (Claude's own errors/slowdowns)
- If a user message is a correction of an assistant behavior, the behavior itself belongs to the assistant, not the user.
Do not summarize assistant errors as user friction.

Optional richer fix: surface a separate "Claude's friction patterns" section that mirrors the existing user friction section, so users can see both sides of the interaction honestly.

Environment

• Claude Code: interactive CLI (Max 20x subscription, WSL2 Ubuntu)
• Report generated: 2026-04-14
• Session count analyzed: 118 (30 days)

Meta note

I run a heavily agentic/governance-first workflow (custom skills, hooks, multi-agent dispatch). My role in sessions is disproportionately the corrector/verifier. That makes this attribution bug especially visible in my transcripts, but it should affect any user with a strong verification style.