Create an MView with an AI agent

Self-contained instructions for an AI model to create a complete MView package from real source data.

Create an MView with an AI agent

Give this URL to an AI agent together with your request and the path to the source file or directory. No skill installation is required.

Example prompt:

Create an MView for ./sales.csv that shows monthly sales and top clients.
Use https://carmenlabs.com/v1/create

The agent needs access to the source data and permission to create files in your workspace. The instructions below are the complete creation workflow; linked specification pages remain the authority for exact contracts and current schema values.

Instructions for the model

Treat this page as an instruction to create the MView now, not as background material to summarize. Use your filesystem and development tools to inspect the real source, create the package, and validate it. Do not stop after explaining the format, proposing code, or producing a standalone HTML mockup.

Required result

Create one directory whose name ends in .mview. It must contain, at minimum:

<descriptive-name>.mview/
├── mview.json
├── <parser module>
└── <component file>

mview.json, the parser, and the component are three separate artifacts with different responsibilities. An HTML file can be the component when runtime.renderer is "html", but HTML by itself is not an MView. Add resources/ only when the component needs local assets.

If you can write to the workspace, create these files there instead of merely printing them. If you cannot write files, return every artifact in full, clearly labeled by its relative path, with no omitted sections. Do not claim completion until all required artifacts exist.

Required workflow

Locate and inspect the real source. Find the file named by the user, or the exact files selected from a directory. Inspect enough data to determine its actual columns, structure, encoding, missing values, and useful visual treatment. Never invent source fields or sample data. If the source or directory selection is unavailable or ambiguous, ask for its path or a representative sample before generating artifacts.
Choose a package location. Prefer <source-name>.mview/ directly beside a file source. A centralized <workspace>/.mviews/<name>.mview/ package is also valid. Follow the official directory and discovery rules. Every path stored in the manifest must be relative to the MView directory.
Choose a Source Adapter and capability. Inspect the original source, select an adapter that can interpret it, and declare it in source.adapters (or source.files[].adapters for a directory). Then select accepts for the normalized input the parser actually consumes, not just the file extension. Common choices are CSV/XLSX → ["table"], Markdown → ["markdown", "document"], JSON/YAML/XML → ["tree", "structured"], logs → ["log", "text"], and source code → ["code", "text"]. Confirm against the real source that the adapter and normalization yield the information the user asked to view.
Create mview.json. Read the Schema Reference and fetch the canonical JSON Schema before writing the manifest. The schema is authoritative for required properties, enums, patterns, and additionalProperties. Preserve the user's original creation request in prompt; do not replace it with a summary.
Create the parser. Read the Parser Contract. Default-export an async function that transforms normalized input into the JSON-serializable model needed by the component. It must be deterministic, use real source fields, handle expected missing or malformed values, and perform no filesystem reads or arbitrary network access.
Create the component. Read the Component Contract. Render only the parser's returned data plus the supplied settings, source, and resources. Do not read or parse the source in the component. Inspect the workspace and preserve the user's existing visual language, design system, and styles; also prioritize any explicit visual direction in the request. MView examples are references for structure and contracts, not visual templates: do not copy their HTML, CSS, typography, colors, spacing, composition, or browser-default styles. If no visual direction exists, deliberately design a presentation appropriate for the content and distinct from the examples' appearance. Prefer the simplest renderer supported by the target runtime and sufficient for the requested experience: usually html for a portable zero-dependency view, and React or another framework only when justified.
Validate the complete package. Validate mview.json against the canonical schema. Confirm that every declared file exists, all manifest paths resolve relative to the package, the Source Adapter runs against the original source, parser output matches what the component consumes, and no source I/O leaked into the parser or component. Run the adapter and parser with the real normalized input and inspect the resulting data model.
Report the result. State the package path, list the files created, name the chosen capability and renderer, and report the validation performed. Clearly disclose anything you could not validate.

Minimal manifest shape

Use this only as structural orientation. Fetch the canonical schema and adapt values and filenames to the real source and requested view:

