Allow custom slash commands to invoke other slash commands (e.g. /clear, /compact)
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
Custom slash commands are prompts, so they can't trigger built-in commands. This breaks otherwise-natural workflows. My specific case: a /session command that saves a handoff file, clears context, and restores from the handoff. The save and restore work, but the /clear in the middle can't be invoked from the command — the user has to run it manually. Hooks (SessionEnd/SessionStart) automate the restore, but a SessionEnd command hook runs shell, not Claude, so it can't produce a Claude-authored handoff at end-of-session either.
Request: A supported mechanism for a command (or hook) to enqueue/execute another slash command — including built-ins like /clear and /compact. For example, a directive the harness recognises in command output, or a type: "slash_command" step, so multi-step flows like save → clear → restore can run as one action.
Alternatives considered: Chaining works for skills, but not built-ins; hooks automate parts but can't call Claude at SessionEnd; /compact covers the "keep going" case but not a true reset with a distilled, on-disk handoff.
Proposed Solution
The key reframe: /clear is the one atom nothing can invoke — not a command, not a hook. So the winning design isn't "one command that does all three." It's make everything around /clear automatic, so typing /clear alone is the whole cycle. We've already automated the restore side with the SessionStart hook. That leaves one question — when does Claude distill the handoff — and it has a real tradeoff, which gives you three clean options.
The tradeoff is simple: distilling a good handoff requires Claude (a shell hook can't do it), so Claude has to run at some point — either once when you ask, or continuously in the background. Cheap means one command; automatic means tokens.
Option A — one command, then bare clear (what you already have, and my default recommendation). Run /session --save, then /clear. The SessionStart hook auto-restores. Two keystrokes, distilled, durable on disk, cheap. This is the best everyday setup.
Option B — bare clear only, save is automatic. Add a Stop hook (fires when Claude finishes a response) that keeps tmp/handoff.md continuously distilled via a subagent. Then the only thing you ever type is /clear — save and restore both happen automatically around it. This is the closest thing to "run commands inside a command" that the platform actually permits. The cost is a small background distillation on each turn, so I'd gate it (refresh every N turns, or only when the conversation has grown past some size) to keep tokens sane. Best for long or unattended sessions where you don't want to remember to save.
Option C — no files, native, zero setup. Just use /compact (optionally /compact focus on the auth work). It's the built-in that distills history and keeps you in the same session — a genuine one-keystroke "clean but continue." You give up the durable on-disk handoff and the true empty-context reset, but for routine mid-task breathing room it's the simplest thing that exists.
My recommendation: keep Option A as your normal driver, use Option C when you just need to shrink context and keep going, and add Option B only if you're doing long unattended runs where forgetting to save is a real risk.
If you want, I'll build Option B — the rolling Stop-hook distiller with a turn-gate so it doesn't fire every message. One caveat: I've verified the SessionStart/SessionEnd/command schema, but the Stop hook's agent/prompt type schema I'd want to confirm against the docs before writing it, so it's correct on the first drop. Want me to verify and build it?
Alternative Solutions
_No response_
Priority
High - Significant impact on productivity
Feature Category
Interactive mode (TUI)
Use Case Example
_No response_
Additional Context
_No response_
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