session-aggregate: cross-workspace pattern mining skill

[bacleclement]

Part of the feedback-loop v2 epic.

Problem

Individual session reviews and revision records live in isolation. Each workspace gets its own {key}-review.md and {key}-summary.md, but patterns only emerge when you look across many workspaces.

Examples of patterns only visible at the aggregate level:

• "70% of post-QA defects in the last month were bad acceptance criteria — the refine skill is missing an edge-case check"
• "All bad architecture revisions happened in the network scope — its AGENT.md is stale (last updated 6 weeks ago)"
• "The tdd skill produced feedback corrections 4 times in 2 weeks, always about missing failure cases — skill gap"
• "Recurring capture-rule entries about readonly props across 5 different features — propose promoting to code-standards.md"

Today these signals are invisible. You'd have to manually read 20 review files and mentally diff them.

Proposed skill: session-aggregate

Runs on accumulated summaries and revision records, detects recurring patterns, proposes rules via capture-rule.

Inputs

• A set of {key}-summary.md files (produced by child B's session-summarize)
• A set of revisions/{timestamp}/ folders (produced by child A's revise)
• Scope filter: all workspaces / one app scope / one time window / one skill
• Minimum pattern size: e.g. "report patterns that occur in at least 3 workspaces"

Logic

LLM-driven pattern detection. The prompt asks the model to:

1. Recurring corrections — same rule captured multiple times across features
2. Recurring debug patterns — same type of bug found repeatedly
3. Recurring friction points — same skill failing, same manual step taken
4. Stale context indicators — references to patterns that no longer exist in the codebase
5. Skill gaps — operations users keep doing by hand
6. Classification hotspots — which revise classification dominates (bad spec? bad arch? bad tests?)

For each pattern:

• Category (one of 6 above)
• Evidence (which workspaces, which timestamps, which classifications)
• Recommended action (capture-rule target: code-standards.md, product.md, scope AGENT.md, or specific kitt skill)
• Confidence score

Output

~/.claude/workspace/aggregates/{timestamp}-patterns.md with:

• Summary of scope and time window analyzed
• Ordered list of detected patterns with evidence
• Proposed rules ready to be captured via capture-rule

User reviews the output, approves patterns one by one, each approval invokes capture-rule against the suggested target.

Trigger

• Manual: /session-aggregate with optional scope/time arguments
• Future automation: a cron-based call once a week to propose patterns for review (not in this ticket)

Depends on

• Child A (revise) — needs a few weeks of revision data to mine
• Child B (refactor) — needs session-summarize output to consume

Does NOT depend on

• Multi-user aggregation (not in scope, solo first)
• Cloud storage (local filesystem only)
• Studio UI (Studio will read these files later)

Files to change

• ~/.claude/kitt/.claude/skills/session-aggregate/SKILL.md (new)

Acceptance criteria

• /session-aggregate is callable with optional scope and time filters
• Produces a timestamped aggregates/{timestamp}-patterns.md file
• Each detected pattern has category, evidence, recommended action, confidence
• User can approve patterns one by one; approvals flow through capture-rule
• Works on an empty dataset (gracefully reports "not enough data")
• Respects minimum pattern size threshold to avoid noise

Estimate

~1-1.5 days solo. The skill is mostly a prompt + a file loop + delegation to capture-rule.

Ship condition

Only ship after child A has been running for at least 3 weeks in real use — otherwise there's nothing to aggregate.

[bacleclement]

Phase C addition: Refactoring intelligence from cross-session patterns

Following the analysis in #25 and the design of the /refactor skill (Phase A/B), session-aggregate gains a new pattern detection category:

7. Recurring architectural drift

When the same type of refactoring opportunity appears across multiple features/sessions, session-aggregate should detect and surface it:

Examples:

• "Frontend keeps deriving backend data — 7 instances of .some()/.filter()/.reduce() on DTO arrays in the last month across 4 features → propose BFF flag pattern as a code-standards rule"
• "Type assertion hacks (as X & { ... }) appeared in 5 mappers across 3 features → DTO contract gaps are systemic, not one-off"
• "canManage* authorization checks in frontend entities found in 3 features → propose backend-owned authorization flags as a pattern"
• "Shared components exist but aren't reused — TabPage, SectionHeader, etc. underutilized across 6 features → missed abstraction is a recurring pattern"

How it feeds from /refactor

The /refactor skill (Phase A) produces structured findings with categories:

• layer_violation, authorization_leak, missed_abstraction, contract_gap, duplication, dead_code

Each finding is logged to session-log.jsonl:

{"ts":"...","skill":"refactor","event":"finding","data":{"category":"layer_violation","file":"counters-section.hooks.ts","severity":"M","detail":"Frontend derives hasAnyOvertime from DTO periods"}}

Session-aggregate (this skill) mines these events across workspaces to detect systemic drift vs one-off issues. Systemic findings get proposed as code-standards.md rules via capture-rule, not just individual fixes.

Updated pattern categories (7 total)

1. Recurring corrections
2. Recurring debug patterns
3. Recurring friction points
4. Stale context indicators
5. Skill gaps
6. Classification hotspots
7. Recurring architectural drift ← new, fed by /refactor findings

Context

Inspired by Cantrill's "The Peril of Laziness Lost" — LLMs generate code but don't simplify. The refactor → aggregate pipeline closes the loop: detect drift per-feature, surface systemic patterns cross-feature, codify as rules so the drift stops recurring.