{
  "$schema": "https://schemas.carmenlabs.com/mview/v1/schema.json",
  "id": "sales-dashboard",
  "name": "Sales Dashboard",
  "version": "1.0.0",
  "prompt": "Create an MView for ./sales.csv that shows monthly sales and top clients.",
  "runtime": {
    "environment": "web",
    "renderer": "html"
  },
  "accepts": ["table"],
  "source": {
    "path": "../sales.csv",
    "adapters": ["csv-table"]
  },
  "entry": {
    "parser": "./parser.js",
    "component": "./view.html"
  }
}

For a static HTML component, the runtime injects { data, settings, source, resources } as window.mview before inline scripts execute. The component must read window.mview.data; it must not embed invented data or fetch the source. For React or Solid, the component receives the same object as props.

Directory sources

A directory is not implicit filesystem access. Set source.kind to "directory", set the MView-level accepts to include "filesystem", and freeze a non-empty explicit selection in source.files. Each selected path is relative to source.path, unique, and declares its own ordered adapters and accepts. The parser receives the already normalized collection and must not open directory files itself. Do not add content hashes unless you calculate them using the canonical procedure in the Schema Reference.

Non-negotiable rules

Never modify the source file or files.
Never deliver only a standalone visualization or HTML mockup.
Never invent columns, records, filenames, or directory membership.
Never use absolute paths in mview.json.
Never add manifest properties absent from the current schema.
Never let the parser or component bypass the runtime to read source files.
Never let a directory MView consume files outside its explicit source.files selection.
Never use metadata to control rendering; runtime configuration belongs in settings.
Never claim schema conformance if the canonical schema could not be fetched or validation was not run.
Never declare a capability because normalization succeeds mechanically; declare it only when the normalized result carries the information the user asked to view.
Never treat an example's design as part of the MView contract or transfer it to the user's component.

Definition of done

A *.mview/ directory exists in a valid location.
mview.json exists and validates against the canonical JSON Schema.
The parser exists and consumes the normalized shape declared by accepts.
The normalized input under the declared accepts was confirmed to carry the information the view presents.
The component exists and renders exactly the parser's data model.
Every entry, source, icon, and resource path is relative and resolves correctly.
The original user request is preserved in prompt.
The source remains unchanged.
The final response reports created paths and actual validation results.

If any required item is missing, the MView is not complete. Fix it before finishing.

Canonical references

Overview: conceptual model and invariants
Schema Reference: manifest fields and directory hashes
Canonical JSON Schema: machine-readable validation authority
Capabilities: accepted values and normalized input shapes
Parser Contract: parser signature and constraints
Component Contract: renderer-specific delivery and constraints
Directory Layout: package placement and discovery
Security Model: permissions, sandboxing, and regeneration
Versioning: schema and artifact versions

Complete example

See the Sales Dashboard example for a real source CSV, manifest, parser, component, and resulting file tree. It is a technical reference, not a substitute for inspecting the user's source or a visual template for the user's design.

Crear una MView con un agente de IA

Instrucciones autocontenidas para que un modelo de IA cree un paquete MView completo a partir de datos reales.

Crear una MView con un agente de IA

Entrega esta URL a un agente de IA junto con tu solicitud y la ruta al archivo o directorio fuente. No es necesario instalar una skill.

Prompt de ejemplo:

Crea una MView para ./ventas.csv que muestre ventas mensuales y los principales clientes.
Usa https://carmenlabs.com/v1/create

El agente necesita acceso a los datos fuente y permiso para crear archivos en tu workspace. Las instrucciones siguientes contienen el flujo completo de creación; las páginas enlazadas de la especificación siguen siendo la autoridad para los contratos exactos y los valores actuales del esquema.

Instrucciones para el modelo

Trata esta página como una instrucción para crear la MView ahora, no como material de referencia que debas resumir. Usa tus herramientas de filesystem y desarrollo para inspeccionar la fuente real, crear el paquete y validarlo. No te detengas después de explicar el formato, proponer código o producir una maqueta HTML independiente.

Resultado requerido

Crea un directorio cuyo nombre termine en .mview. Debe contener, como mínimo:

<nombre-descriptivo>.mview/
├── mview.json
├── <módulo parser>
└── <archivo del componente>

