[FEATURE] Allow a user-designated skill/command as the autoCompact summarizer

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

When compaction runs, the harness always generates its own summary using its own judgment of what's relevant. That judgment doesn't always match what a given session actually needs preserved, and a developer with a well-tuned handover/session-notes skill has no way to reuse it for compaction instead of getting a second, independently-judged summary.

Proposed Solution

Let compaction invoke a user-designated skill/command to produce the pre-compact summary, instead of always using the harness's built-in summarizer:

"autoCompactSummarySkill": "session"

When set, compaction runs the named skill to generate the summary rather than (or in addition to) the default summarization logic.

Alternative Solutions

#90089 proposes replacing auto-compact with threshold-triggered /clear plus an auto-generated handover doc and auto-resume. That addresses lossy summaries too, but generates a new system-authored handover document each time rather than letting the developer reuse a skill they've already built and tuned for their own workflow.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

With autocompact off, I did significant work in a session and asked Claude whether its default compaction summary would be good enough, or whether we should write our own. It checked available skills, determined my own /session skill would produce a better summary for that context than its default summarizer, and used that instead — then said it would read that file back in after compacting. That confirmed the summarizer itself should be a configurable choice, since a project- or developer-tuned skill can know what to preserve better than a generic default judgment call.

Additional Context

Related: #90089 (adjacent — system-generated handover doc vs. reusing an existing trusted skill).

This is issue 3 of a 3-part split (part 1 #90137, part 2 #90138)— see also "[FEATURE] Replace autoCompact boolean with off/auto/ask modes" and "[FEATURE] Configurable ask breakpoints for autoCompact".

Additional context bearing on how this should be implemented, from a real-world attempt to approximate it with a PreCompact hook before this issue existed:

A hook that's silently defeated with no error is a gap regardless of the specific policy that triggers it. We configured a local PreCompact hook to inject team-workflow context (decisions + why, deferred items, next steps) into the compaction prompt. It never fired, and nothing in the CLI or in /compact's own hook-completion output ever indicated that — no error, no warning, just silence. We only discovered it by noticing the hook's log file was never written across two real /compact runs, including a completely fresh session. The trigger in our case was an enterprise managed-settings.json setting ("allowManagedHooksOnly": true, which disables all user/project-level hooks org-wide for every hook event), but the underlying problem — a configured hook that silently no-ops instead of erroring — isn't specific to that one setting.

That's directly relevant here: if autoCompactSummarySkill (or equivalent) is implemented as a variant of the existing hook mechanism, it inherits the same silent-failure risk on any install where hooks are locked down — a developer would believe their configured skill is active when it silently isn't, with no signal to tell them otherwise. Two independent asks that would prevent that: (1) implement this as a first-class settings.json key on a code path that doesn't depend on the hook system, and (2) regardless of implementation, surface a visible error/warning whenever a configured summarizer skill can't run, instead of a silent fallback. Either would have saved us a full investigation to even find the cause.