Bundled workflows (deep-research, code-review) are not enumerated in model context — model falsely tells users the slash command doesn't exist

Summary

Bundled workflows (deep-research, code-review) are invocable via Workflow({name: "..."}) and are exposed to users as slash commands, but their names are never enumerated in the model's context. Every other invocable surface is: skills, MCP tools, agent types, and deferred tools all arrive as explicit inventories. Workflows arrive as a bare name parameter with no directory.

The result is that the model cannot distinguish "this workflow does not exist" from "I have no list of workflows" — and it reliably resolves that ambiguity the wrong way, telling the user the command is unavailable.

This has happened to me multiple times across sessions.

What happens

I typed /deep-research alongside another request. The model responded:

/deep-research isn't available in this session — it's not among the installed skills, so I can't invoke it.

It then substituted a hand-authored workflow instead.

deep-research is in fact a bundled workflow that was available the entire time. When I pushed back, the model searched the filesystem and found it immediately — including 15 persisted deep-research-wf_*.js scripts across 13 distinct sessions in my own transcript history. It had been running it for weeks.

Expected

The model should either (a) receive an enumeration of available workflow names the way it receives skills, MCP tools, and agent types, or (b) be told explicitly that the workflow registry is not enumerated in context, so "not listed" carries no information about existence.

Either fixes the failure. Silence about the registry's existence is what produces a confident false denial.

Why it happens

Two mechanisms compound:

1. No inventory. The Workflow tool description says name is the "Name of a predefined workflow (built-in or from .claude/workflows/)" and then lists none. There is no way for the model to check.

1. An adjacent instruction that over-generalizes. The session prompt instructs: "Only use skills listed in the user-invocable skills section — don't guess." That rule is correct and well-scoped for Skills, and deep-research is correctly absent from the skills list because it is not a skill. But it has no counterpart for workflows, so the model applies skill-shaped reasoning to a workflow and concludes non-existence rather than "wrong lookup table."

The failure is quiet, which is what makes it costly — the user gets a plausible-sounding denial and a substituted approach rather than an error.

Reproduction

1. Invoke /deep-research (or /code-review) in a session where the model has not previously used it.
2. Observe whether the model invokes Workflow({name: "deep-research"}) or claims the command is unavailable.

Not deterministic, but recurring. The denial is more likely when the workflow is requested alongside other work rather than as the sole instruction.

Related

• #73731 — Workflow({name}) does not discover saved workflows under .claude/workflows/. Related but distinct: that is a runtime resolution failure for user-saved workflows. This report is about bundled workflows resolving fine while being invisible to the model's context, so it declines to call them. If triage disagrees and considers these one issue, they share a root cause in workflow-name discoverability.
• #78994 — confirms deep-research and code-review are bundled workflows.

Suggested fix

Emit available workflow names into context alongside the existing skills/agents/MCP inventories. A one-line-per-workflow listing with whenToUse would be enough — deep-research's meta already carries a usable description.

Environment

• Claude Code 2.1.222
• Windows 11 Pro 26200
• Model: Opus 5