Powerbi Modeling

GitHubOfficialFirst committed by AlahmadiQ8Distributed by GitHub

Skill
Tool integration
Data and AI
MIT
No issues found

From the author

Power BI semantic modeling assistant for building optimized data models. Use when working with Power BI semantic models, creating measures, designing star schemas, configuring relationships, implementing RLS, or optimizing model performance. Triggers on queries about DAX calculations, table relationships, dimension/fact table design, naming conventions, model documentation, cardinality, cross-filter direction, calculation groups, and data model best practices. Always connects to the active model first using power-bi-modeling MCP tools to understand the data structure before providing guidance.

— the description by AlahmadiQ8

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The Power BI Modeling assistant helps users design and maintain efficient semantic models. It enforces Microsoft best practices by connecting directly to active models to analyze structure, relationships, and DAX measures. The skill provides guidance on star schema design, performance tuning, row-level security, and naming conventions, ensuring models are well-documented and optimized for report performance.

What it does

Connects to active Power BI models to inspect tables, relationships, and measures.
Provides guidance on designing star schemas and configuring model relationships.
Assists in writing and optimizing DAX measures and calculated columns.
Implements row-level security and model documentation standards.
Offers performance tuning advice, including data reduction and column optimization.
Validates models against established naming conventions and best practices.

When to use it

When creating a new Power BI semantic model from scratch.
When troubleshooting performance issues in an existing model.
When needing to define complex DAX measures or calculation groups.
When standardizing naming conventions and documentation across a model.
When configuring security roles or complex relationship cardinalities.

Advantages

Ensures adherence to official Microsoft Power BI modeling best practices.
Automates the inspection of model health and structure.
Reduces manual effort in documenting and organizing semantic models.
Provides actionable performance optimization techniques for DAX and data structures.
Maintains consistency through standardized naming and folder organization.

Usage examples

“Create a new measure for Total Sales with a currency format and description.”: The agent will use measure_operations to create the 'Total Sales' measure with the specified expression, format string, and documentation.
“Analyze my current model and suggest performance improvements.”: The agent will list tables, relationships, and measures, then identify opportunities like removing unused columns or optimizing relationship cardinalities.
“How should I name my dimension and fact tables?”: The agent will provide the recommended naming conventions, such as using singular nouns for dimensions and business process names for fact tables.
“Create a relationship between my Sales and Customer tables.”: The agent will verify the columns and use relationship_operations to establish a one-to-many relationship with the correct cross-filtering behavior.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/github/powerbi-modeling/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip powerbi-modeling.zip -d .agents/skills

Documentation by AlahmadiQ8

Power BI Semantic Modeling

Guide users in building optimized, well-documented Power BI semantic models following Microsoft best practices.

When to Use This Skill

Use this skill when users ask about:

Creating or optimizing Power BI semantic models
Designing star schemas (dimension/fact tables)
Writing DAX measures or calculated columns
Configuring table relationships (cardinality, cross-filter)
Implementing row-level security (RLS)
Naming conventions for tables, columns, measures
Adding descriptions and documentation to models
Performance tuning and optimization
Calculation groups and field parameters
Model validation and best practice checks

Trigger phrases: "create a measure", "add relationship", "star schema", "optimize model", "DAX formula", "RLS", "naming convention", "model documentation", "cardinality", "cross-filter"

Prerequisites

Required Tools

Power BI Modeling MCP Server: Required for connecting to and modifying semantic models
- Enables: connection_operations, table_operations, measure_operations, relationship_operations, etc.
- Must be configured and running to interact with models

Optional Dependencies

Microsoft Learn MCP Server: Recommended for researching latest best practices
- Enables: microsoft_docs_search, microsoft_docs_fetch
- Use for complex scenarios, new features, and official documentation

Workflow

1. Connect and Analyze First

Before providing any modeling guidance, always examine the current model state:

1. List connections: connection_operations(operation: "ListConnections")
2. If no connection, check for local instances: connection_operations(operation: "ListLocalInstances")
3. Connect to the model (Desktop or Fabric)
4. Get model overview: model_operations(operation: "Get")
5. List tables: table_operations(operation: "List")
6. List relationships: relationship_operations(operation: "List")
7. List measures: measure_operations(operation: "List")

2. Evaluate Model Health

After connecting, assess the model against best practices:

