Making the Library Callable

A governed prompt is useful only when it can reach the place where work happens. For prompts.chat, that means more than a browser page: the same object can be fetched by a terminal client, discovered through MCP, used from a Claude Code plugin, or packaged as a multi-file skill. This chapter follows those interfaces as different paths through the same lifecycle, so the reader can judge portability together with freshness, authentication, variable handling, and operational limits.

One artifact, different interfaces

The web interface is the most visible way to browse a prompt, but it is not the only consumer. A person in a terminal may want to search without opening a browser, copy a prompt with variables filled, or open the item in an external AI service. An AI client may need to list available prompts, retrieve one by name, and supply its variables as part of a tool call. A coding assistant may need to discover a skill and install its supporting files rather than receive one block of text.

These experiences differ because the interface owns different parts of the interaction. The website owns a visual browsing and contribution experience. The CLI owns terminal state, local navigation, copying, and its cache. The MCP endpoint owns protocol translation, visibility filters, authentication, variable elicitation, and rate limits. A plugin adds commands and skills that make those MCP capabilities discoverable inside an AI-assisted development environment. The prompt record remains the shared object, but its path changes what the consumer can do with it.

That is why integration should not be described as copying the catalog into several places. Ideally, each surface retrieves or represents the same current object according to its own contract. The risk is that the surfaces may not have the same freshness, permissions, or supported operations. Portability is a relationship between a source object and an interface, not a promise that every interface behaves identically.

The CLI: remote data with local state

The prompts.chat package’s default command launches an interactive terminal UI. It fetches prompt data from a full-content JSON endpoint and presents a list that can be searched, filtered by category, paginated, and opened in a detail view. The user can copy a prompt, fill variables through the client flow, run or open it, and navigate without leaving the terminal. The package also exposes a new command for creating a prompts.chat instance and an mcp command that starts an MCP server package, so the CLI is both a consumer and a doorway to deployment or integration.

The most important architectural choice in the terminal client is its cache. After a successful fetch, the client stores the prompt collection under the user’s home directory. If the network request fails later, it falls back to that local data. This improves resilience: a temporary network problem does not necessarily leave the user with an empty browser. But the cache also becomes a state owner. It can be stale, and the local user may not know which remote changes arrived after the last successful fetch.

The CLI’s filtering is local too. It searches titles, content, descriptions, authors, and tags in the data it has already loaded, then paginates the result.