From Shared Text to Governed Objects

Once a prompt can be structured for text, chat, or media, prompts.chat faces a different problem: how should that artifact live in a community system? This chapter follows the transition from authored content to a durable platform object with an owner, type, visibility, metadata, revision history, feedback, and moderation states. The goal is to understand how prompts.chat supports reuse without pretending that discovery signals, quality gates, or public availability prove that a prompt is correct for every context.

A prompt becomes more than content

A file or copied paragraph primarily answers, “What does this instruction say?” A platform object must answer additional questions. Who created it? What is it called? Which kind of prompt is it? Is it public, private, or unlisted? How can someone find it? Has it changed? Who proposed the change? Can another person comment, vote, collect, or report it? What should happen if it is no longer suitable for public discovery?

The prompts.chat data model gives the prompt an identity and relationships that a plain text file does not have. It stores a title, slug, description, content, type, author, visibility, and optional category or tags. The type system distinguishes text, image, video, audio, structured prompts, skills, and other project-specific forms. The record can also carry media-related information, structured-format metadata, discoverability states, and connections to other prompts.

This is not merely a database convenience. Identity determines whether a prompt can be referred to reliably after its wording changes. Type determines which interface or expectations a consumer should apply. Visibility determines who may retrieve it. Relationships determine whether the platform can support discovery, revision, discussion, and composition around the prompt rather than treating every entry as an isolated string.

erDiagram USER ||--o{ PROMPT : authors PROMPT }o--o| CATEGORY : organized_in PROMPT }o--o{ TAG : labeled_with PROMPT ||--o{ VERSION : preserves PROMPT ||--o{ CHANGE_REQUEST : receives PROMPT ||--o{ COMMENT : discusses PROMPT ||--o{ REPORT : can_be_reported USER }o--o{ PROMPT : votes_or_collects PROMPT ||--o{ CONNECTION : links_to PROMPT { string title string type boolean visibility string status }

The diagram compresses a larger schema into the relationships that affect a prompt’s life. It should not be read as proof that every deployment exposes every relation in the same way. The repository’s configuration can enable or disable features such as private prompts, change requests, categories, tags, comments, AI search, AI generation, and MCP. The schema shows what the platform is designed to represent; configuration and deployment determine which parts are active.

Ownership and visibility shape reuse

Authoring creates an ownership boundary. A user record is related to the prompts they create, and the prompt can retain contributors or revision history. That boundary matters when a prompt is copied or changed. Reuse may be encouraged, but the platform still needs to know who can edit, who can propose a change, and which account is responsible for a private artifact.

Visibility adds another boundary. A public prompt can participate in discovery and community use. A private prompt can remain associated with an account without becoming a community resource. An unlisted prompt can be reachable through a specific path while being excluded from ordinary browsing.