メニュー
WHEN to auto-invoke: After 50+ edit operations, long sessions, before context overflow, when suggested by hooks, transitioning between major task phases. WHEN NOT to invoke: Mid-implementation, during active debugging, when context is critical to current work.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | strategic-compact |
| description | WHEN to auto-invoke: After 50+ edit operations, long sessions, before context overflow, when suggested by hooks, transitioning between major task phases. WHEN NOT to invoke: Mid-implementation, during active debugging, when context is critical to current work. |
Compact context at meaningful workflow junctures rather than accepting arbitrary auto-compaction.
Auto-compaction triggers at arbitrary points:
Strategic compaction = User-controlled timing at natural breakpoints.
| Phase Transition | Why It's Good |
|---|---|
| Research → Implementation | Fresh start with findings summarized |
| Feature complete → New feature | Clean context for new work |
| Debugging done → Continuing | Problem solved, context can reset |
| PR submitted → New task | Natural task boundary |
| End of day → Next day | Session boundary |
| Situation | Why It's Bad |
|---|---|
| Mid-implementation | Loses code context |
| Active debugging | Loses error trail |
| Multi-file refactor | Loses file relationships |
| Complex merge | Loses conflict context |
The strategic-compact.sh hook:
# What you'll see:
[Strategic Compact] 50 edit operations reached
Consider using /compact at a natural breakpoint:
- After completing a feature or fix
- After finishing research, before implementation
- When switching between different task types
cat ~/.claude/.compact_counter
After compacting or starting fresh:
rm ~/.claude/.compact_counter
When you're at a good breakpoint:
/compact
Before compacting, ensure:
- [ ] Current task is at a natural stopping point
- [ ] No uncommitted critical context
- [ ] Key decisions are documented (in code comments or memory)
- [ ] Next steps are clear
In strategic-compact.sh:
THRESHOLD=50 # Initial notification
REMINDER_INTERVAL=25 # Reminder frequency after threshold
# Skip the hook for this session
export SKIP_COMPACT_HOOK=1
Research phase
↓
[Good time to compact - summarize findings]
↓
Implementation phase
↓
[Good time to compact - feature complete]
↓
Testing phase
Before /compact, ensure key context is preserved:
## Session Summary (for next context)
### Completed
- Implemented user authentication
- Added JWT token refresh
### In Progress
- Working on password reset flow
- File: src/auth/reset.ts
### Next Steps
1. Complete email verification
2. Add rate limiting
Store persistent context in .claude/memory.json:
{
"current_focus": "Authentication system",
"architecture_decisions": [
"Using httpOnly cookies for JWT",
"Refresh tokens stored in Redis"
],
"blocked_on": "Waiting for email service API key"
}
Strategic compaction works with memory persistence:
This prevents the "what was I doing?" problem after compaction.
WHEN to auto-invoke: Creating API routes, building endpoints, adding route.ts files, implementing REST/GraphQL APIs, adding authentication to APIs, rate limiting, API validation with Zod, handling HTTP methods (GET/POST/PUT/DELETE). WHEN NOT to invoke: Pure frontend work, styling, React components without API calls, documentation-only tasks, database migrations without API changes.
WHEN to auto-invoke: Code review requests, refactoring code, cleaning up code, performance optimization, security audits, linting issues, reducing technical debt. WHEN NOT to invoke: Building new features (use domain-specific skills), initial implementation, documentation-only work.
WHEN to auto-invoke: End of productive sessions, after solving difficult problems, after user corrections, after discovering effective workarounds, after establishing project conventions. WHEN NOT to invoke: Trivial sessions, sessions with only exploration, when explicitly told not to learn.
WHEN to auto-invoke: Database schema design, creating migrations, writing SQL queries, query optimization, Supabase operations, Prisma/Drizzle schema changes, PostgreSQL tasks, RLS policies, indexes. WHEN NOT to invoke: Pure frontend work, API logic without database, styling, React components, deployment tasks.
WHEN to auto-invoke: Creating CI/CD pipelines, GitHub Actions workflows, Docker/containerization, Vercel/Netlify deployment, infrastructure as code, environment variables, deployment configurations. WHEN NOT to invoke: Application code changes, UI development, database schema design, testing application logic.
WHEN to auto-invoke: Measuring code quality, testing AI outputs, establishing success criteria, defining acceptance tests, checking implementation correctness. WHEN NOT to invoke: Simple implementations, prototyping, exploration phases, when speed matters more than measurement.