Commands should be composable — one command must be able to invoke another deterministically
Problem
There is no reliable way for one custom command to invoke another custom command. This structurally prohibits DRY logic implementation across command workflows.
If command A and command B share a common sub-workflow (e.g., "sync a submodule" or "poll CI and merge"), the only options today are:
- Duplicate the steps in both commands — violates DRY, drifts over time
- Reference the other command by name in prose ("run the
/fooworkflow") — works sometimes but is probabilistic, not deterministic. The model may interpret the reference incorrectly, skip steps, or stop early.
Neither option is acceptable for production workflows.
Prior art
This previously worked via SlashCommand tool invocations before the Skill tool was introduced. See #8421, which documents the regression — commands that chained other commands stopped executing after the first nested call. That issue was auto-closed by inactivity bot despite active user complaints and was never fixed.
Expected behavior
A command should be able to invoke another command the same way a function calls a function:
- Deterministic dispatch (not dependent on model interpretation)
- The invoked command runs to completion
- Control returns to the calling command, which continues with its remaining steps
- Works for any depth of nesting
Use case
We have ~15 custom commands for repo operations (commit, push, sync submodule, sync branches, deploy, etc.). Many share sub-workflows. Today we either duplicate steps or accept non-deterministic cross-references. A composable command system would eliminate both problems.
Environment
- Claude Code extension (VS Code)
- Custom commands in
.claude/commands/
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