From pigment
Guides modeling patterns for Pigment planning domains: FP&A, OPEX, Workforce, Sales Performance, Supply Chain, and Financial Consolidation.
How this skill is triggered — by the user, by Claude, or both
Slash command
/pigment:solving-specific-use-casesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Pigment is a business planning platform used across multiple domains. Each domain has its own modeling patterns, dimensions, and reporting needs, but they all share Pigment's core building blocks: lists, metrics, formulas, tables, and boards.
finance_nexus_financial_statements.mdfx_currency_conversion.mdopex_forecasting_planning_methods_engine.mdopex_planning_application_architecture.mdworkforce_planning_architecture_patterns.mdworkforce_planning_cards_mapped_dimensions.mdworkforce_planning_changelog_overrides.mdworkforce_planning_snapshot_spread.mdPigment is a business planning platform used across multiple domains. Each domain has its own modeling patterns, dimensions, and reporting needs, but they all share Pigment's core building blocks: lists, metrics, formulas, tables, and boards.
This skill introduces the five primary use cases and explains what each one typically involves so the agent can orient itself when helping users build or extend a model. The list of patterns is not complete.
Read this skill when:
Planning-cycle topics (Version Dimension, Budget vs Actual, Forecast, Reforecast, switchover, Actual/Plan layering, scenarios, snapshots) are NOT covered here. They are owned by
skill:planning-cycles-pigment-applications. Most patterns below (Centralized Reporting Metric, OPEX, Workforce, FX) assume a Version Dimension already exists; consult that skill before building the planning-cycle layer of the model.
Pattern #1 — Centralized Financial Reporting Metric (Nexus): The recommended approach is to use a centralizing metric that aggregates upstream calculations, maps them to a reporting structure (e.g. a Chart of Accounts), and serves as the sole source of truth for financial statement boards and tables. It blends multiple data sources into one single metric with an Account dimension. This decouples reporting from model internals and provides a clean security boundary. Only use for financial reporting (P&L, Balance Sheet, Cash Flow), not for operational models. Required reading for this pattern: Centralizing Financial Reporting Metric (Nexus Pattern)
Pattern #2 — OPEX Planning Application Architecture: Overall structure of a driver-based OPEX planning app: data foundation (PULL layer from Library), configuration layer (version windows, account scope), output pipeline (OUT_FC → ACT+FC → Push), folder structure, and naming conventions (INP_, CALC_, OUT_, PULL_, Push_). Load when building the overall structure of an OPEX planning app or working on its data, configuration, or output layers. For forecasting method formulas and how to add new methods, see Pattern #3. Required reading for this pattern: OPEX Planning – Architecture & Patterns
Pattern #3 — OPEX Forecasting Methods & Engine: Implementation reference for the OPEX forecasting engine internals. Contains: method formula patterns and parameters, YoY and blank-handling modifiers, Actual vs Plan window interactions, and the step-by-step procedure for adding new methods. Load when adding, modifying, or debugging individual forecasting methods and their parameters. Required reading for this pattern: OPEX Planning – Forecasting Methods & Engine
Pattern #4 — FX Currency Conversion (Hub): Centralized, version-aware FX engine in a dedicated Hub app. Dimensions: Currency, FX Rate Types (AVG for P&L, END for Balance Sheet), Reporting Currency (Local, Group). Layers: FX_01 (raw input by Version) → FX_02 (fill-forward if needed) → Push_DH_FX_Entity Currencies (entity → currency mapping) → Push_DH_FX_FX Rates (only metric referenced by P&L/BS). Use when building or connecting multi-currency models (Nexus, OPEX, Workforce, consolidation). Required reading for this pattern: FX Currency Conversion (Hub pattern)
Pattern #1 — Application Architecture & Patterns: Full blueprint for employee-based workforce planning: layered metric architecture (Data → Card → Stats → Comp → Push/KPI), dimension roles, EE + TBH data flows, override-first staging, naming conventions, and folder structure. Load when building or extending a workforce planning app end-to-end. Required reading for this pattern: Workforce Planning – Architecture & Patterns
Pattern #2 — Workforce Cards & Mapped Dimensions: The 4.0 layer that unifies Existing Employees and To-Be-Hired into a single Workforce dimension, with card metrics (WF_Card_Entity, WF_Card_Department, etc) and mapped-dimension reporting via BY: -> WF_Card_…. Load when you need to consolidate two populations into one workforce view or report by Entity/Department without adding those as structural dimensions.
Required reading for this pattern: Workforce Planning – Cards & Mapped Dimensions
Pattern #3 — Changelog to Override Metrics: Models discrete change requests (transfers, salary updates, term dates) as Changelog dimension rows, projects them into override metrics at planning grain, and applies override-first staging. Load when users submit change requests with effective dates and an approval workflow. Required reading for this pattern: Workforce Planning – Changelog to Override Metrics
Pattern #4 — Snapshot Spread Logic: Bridges snapshot-based source data (e.g. HRIS with sparse load months) to a dense planning grid (Version × Employee × Month). Covers snapshot selection, FILLFORWARD propagation, history-vs-plan toggle, and version windows. Load when the source provides as-of snapshots and planning needs values on every month. Required reading for this pattern: Workforce Planning – Snapshot Spread Logic
Pattern to be added Use your general knowledge to answer questions on this use case
Pattern to be added Use your general knowledge to answer questions on this use case
Pattern to be added Use your general knowledge to answer questions on this use case
skill:modeling-pigment-applications (dimensions, folder structure, Push/Pull)skill:planning-cycles-pigment-applications -- always use this when a use case involves a Version Dimension, Budget vs Actual, Forecast, Reforecast, switchover, or Actual/Plan layering (most FP&A, OPEX, and Workforce patterns do)skill:writing-pigment-formulas (BY modifier, aggregation functions)skill:optimizing-pigment-performance (large aggregation optimization)npx claudepluginhub gopigment/ai-plugins --plugin pigmentGuides implementation of planning cycles in Pigment applications: Version Dimensions, Native Scenarios, and Snapshots for budgeting, forecasting, and actual-vs-plan analysis.
Develops SAP Analytics Cloud planning apps including models, data/multi-actions, versions, workflows, JS scripts, APIs, forecasting, Datasphere/BPC integration, value driver trees.
Builds 3-5 year financial models with revenue projections, cost structures, cash flow analysis, and scenario planning for early-stage startups.