Feature Request: Generate prompts from a subset of the library (component allow-list in PromptOptions)

[Shinyaigeek]

This is proposal, so if you feel this is not acceptable, feel free to close this. Also, if this seems good, I would like to implement this!

Is your feature request related to a problem? Please describe.

Yes. library.prompt() always emits every component in the library. For a library with ~54 components that's ~20k tokens, even when a given screen only needs a handful (e.g. Card / Table / Stat / LineChart).

This causes two concrete problems:

1. Token bloat — most of the prompt describes components the model will never use.
2. Lower generation stability — more component choices means more chances for a small model (e.g. Haiku) to pick the wrong one. Fewer, relevant signatures measurably improve selection accuracy.

It's especially painful via the CLI / coding-agent path: the generated prompt stacks on top of the agent's own context (~18k), so an unfiltered ~20k can become the dominant share of the window — most of it unused.

Describe the solution you'd like

An opt-in component allow-list on PromptOptions:

library.prompt({ components: ["Card", "Table", "Stat", "LineChart"] })

• components?: string[] — when set, only these components appear in the prompt. Omit for today's behavior (all components). Fully backward-compatible.
• The prompt's root is always kept, even if not listed, so the output stays self-consistent.
• Sub-component dependencies are pulled in automatically — if a listed component renders other components as children, those are included too, so the prompt never references signatures it doesn't show. (Implementation can walk the existing schema refs; an includeDependencies: false escape hatch could be offered, but auto-include should be the default.)
• componentGroups are filtered to the kept set (empty groups dropped).
• Unknown names fail fast with an "Available: ..." message, matching the existing root validation.

Same thing surfaced on the CLI:

openui generate ./lib.tsx --components Card,Table,Stat,LineChart

Describe alternatives you've considered

• componentGroups — only reorganizes the prompt output; it doesn't reduce what's included, so it doesn't help with tokens.
• Splitting the library into smaller libraries — defeats the purpose of one shared library and duplicates definitions; subsetting is a per-prompt view concern, not a library-structure one.
• A deny-list (exclude) — turns the real ask ("I want these 4") into a "remove these 50" problem; an allow-list matches intent directly.
• Manual subsetting by the caller — requires reasoning about the component dependency graph by hand, which is exactly what the auto dependency closure removes.

Additional context

• Both fields are optional; unset = today's behavior, so this is non-breaking.
• The only non-trivial piece is the dependency closure, which keeps subsetting from silently breaking generation; it can reuse the schema refs the library already tracks.