[FEATURE] /insights should incorporate ~/.claude/ config context into analysis

Resolved 💬 2 comments Opened Feb 4, 2026 by aaronsb Closed Mar 5, 2026

Problem

The /insights report analyzes session telemetry (tool counts, outcomes, message volume) but has no visibility into user configuration — hooks, custom integrations built on top of hooks, custom commands, agent profiles, or settings. This leads to incorrect conclusions.

Concrete example

My ~/.claude/ is a git-managed configuration with:

  • 24 contextual ways across 3 domains with regex, semantic, and model-based matching
  • 8+ hook matchers across 4 lifecycle events (SessionStart, PreToolUse, UserPromptSubmit, Stop)
  • 6 behavioral agent profiles for delegation (code-reviewer, task-planner, etc.)
  • Custom slash commands and macro scripts for dynamic context injection
  • Session-scoped state management via marker files for once-per-session gating
  • 90+ git commits of active maintenance over ~2 months

The insights report concluded:

"the absence of a CLAUDE.md or custom instructions means Claude has no persistent context about your repo conventions, testing setup, or preferences"

This is factually wrong. The setup is specifically designed to inject instructions at the right lifecycle moments (session start, pre-tool, prompt submit) rather than front-loading a static CLAUDE.md. The report saw the effects of this system (structured task handoffs, high productivity, consistent workflows) but attributed them to user discipline rather than recognizing the infrastructure driving it.

Another mischaracterization

The report flagged every session as "partially_achieved" and categorized this as friction — "sessions ending before task completion." In practice, this is an intentional workflow: using TodoWrite/TaskCreate near the end of a context window as a handoff mechanism for the next session. The task list acts as a continuation contract, not evidence of failure.

The insights tool has no way to distinguish "ran out of context mid-task" from "deliberately set up a checkpoint for the next session" — but inspecting the config (hooks that fire on session start, ways that load continuation context) would reveal this is by design.

Proposed solution

When generating the /insights report, optionally scan:

  1. ~/.claude/ (user scope) — settings.json, hooks, and user-created integrations identified within (e.g. contextual guidance systems, custom matching scripts, macro generators), commands, agent profiles
  2. $PROJECT/.claude/ (project scope) — project-specific integrations, skills, CLAUDE.md

What to surface

| Config element | Insight it provides |
|---|---|
| settings.json hooks | User has lifecycle automation (not "no instructions") |
| User-created integrations (e.g. contextual guidance directories, matching scripts) | Domains of custom guidance, instruction injection strategies |
| Agent profiles | Delegation patterns in use |
| Custom commands | User-defined workflows |
| Integration config files | Intentionally enabled/disabled feature domains |
| Git history (if available) | Config maintenance cadence |
| CLAUDE.md (user + project) | Instruction strategy (static vs hook-injected) |

How it changes the analysis

  • "No custom instructions" → "User has 24 contextual guidance entries with semantic matching and 8 lifecycle hooks — instructions are injected dynamically via user-created integrations rather than statically"
  • "Sessions ending prematurely" → "User has session-start hooks that load continuation context — partial completion may be an intentional handoff pattern"
  • Suggestions section → Skip recommending things the user already has (hooks, custom instructions, structured workflows)

Privacy consideration

Config scanning should be opt-in or at minimum clearly disclosed, since ~/.claude/ may contain credentials or sensitive paths. The report could note "config analysis available — run /insights --include-config for richer analysis" without scanning by default.

Environment

  • Claude Code CLI
  • macOS / Linux
  • Config managed via git in ~/.claude/

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