views

name	views
description	Author Mighty views and `view_def` payloads from external repos. Use when creating or updating `/api/views` payloads, `list` or `json_ui` views, component-tree dashboards/galleries, modal detail overlays, or record discussion panels.

Views

Use this skill when an external repo needs to define or update Mighty views without shipping bespoke frontend code.

Core model

• A view is a persisted artifact with presentation metadata plus an optional declarative view_def.
• The current view surface is space-scoped. Create and update views through /api/views using space_id.
• v1 has two built-in view kinds: list and json_ui.
• Use list for straightforward query-backed queues, boards, and tables.
• Use json_ui for composed dashboards, galleries, overlays, editable panels, and split-pane review flows.

Upstream references:

• Primitive: Views
• Views: typed definitions for AI-authored dashboards
• Views: declarative view_def schema (JSON UI + action DSL)
• View kind: json_ui (schema-driven layout renderer)
• JSON UI: collection surfaces, overlays, and embedded record discussions
• View composition: nested ViewRef resolution and safety limits

Constraints

• Keep authored views declarative and allowlisted. Do not assume arbitrary React, script execution, or unrestricted backend calls.
• Bind components only to ACL-scoped replicated data already available through view queries and datasets.
• Treat overlays as view-local state in v1. Do not assume freeform router transitions or nested modal stacks.
• Use only supported action names and component types. If the runtime does not already recognize a primitive, add platform support first instead of inventing schema.

Authoring workflow

1. Confirm the records or typed indexes the view should read from.
2. Choose list or json_ui.
3. Define root queries first, then derive selections and filtered subsets through datasets.
4. Bind UI off named datasets using collection bindings like selected_variant[0].image_url.
5. Keep transient UI state in explicit state_path values.
6. Persist the view_def through /api/views, then iterate from validation/runtime errors instead of adding bespoke code paths.

Practical rules

• Prefer pick datasets for selection state and filter datasets for client-side joins.
• Keep bindings simple and explicit: collection[index].field or collection[*].field.
• For editable record fields, stage user input in local state and then write back with a supported action such as set_field.
• Reach for record_discussion when a selected record needs inline comments or modal discussion.
• Use ViewRef only when a nested view boundary is clearer than one large json_ui tree.

Action baseline

The core declarative action DSL covers:

• set_field
• add_tag / remove_tag
• create_edge / delete_edge
• create_record
• create_message

Do not assume that every JSON UI action is part of this small baseline. Check the runtime's documented action namespace before authoring more specialized actions.

Examples

• Illustration Library style gallery with editable prompt text, modal media detail, and record discussion: see view-def patterns.
• Review-style split pane remains a valid json_ui pattern; keep it on the same query/dataset semantics as component-tree layouts.
• Dashboard summary views should compose reusable collection-backed panels instead of hardcoding product-specific React.