[FEATURE] A native way to hide a plugin's workflow behind a single command entry point

Open 💬 0 comments Opened Jun 28, 2026 by natemacfadden

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

It can sometimes be valuable to have the model provide assistance in constructing arguments for calling a workflow. This occurs in my plugin in which there is a workflow with a moderate number of arguments that must be specified. My desired entry point is via a command/skill to the current model, not via the raw workflow. As of now, I have to hide the js file not under the natural workflow directory (workflows/) but under a different lib (e.g., lib/) so it doesn't get auto-exposed to the user.

Without this hiding, there are two exposed entry-points that I have to design around the user. One of which is notably less-friendly. It would be very unclear to a user which is preferred without the hack (changing the directory).

Proposed Solution

I would like to be able to set a field in the meta object of the workflow. Something like

export const meta = {
  ...
  hidden: true,            // <- proposed: keep it invoke-by-path-only, don't auto-register as a command
  ...
}

Under this configuration, I'd like the workflow to be hidden from the user, only callable via Claude.

Alternative Solutions

_No response_

Priority

Low - Nice to have

Feature Category

CLI commands and flags

Use Case Example

  1. I'm building a plugin with a large argument surface
  2. I decide it's better to use Claude as a `doorman' to assist the user in argument setting
  3. I set meta.hidden = True so I can have these requests go through Claude

Additional Context

_No response_

View original on GitHub ↗