[FEATURE] /insights add optional path parameter for single project-scoped analysis

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

While helpful at a high-level, The /insights command currently aggregates data across all projects and sessions globally. For developers working across multiple projects — particularly those with different languages, frameworks, or domains — this produces noisy, low-signal output:

• Suggestions and patterns from unrelated projects are mixed together, reducing relevance
• Project-specific recommendations (prompts, skills, hooks) lack the context needed to know where they apply or whether they'd transfer to another project
• Frequent context switching is required to mentally filter insights per project
• Recently inactive projects may be underrepresented or omitted entirely
• Stale suggestions from older sessions can surface even when the issue was resolved in a later session

Proposed Solution

Add an _optional_ path argument to /insights. When omitted, behavior is unchanged (global analysis). When provided, analysis is scoped to sessions where the specified project was active — including cross-project sessions that touched that path.

# Current behavior (unchanged)
/insights

# Proposed: project-scoped analysis
/insights path/to/project

The path would resolve relative to the working directory, consistent with standard CLI conventions.

Alternative Solutions

_No response_

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

Before: Running /insights on a machine with 4 active projects returns a mixed set of suggestions — a hook recommendation for a Python data pipeline, a prompt pattern from a React app, and a skill suggestion that applies to a Go CLI tool. None are labeled by project, requiring manual triage.

After: Running /insights ~/projects/my-app returns only insights derived from sessions involving that project, with suggestions directly actionable in that context.

Additional Context

Additional Context

• Backwards compatible — no change to existing behavior when path is omitted
• Mirrors familiar CLI path-scoping conventions (e.g. git log <path>, grep -r <path>)
• Cross-project sessions touching the target path should be included, since context often spans projects (e.g. a shared library being modified alongside a consumer app)
• This lays groundwork for potential future features like per-project insight history or exportable project summaries