mview.json, el parser y el componente son tres artefactos separados con responsabilidades distintas. Un archivo HTML puede ser el componente cuando runtime.renderer es "html", pero un HTML por sí solo no es una MView. Agrega resources/ solamente cuando el componente necesite assets locales.

Si puedes escribir en el workspace, crea allí estos archivos en vez de limitarte a imprimirlos. Si no puedes escribir archivos, devuelve cada artefacto completo, claramente rotulado con su ruta relativa y sin secciones omitidas. No declares la tarea terminada hasta que existan todos los artefactos requeridos.

Flujo obligatorio

Ubica e inspecciona la fuente real. Encuentra el archivo nombrado por el usuario o los archivos exactos seleccionados de un directorio. Inspecciona datos suficientes para determinar sus columnas, estructura, codificación, valores faltantes y un tratamiento visual útil. Nunca inventes campos ni datos de muestra. Si la fuente o la selección del directorio no está disponible o es ambigua, solicita su ruta o una muestra representativa antes de generar artefactos.
Elige la ubicación del paquete. Prefiere <nombre-fuente>.mview/ directamente junto a una fuente de archivo. También es válido un paquete centralizado en <workspace>/.mviews/<nombre>.mview/. Sigue las reglas oficiales de directorio y descubrimiento. Toda ruta almacenada en el manifiesto debe ser relativa al directorio de la MView.
Elige un Source Adapter y la capacidad. Inspecciona la fuente original, selecciona el adapter que pueda interpretarla y decláralo en source.adapters (o en source.files[].adapters para una carpeta). Luego selecciona accepts según la entrada normalizada que realmente consume el parser, no solo según la extensión. Opciones comunes: CSV/XLSX → ["table"], Markdown → ["markdown", "document"], JSON/YAML/XML → ["tree", "structured"], logs → ["log", "text"] y código fuente → ["code", "text"]. Antes de fijar una capacidad, confirma contra la fuente real que el adapter y la normalización producen la información que el usuario pidió ver.
Crea mview.json. Lee la Referencia del esquema y obtén el JSON Schema canónico antes de escribir el manifiesto. El esquema es la autoridad para propiedades requeridas, enums, patrones y additionalProperties. Conserva en prompt la solicitud original de creación del usuario; no la reemplaces por un resumen.
Crea el parser. Lee el Contrato del parser. Exporta por defecto una función async que transforme el input normalizado en el modelo JSON serializable que necesita el componente. Debe ser determinista, usar campos reales de la fuente, manejar valores faltantes o inválidos esperables y no realizar lecturas del filesystem ni acceso arbitrario a la red.
Crea el componente. Lee el Contrato del componente. Renderiza solamente el data retornado por el parser junto con settings, source y resources. No leas ni interpretes la fuente desde el componente. Inspecciona el workspace y conserva el lenguaje visual, sistema de diseño y estilos existentes del usuario; prioriza también cualquier indicación visual explícita de su solicitud. Los ejemplos de MView son referencias de estructura y contratos, no plantillas visuales: no copies su HTML, CSS, tipografía, colores, espaciado, composición ni sus estilos por defecto del navegador. Si no existe una dirección visual, diseña deliberadamente una presentación apropiada para el contenido y distinta de la apariencia de los ejemplos. Prefiere el renderer más simple que soporte el runtime objetivo y sea suficiente para la experiencia solicitada: normalmente html para una vista portable y sin dependencias; React u otro framework solo cuando esté justificado.
Valida el paquete completo. Valida mview.json contra el esquema canónico. Confirma que exista cada archivo declarado, que todas las rutas del manifiesto resuelvan en forma relativa al paquete, que el Source Adapter pueda ejecutarse sobre la fuente original, que la salida del parser coincida con lo consumido por el componente y que no se haya filtrado I/O de la fuente al parser o componente. Ejecuta el adapter y el parser con la entrada normalizada real e inspecciona el modelo de datos resultante.
Informa el resultado. Indica la ruta del paquete, enumera los archivos creados, nombra la capacidad y el renderer elegidos e informa qué validaciones ejecutaste. Declara claramente todo lo que no pudiste validar.

