claude-code - 💡(How to fix) Fix [FEATURE] Per-word predictive tree-dialogue completion for slash commands (grammar from skill metadata)

Problem Statement

When invoking a slash command in Claude Code today, the autocomplete experience ends at the command boundary: typing / filters the flat list of ~280 skills/commands, and once a command is committed (/voice-enforcement, /closeout, etc.) the user is back to free-form typing for any arguments, context, or follow-on instructions. The command itself is structured (it has named parameters, valid argument values, common follow-on patterns), but none of that structure surfaces as the user composes the prompt.

The result: users either memorize the per-command grammar, type a partial command and submit "blind" to see what happens, or open the skill's SKILL.md in another pane to see what arguments are valid. None of these scale across a 100+ skill library, and they're especially hostile to discovery (you can't find out what a skill can do without leaving the prompt).

Proposed Solution

Per-word predictive tree-dialogue completion, driven by declarative grammar in skill/command frontmatter.

After the user commits a slash command, suggest next-word candidates derived from the skill's metadata. For example, after /accessibility-patterns, surface a branching menu like:

/accessibility-patterns  ←  user typed this
   │
   ├─ L2: WHEN / CONTEXT
   │   ├─ about accessibility       [user-asks-about-accessibility]
   │   ├─ about wcag                [user-asks-about-wcag]
   │   ├─ on *.html files           [file-type:*.html]
   │   └─ in frontend context       [context:frontend]
   │
   ├─ L3: AND THEN  (chain to complement)
   │   ├─ /frontend-design-systems
   │   └─ /responsive-design-patterns
   │
   └─ L4: PHASE × ORGAN
       ├─ in build-phase × organ-iii
       └─ in prove-phase × organ-iii

Each level is declared metadata, not generation. The user walks the tree with arrow keys / one-keystroke IDs / fuzzy filter, composing their intent through structured choices rather than blank-page typing.

The grammar substrate already exists. A representative skill registry I examined (162 skills) carries:

• triggers[] — 95% populated; high-quality next-word stems like user-asks-about-X, file-type:Y, context:Z, before-Z
• complements[] — 48% populated; lateral "and then /<sibling>" branches
• governance_phases[] — 93% populated; FRAME/SHAPE/BUILD/PROVE narrowing
• organ_affinity[] — 92% populated; domain narrowing
• category + governance_norm_group — classification axes

A grammar engine that reads frontmatter and emits a suggestion graph requires no new training data and no new declarations — it's a structural read of what skill authors are already writing.

The minimum-viable shape would be a single new frontmatter field (grammar: or similar) for skills that want richer trees than the auto-derived defaults, plus a tab-or-arrow-key affordance after a slash command commits.

Alternatives Considered

1. Existing argument hints — some commands declare argument hints today, but they're per-command bespoke and flat (one level deep). They don't compose, can't branch, and aren't derived from a shared grammar.

2. External composer — I built a local fzf-driven picker that walks the same trie outside Claude Code and emits the assembled prompt to the clipboard for pasting. It works, but loses the inline-typing UX and requires context-switch out of the TUI. That's a workaround, not a substitute — the right architectural home for this is inside the input renderer.

3. Dictionary-style word completion (per #60761 by @khuisman) — adjacent but different: that targets natural-language prose; this targets slash-command argument grammar. The two could ship independently.

4. Skill autocomplete parity with VS Code (#10246) — closer adjacent, but extends /-prefix completion only; doesn't address per-word grammar after the command commits, which is where most of the typing burden lives.

Priority

Medium - Quality of life improvement

Discovery and composition speed scale poorly past ~50 skills today; teams with curated skill libraries (the case Anthropic seems to be designing toward via the skill registry and plugin system) hit this earlier. The bigger structural win is making skill authors' declarative metadata visible to the user — right now it's used by the model but invisible at the input layer.

Additional Context

Related (adjacent, not duplicate):

• #60761 — dictionary word-completion in prose (lexical layer, not syntactic)
• #10246 — skill autocomplete CLI parity with VS Code (extends /-list; doesn't enter per-word grammar)
• #54829 — plugin slash-command namespace-prefix drops (UX-adjacent, not feature-equivalent)