Stats
Actions
Tags
From pigment
Guides creation and editing of Pigment Views (KPI, Grid, Chart, Table, List) with correct pivot semantics, metricsLocation rules, and server-assigned IDs.
How this skill is triggered — by the user, by Claude, or both
Slash command
/pigment:creating-and-editing-pigment-viewsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**Progressive Disclosure Pattern**: This `SKILL.md` provides an overview. Most details live in supporting files.
Progressive Disclosure Pattern: This SKILL.md provides an overview. Most details live in supporting files.
This file alone is often not sufficient
Required workflow:
tool:read_file or tool:grep to access detailed documentationtool:ls, tool:grep, or tool:glob to discover additional resources in this directory (some might not be explicitly mentioned in this file)These notes align the Pigment UI with view creation and edition tools
values (value fields)Each entry describes what appears in the cells :
Value labels in Pivot panel in the UI are different:
metricsLocation (Metric & Table views)API enum (C# MetricsLocation): Columns (1), Rows (2), Pages (3) — which axis carries the metrics in the pivot. Dimensions go under rows, columns, or pages. Metrics are chosen in values; they are not duplicated into the arrays for dimensions. Their axis is set only via metricsLocation.
KPI rule: metricsLocation for a KPI View MUST NOT be Rows. KPIs have no row pivots, so Rows yields a broken layout. Use Columns (default) or Pages.
pivotFieldIdEvery pivot field placed in pages, rows, or columns gets a stable id (GUID) assigned by the server. pivotFieldId in other structures (filters, sorts, etc.) points to that pivot — read it back from the tool:create_view / tool:update_view_pivots response, do not invent it.
listPropertyPath on pivots (grouping / hierarchy)ListPropertyPath is the technical name of properties (e.g. in the UI: Month > Year, Country > Region).
display_type (KPI / Grid / Chart) is not stored on the View; configure it on the Board widget.Value and pivot ids — Assigned by the server. For a NEW pivot/value, omit id. To KEEP an existing one, echo back the id from a prior tool:create_view / tool:update_view_* / tool:get_view response. Never invent UUIDs.
Same dimension on Pages and on Rows/Columns is SUPPORTED — When the user asks to "put X on Pages", add to Pages without removing X from Rows/Columns. Page selectors then narrow which modalities appear on the row/column axis. Do not treat this as a conflict. See view_components.md for OK patterns vs. anti-patterns.
"Filter" from users → Page Selector first — Restricting to a dimension item (Year, Country, Version, …) = pages + default item, not filters[]. View Filters only for top-N-by-metric, exclusion, or logic Page Selectors cannot express. See view_filtering.md.
New View (greenfield) — Two-step flow:
tool:create_view. Leave pivotLayout null to let the server build a sensible default layout for the underlying block. To override, send a complete pivotLayout with all three axes (rows, columns, pages) populated — each entry is a simplified pivot seed (dimensionId + optional listPropertyPath); use an empty array for an axis with no pivot. Half-specified layouts are rejected. Values and hidden-dim aggregations are created with sensible defaults; refine them in step 2 if needed.tool:update_view_pivots, tool:update_view_values (and the other update_view_* tools) to refine the configuration. None of those refinements are accepted by tool:create_view.Editing an existing View — Use the field-specific variants directly on the View id:
showValueAsConfiguration) → tool:update_view_values. Echo back existing value ids to keep them stable.tool:update_view_pivots.tool:update_view_filters. Sorts → tool:update_view_sorts. Chart config → tool:update_view_chart_config.tool:update_view.If a Draft was auto-created, the agent should:
tool:update_view_widget_overrides so only this user sees itBulk-save protocol if tool:save_draft_views is available — after creating or editing one or more Draft Views:
tool:save_draft_views once with all draft view IDs.When editing a View in the context of a widget on a Board, you must:
Name (first signal) — "View 1" and similar are often placeholders. Prefer create_view with a real name and pivots aligned to this widget and other widgets on the same board unless the existing View already fits.
Shared / external View (other users, other boards) — Prefer Draft (or a new View) before overwriting something others rely on or displayed in another board, except if asked explicitely.
Table views — per-view metrics — When adding or removing metrics on Table block views, call tool:update_view_values with the full desired value list: add a value entry for new metrics, remove value entries that are not relevant. Prefer removal over hiding — hidden metrics may still compute. Keep a metric hidden (displayed: false) only when the view still depends on it, such as for value-field filtering, sort-by-metric-value, or as an advanced-aggregator operand (ratio, growth, etc.). Do not plan a separate step to update the Table block's metric membership first. Do not add every table metric to each view and hide the rest; configure only the metrics each view should show.
A View is how a Block (Metric, List, Table) is shown: pivots, filters, sort, display. One Block, many Views.
A private working copy to preview edits before they hit an existing view. On boards, use a Draft + widget overrides when changing the live View behind a widget—see view_widgets.md. Not a substitute for create_view when you need a new View. Save via bulk-save protocol — list the draft names, wait for user confirmation, then call tool:save_draft_views once with all draft view IDs
tool:get_block_views helps spot candidates; there is no hard rule to “find similar views” before you create. Creating is normal when names are generic or pivots do not match the board. Details: relevant_views.md, view_design_process.md.
Grid — no widget suffix. Chart — add chart type, e.g. … - Waterfall. KPI — suffix - KPI.
Must read: view_design_process.md.
npx claudepluginhub gopigment/ai-plugins --plugin pigmentSearches MemPalace before answering questions about past work, people, projects, or prior decisions. Returns verbatim stored content instead of guessing from model memory.
Guides Payload CMS config (payload.config.ts), collections, fields, hooks, access control, APIs. Debugs validation errors, security, relationships, queries, transactions, hook behavior.
Implements vector databases with Pinecone, Weaviate, Qdrant, Milvus, pgvector for semantic search, RAG, recommendations, and similarity systems. Optimizes embeddings, indexing, and hybrid search.