Feature Request: Filtering Insight Reports by Commit/PR/Date Range

Resolved 💬 3 comments Opened Mar 9, 2026 by colmancreative Closed May 11, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Currently, /insights analyzes all cached sessions indiscriminately. After addressing friction points or workflow issues it identified, those resolved issues persist in subsequent reports unless you clear or archive the session cache — but for longstanding projects, clearing the cache also means losing valuable session memory.

The tool is also evaluated based on total sessions and cannot be differentiated by project or workflow. For devs working across multiple languages or workflow styles (e.g., Python backend vs React/TS frontend), it would be valuable to generate insights scoped to distinct workflows rather than a single blended report.

Adding filter parameters to constrain which sessions /insights are analyzed would make this a significantly more powerful tool with a relatively simple enhancement.

Proposed Solution

Insight Filters:

  1. --since yyyy-mm-dd | analyze only sessions from a given date forward
  2. --after-commit <sha> | analyze only sessions after a specific commit (useful for sprint-driven workflows where issues get fixed between cycles)
  3. --range yyyy-mm-dd..yyyy-mm-dd | bounded window for comparing across sprints (e.g., "did my friction patterns change between M8 and M10?")
  4. --project <path> | scope analysis to sessions from a specific project directory, complementing

https://github.com/anthropics/claude-code/issues/28153

Alternative Solutions

_No response_

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

  1. Post Project Evaluation
  2. Month-to-month tracking of the effectiveness of /insights recommendation implemented.
  3. Evaluation of approach issues between projects
  4. Assessment of setup between workstreams and programming languages, workspaces, etc.

Additional Context

Context:

  • Sprint-driven workflows produce a natural cycle of execute → audit → fix → merge. Stale friction points from earlier sprints dilute the signal in new reports, preventing fresh insights from surfacing.
  • Multi-project users get a blended analysis that may not reflect the patterns of any single codebase or workflow.

Related:

Related Issues:

View original on GitHub ↗

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