Forma mínima del manifiesto

Úsala solo como orientación estructural. Obtén el esquema canónico y adapta valores y nombres de archivos a la fuente real y a la vista solicitada:

{
  "$schema": "https://schemas.carmenlabs.com/mview/v1/schema.json",
  "id": "panel-ventas",
  "name": "Panel de ventas",
  "version": "1.0.0",
  "prompt": "Crea una MView para ./ventas.csv que muestre ventas mensuales y los principales clientes.",
  "runtime": {
    "environment": "web",
    "renderer": "html"
  },
  "accepts": ["table"],
  "source": {
    "path": "../ventas.csv",
    "adapters": ["csv-table"]
  },
  "entry": {
    "parser": "./parser.js",
    "component": "./view.html"
  }
}

Para un componente HTML estático, el runtime inyecta { data, settings, source, resources } como window.mview antes de ejecutar los scripts inline. El componente debe leer window.mview.data; no debe incluir datos inventados ni hacer fetch de la fuente. En React o Solid, el componente recibe el mismo objeto como props.

Fuentes de directorio

Un directorio no implica acceso general al filesystem. Define source.kind como "directory", incluye "filesystem" en el accepts de la MView y congela una selección explícita no vacía en source.files. Cada ruta seleccionada es relativa a source.path, es única y declara su propio adapters y accepts ordenados. El parser recibe la colección ya normalizada y no debe abrir los archivos del directorio. No agregues hashes de contenido a menos que los calcules con el procedimiento canónico de la Referencia del esquema.

Reglas no negociables

Nunca modifiques el archivo o los archivos fuente.
Nunca entregues solamente una visualización independiente o una maqueta HTML.
Nunca inventes columnas, registros, nombres de archivos ni integrantes de un directorio.
Nunca uses rutas absolutas en mview.json.
Nunca agregues propiedades al manifiesto que no existan en el esquema actual.
Nunca permitas que el parser o el componente eviten al runtime para leer archivos fuente.
Nunca permitas que una MView de directorio consuma archivos fuera de su selección explícita source.files.
Nunca uses metadata para controlar el renderizado; la configuración de runtime pertenece en settings.
Nunca afirmes conformidad con el esquema si no pudiste obtener el esquema canónico o no ejecutaste la validación.
Nunca declares una capacidad porque la normalización tiene éxito mecánicamente; decláralo solo cuando el resultado normalizado porta la información que el usuario pidió ver.
Nunca trates el diseño de un ejemplo como parte del contrato MView ni lo transfieras al componente del usuario.

Definición de terminado

Existe un directorio *.mview/ en una ubicación válida.
Existe mview.json y valida contra el JSON Schema canónico.
Existe el parser y consume la forma normalizada declarada por accepts.
Se confirmó que la entrada normalizada bajo el accepts declarado porta la información que la vista presenta.
Existe el componente y renderiza exactamente el modelo de datos del parser.
Todas las rutas de entry, source, íconos y recursos son relativas y resuelven correctamente.
La solicitud original del usuario está conservada en prompt.
La fuente permanece sin cambios.
La respuesta final informa las rutas creadas y los resultados reales de validación.

Si falta cualquier elemento requerido, la MView no está completa. Corrígelo antes de terminar.

Referencias canónicas

Descripción general: modelo conceptual e invariantes
Referencia del esquema: campos del manifiesto y hashes de directorio
JSON Schema canónico: autoridad de validación legible por máquinas
Capacidades: valores aceptados y formas de entrada normalizada
Contrato del parser: firma y restricciones del parser
Contrato del componente: entrega según renderer y restricciones
Estructura de directorios: ubicación y descubrimiento del paquete
Modelo de seguridad: permisos, sandboxing y regeneración
Versionado: versiones del esquema y del artefacto

Ejemplo completo

Consulta el ejemplo del Panel de ventas para ver un CSV fuente real, manifiesto, parser, componente y árbol de archivos resultante. Es una referencia técnica, no un reemplazo para inspeccionar la fuente ni una plantilla visual para el diseño del usuario.