Star Schema: Are tables properly classified as dimension or fact?
Relationships: Correct cardinality? Minimal bidirectional filters?
Naming: Human-readable, consistent naming conventions?
Documentation: Do tables, columns, measures have descriptions?
Measures: Explicit measures for key calculations?
Hidden Fields: Are technical columns hidden from report view?

3. Provide Targeted Guidance

Based on analysis, guide improvements using references:

Star schema design: See STAR-SCHEMA.md
Relationship configuration: See RELATIONSHIPS.md
DAX measures and naming: See MEASURES-DAX.md
Performance optimization: See PERFORMANCE.md
Row-level security: See RLS.md

Quick Reference: Model Quality Checklist

Area	Best Practice
Tables	Clear dimension vs fact classification
Naming	Human-readable: `Customer Name` not `CUST_NM`
Descriptions	All tables, columns, measures documented
Measures	Explicit DAX measures for business metrics
Relationships	One-to-many from dimension to fact
Cross-filter	Single direction unless specifically needed
Hidden fields	Hide technical keys, IDs from report view
Date table	Dedicated marked date table

MCP Tools Reference

Use these Power BI Modeling MCP operations:

Operation Category	Key Operations
`connection_operations`	Connect, ListConnections, ListLocalInstances, ConnectFabric
`model_operations`	Get, GetStats, ExportTMDL
`table_operations`	List, Get, Create, Update, GetSchema
`column_operations`	List, Get, Create, Update (descriptions, hidden, format)
`measure_operations`	List, Get, Create, Update, Move
`relationship_operations`	List, Get, Create, Update, Activate, Deactivate
`dax_query_operations`	Execute, Validate
`calculation_group_operations`	List, Create, Update
`security_role_operations`	List, Create, Update, GetEffectivePermissions

Common Tasks

Add Measure with Description

measure_operations(
  operation: "Create",
  definitions: [{
    name: "Total Sales",
    tableName: "Sales",
    expression: "SUM(Sales[Amount])",
    formatString: "$#,##0",
    description: "Sum of all sales amounts"
  }]
)

Update Column Description

column_operations(
  operation: "Update",
  definitions: [{
    tableName: "Customer",
    name: "CustomerKey",
    description: "Unique identifier for customer dimension",
    isHidden: true
  }]
)

Create Relationship

relationship_operations(
  operation: "Create",
  definitions: [{
    fromTable: "Sales",
    fromColumn: "CustomerKey",
    toTable: "Customer",
    toColumn: "CustomerKey",
    crossFilteringBehavior: "OneDirection"
  }]
)

When to Use Microsoft Learn MCP

Research current best practices using microsoft_docs_search for:

Latest DAX function documentation
New Power BI features and capabilities
Complex modeling scenarios (SCD Type 2, many-to-many)
Performance optimization techniques
Security implementation patterns

Files

ATTRIBUTION.mdAdded by AutoGineer869 B
LICENSELicence file added by AutoGineer1.0 KiB
SKILL.md5.8 KiB
references/MEASURES-DAX.md4.9 KiB
references/PERFORMANCE.md5.3 KiB
references/RELATIONSHIPS.md3.4 KiB
references/RLS.md5.3 KiB
references/STAR-SCHEMA.md3.1 KiB

references/MEASURES-DAX.md

DAX Measures and Naming Conventions

Naming Conventions

General Rules

Use human-readable names (spaces allowed)
Be descriptive: Total Sales Amount not TSA
Avoid abbreviations unless universally understood
Use consistent capitalization (Title Case recommended)
Avoid special characters except spaces

Table Naming

Type	Convention	Example
Dimension	Singular noun	Customer, Product, Date
Fact	Business process	Sales, Orders, Inventory
Bridge	Combined names	CustomerAccount, ProductCategory
Measure Table	Underscore prefix	_Measures, _KPIs

Column Naming

Type	Convention	Example
Keys	Suffix with "Key" or "ID"	CustomerKey, ProductID
Dates	Suffix with "Date"	OrderDate, ShipDate
Amounts	Descriptive with unit hint	SalesAmount, QuantitySold
Flags	Prefix with "Is" or "Has"	IsActive, HasDiscount

Measure Naming

