Commands should be composable — one command must be able to invoke another deterministically

Resolved 💬 2 comments Opened Apr 1, 2026 by T-P-F Closed May 9, 2026

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:

  1. Duplicate the steps in both commands — violates DRY, drifts over time
  2. Reference the other command by name in prose ("run the /foo workflow") — 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/

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