skills/strategic-compact/SKILL.md
Suggest context compaction at optimal logical boundaries — between phases, after a research burst, after a debugging session ends — rather than waiting for the automatic compaction threshold to hit mid-task. Use when the user asks whether to compact, mentions context is getting long, wants to checkpoint before a big task, or when you notice the session is approaching a natural transition where compacting would preserve the next phase's context. Complements (doesn't replace) Claude Code's built-in auto-compaction. Triggers on "/strategic-compact", "should I compact", "when should I clear context", "getting long", or proactively at phase boundaries and session transitions.
npx skillsauth add mhylle/claude-skills-collection strategic-compactInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Suggest context compaction at logical boundaries — not arbitrary token thresholds. Auto-compaction is a safety net; strategic compaction is a workflow optimization that makes compaction feel like a natural pause instead of an interruption.
Auto-compaction fires on simple thresholds (token count, time). That creates real problems:
Strategic compaction instead:
context-saver to preserve critical state first.Goal: compaction that feels like a natural pause, not an interruption.
Passive monitoring — via PreToolUse hook that attaches to every tool call, tracks counters, and evaluates boundaries. Hook setup → references/hook-setup.md.
Direct invocation:
/strategic-compact — check current session state and get a recommendation./strategic-compact status — view tool counts and threshold proximity./strategic-compact now — force a suggestion (auto-invokes context-saver first).Trigger phrases: "should I compact", "when should I clear context", "getting long", "checkpoint", "context is getting big".
Two questions:
Both must be yes before suggesting. The full rule set is in references/boundary-rules.md. Summary:
| Signal strength | Trigger |
|---|---|
| Strong | Task completion (TaskUpdate → completed), + ≥60% threshold, + >10min since last suggestion |
| Strong | Successful git commit, + ≥70% threshold, + no pending tasks in this feature |
| Medium | New feature starting (TaskUpdate → in_progress after completing previous), + ≥50% threshold |
| Warning (high priority) | Estimated context usage >80% + ≥90% threshold — prevent forced auto-compaction mid-task |
Default: 50 weighted tool calls between logical boundaries.
"Significant" means the weighted count — raw tool calls multiplied by the weight table below. A tool call with weight 1.0 contributes 1 significant call; a Read with weight 0.5 contributes 0.5. Weights:
Scenario-tuned thresholds (standard dev 50, debugging 75, quick fixes 30, large refactor 40, docs 60). Full config + dynamic adjustment rules → references/hook-setup.md.
When a suggestion is accepted, auto-invoke context-saver before compaction (via integrate_context_saver: true in hook config — default). This produces a handoff doc capturing:
The compacted session can be resumed from that file. See context-saver/SKILL.md for the doc format.
Keep suggestions informative but non-intrusive:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Context Compaction Suggested
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Session Metrics:
Tool calls: 72 significant (threshold: 50)
Session time: 45 minutes
Last boundary: Task completed 3 min ago
Boundary Detected:
Task "Add user authentication" marked complete
Git commit: "feat: implement JWT auth flow"
No pending changes or active debugging
Recommendation: GOOD TIME TO COMPACT
Options:
[1] Compact now (will invoke context-saver first)
[2] Defer for 15 minutes
[3] Defer until next boundary
[4] Dismiss (don't suggest again this session)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Always show why now — the specific boundary and conditions that triggered the suggestion. Users trust the heuristic faster when they can see its reasoning.
Minimal mode (for experienced users):
[Compact? 72/50 calls | Task done | Clean state] Y/n/defer
context-saver — auto-invoked before compact. Captures in-flight state as a handoff doc.implement-phase — emits phase_complete boundary events.create-plan — plan creation emits a boundary.code-review — review completion emits a boundary.Full integration specs → references/hook-setup.md.
references/hook-setup.md — PreToolUse hook config, state tracking, tool weights, dynamic thresholds, per-project configuration, integration specs, troubleshootingreferences/boundary-rules.md — Full suggest-when / suppress-when rule specifications with YAML patterns, plus accept/defer heuristics for userstools
--- name: tt-workflow-build description: Tasktracker-native trigger for a PARALLEL build via the Claude Code Workflow tool. Thin by design — it does two things, then drives to done: (1) ensure a tasktracker project exists (use the existing one, or create one), then (2) start a dynamic `Workflow` that builds it, tracking the work in tasktracker and using the build + verify skills. It does NOT analyze parallelism up front, ask the user to choose a mode, hand back, or fall back to a sequential skil
tools
--- name: grumpy-reviewer description: A single grumpy, nitpicky structural code reviewer that runs as an isolated subagent and treats the code as third-party work submitted by a junior programmer for validation. It cares about exactly one thing — maintainability — judged through separation of concerns, service-oriented design, helper-method extraction, small files, and the rule of 7 (as any grouping nears 7 members, it pushes for sub-groupings). It is deliberately kept OUT of the implementation
development
--- name: tt-workflow-run description: Tasktracker-native autonomous build-loop orchestrator. Drives a first-class `workflow_run` end-to-end — create the run (Gate 1 lifecycle completeness + Gate 2 zero-defects-in), then loop while `getNextReadyTask(projectId)` returns a slice — `setActiveTask` → record a pre-slice `scanArchitectureDrift` baseline → delegate the slice to `/tt-implement-phase` (which does the code work, registers the architecture delta in-slice, and auto-logs defects/learnings/fr
tools
Tasktracker-native project-wide parallel audit using the Claude Code Workflow tool (dynamic workflows). Partitions a repo / backlog / architecture and fans out read-only agents (one per partition) that return schema-checked findings, aggregates them into a deduplicated, ranked risk register, and OPTIONALLY writes fixes back as tasks under a Bug Fix phase — with all tasktracker writes done by the PARENT, never the parallel agents (single global active-task pointer). Journaled and resumable, so a rate-limit or crash mid-audit resumes without re-running completed partitions. Use for large, embarrassingly-parallel, read/analyze-heavy jobs where each unit is self-contained and the output aggregates — audit every file/component for risk, find all architecture drift (scanArchitectureDrift) or duplicate tasks (detectDuplicates/auditDuplicates), per-file tech-debt sweep, test-coverage or security-surface scan across a whole project. Triggers on "/tt-workflow-audit", "audit the whole repo", "parallel audit", "scan every file/component", "find all drift/duplicates", "tech-debt sweep (tasktracker)", or any whole-project analyze-at-scale request inside a session with a tasktracker project. Prefer this over /codebase-audit or /code-quality-audit when the project is tracked in tasktracker AND you want the findings written back as tasks; prefer it over team-* modes when the units don't need to negotiate live (they just report).