Type	Convention	Example
Aggregations	Verb + Noun	Total Sales, Count of Orders
Ratios	X per Y or X Rate	Sales per Customer, Conversion Rate
Time Intelligence	Period + Metric	YTD Sales, PY Total Sales
Comparisons	Metric + vs + Baseline	Sales vs Budget, Growth vs PY

Explicit vs Implicit Measures

Always Create Explicit Measures For:

Key business metrics users will query
Complex calculations with filter manipulation
Measures used in MDX (Excel PivotTables)
Controlled aggregation (prevent sum of averages)

Implicit Measures (Column Aggregations)

Acceptable for simple exploration
Set correct SummarizeBy property:
- Amounts: Sum
- Keys/IDs: None (Do Not Summarize)
- Rates/Prices: None or Average

Measure Patterns

Basic Aggregations

Total Sales = SUM(Sales[SalesAmount])
Order Count = COUNTROWS(Sales)
Average Order Value = DIVIDE([Total Sales], [Order Count])
Distinct Customers = DISTINCTCOUNT(Sales[CustomerKey])

Time Intelligence (Requires Date Table)

YTD Sales = TOTALYTD([Total Sales], 'Date'[Date])
MTD Sales = TOTALMTD([Total Sales], 'Date'[Date])
PY Sales = CALCULATE([Total Sales], SAMEPERIODLASTYEAR('Date'[Date]))
YoY Growth = DIVIDE([Total Sales] - [PY Sales], [PY Sales])

Percentage Calculations

Sales % of Total = 
DIVIDE(
    [Total Sales],
    CALCULATE([Total Sales], REMOVEFILTERS(Product))
)

Margin % = DIVIDE([Gross Profit], [Total Sales])

Running Totals

Running Total = 
CALCULATE(
    [Total Sales],
    FILTER(
        ALL('Date'),
        'Date'[Date] <= MAX('Date'[Date])
    )
)

Column References

Best Practice: Always Qualify Column Names

// GOOD - Fully qualified
Sales Amount = SUM(Sales[SalesAmount])

// BAD - Unqualified (can cause ambiguity)
Sales Amount = SUM([SalesAmount])

Measure References: Never Qualify

// GOOD - Unqualified measure
YTD Sales = TOTALYTD([Total Sales], 'Date'[Date])

// BAD - Qualified measure (breaks if home table changes)
YTD Sales = TOTALYTD(Sales[Total Sales], 'Date'[Date])

Documentation

Measure Descriptions

Always add descriptions explaining:

What the measure calculates
Business context/usage
Any important assumptions

measure_operations(
  operation: "Update",
  definitions: [{
    name: "Total Sales",
    tableName: "Sales",
    description: "Sum of all completed sales transactions. Excludes returns and cancelled orders."
  }]
)

Format Strings

Data Type	Format String	Example Output
Currency	$#,##0.00	$1,234.56
Percentage	0.0%	12.3%
Whole Number	#,##0	1,234
Decimal	#,##0.00	1,234.56

Display Folders

Organize measures into logical groups:

measure_operations(
  operation: "Update",
  definitions: [{
    name: "YTD Sales",
    tableName: "_Measures",
    displayFolder: "Time Intelligence\\Year"
  }]
)

Common folder structure:

_Measures
├── Sales
│   ├── Total Sales
│   └── Average Sale
├── Time Intelligence
│   ├── Year
│   │   ├── YTD Sales
│   │   └── PY Sales
│   └── Month
│       └── MTD Sales
└── Ratios
    ├── Margin %
    └── Conversion Rate

Variables for Performance

Use variables to:

Avoid recalculating the same expression
Improve readability
Enable debugging

Gross Margin % = 
VAR TotalSales = [Total Sales]
VAR TotalCost = [Total Cost]
VAR GrossProfit = TotalSales - TotalCost
RETURN
    DIVIDE(GrossProfit, TotalSales)

Validation Checklist

[ ] All key business metrics have explicit measures
[ ] Measures have clear, descriptive names
[ ] Measures have descriptions
[ ] Appropriate format strings applied
[ ] Display folders organize related measures
[ ] Column references are fully qualified
[ ] Measure references are not qualified
[ ] Variables used for complex calculations

Requirements and compatibility

Written for: GitHub Copilot

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

First committed by

AlahmadiQ8

Publisher

GitHub (Official)

Distributed by

GitHub

Source

github/awesome-copilot · skills/powerbi-modeling · commit 797337f

Licence

MIT License (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

Contributors