mcpField
S
standardize-naming-conventions

standardize-naming-conventions

github.com/data-goblinData & databases1.1k54 installsUpdated today
Repository

About standardize-naming-conventions

An interactive skill for auditing and standardizing names in Power BI semantic models stored as TMDL. It helps model owners align tables, measures, columns, and display folders with business terminology while checking cross-file references and downstream report impact.

Key features

  1. 01Scan TMDL model naming patterns
  2. 02Collect business terminology and standards
  3. 03Review proposed renames before changes
  4. 04Update DAX and relationship references
  5. 05Validate syntax and remaining references

Use cases

  1. 01Audit a semantic model for inconsistent names
  2. 02Standardize metric names with business terms
  3. 03Rename fields while checking model references

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/data-goblin/power-bi-agentic-development --skill standardize-naming-conventions

After installing, type/standardize-naming-conventionsin Claude Code to confirm it loaded.

Bundled filesreferences/naming-rules.md

Details

From the project README

Standardize Naming Conventions

Interactive workflow for auditing and standardizing naming conventions in Power BI semantic models stored as TMDL files. Ensures tables, columns, measures, and display folders follow human-readable, consistent, business-aligned naming standards.

Primary Workflow

Phase 1: Discover the Model

Locate the TMDL files. Ask the user for the path to the .SemanticModel/definition/ directory if not obvious from context. Then scan the model structure:

# Count tables and get an overview
ls <path>/tables/*.tmdl

Read all table TMDL files to build a complete picture of current naming patterns. Focus on:

  • Table names (check for DIM_, FACT_, or other technical prefixes)
  • Measure names (check for abbreviations, programming conventions, inconsistent syntax)
  • Column names (check for CamelCase, snake_case, abbreviations)
  • Display folder structure (check for organization and consistency)
  • Presence of descriptions (/// comments)
Phase 2: Understand Business Context

CRITICAL: Do not rename anything without understanding the business terminology.

Use AskUserQuestion to gather context:

  1. Business terminology: "What terminology does your organization use for key metrics? For example, do you call it Revenue, Turnover, Sales, or Gross Sales?"
  2. Existing conventions: "Do you have any documented naming conventions or standards already?"
  3. Period conventions: "How do you typically refer to prior periods? (e.g., 1YP, PY, Prior Year, Last Year)"
  4. Unit conventions: "How do you typically express units in measure names? (e.g., parentheses like (%), (Value), (Quantity))"
  5. Downstream impact: "Are there downstream reports connected to this model that would need visual rebinding after renaming?"

Adapt the naming rules to the user's business context. The rules in references/naming-rules.md are defaults -- override them when the user's organization has established conventions.

Phase 3: Audit and Report

Before making changes, produce an audit report. Present a markdown table showing each proposed rename:

| Object Type | Current Name | Proposed Name | Issues Found |
|-------------|-------------|---------------|-------------|
| Table | FACT_Invoices | Invoices | Technical prefix |
| Measure | NetSls | Net Sales | CamelCase, abbreviation |
| Column | shp_dt | Ship Date | snake_case, abbreviation |

Group findings by issue type:

  • Programming conventions: CamelCase, snake_case, UPPER_CASE
  • Abbreviations/acronyms: Shortened or opaque names
  • Inconsistent syntax: Mixed period, unit, or aggregation patterns
  • Technical prefixes: DIM_, FACT_, STG_ on tables
  • Missing descriptions: Objects without /// docstrings
  • Disorganized folders: Missing or flat display folder hierarchy

Ask the user to confirm or adjust the proposed renames before proceeding.

Phase 4: Apply Changes

After user approval, edit the TMDL files. For each table file:

  1. Rename the table (if needed): Change the table declaration
  2. Rename measures: Change measure names in their declarations. IMPORTANT: Also update all internal DAX references to renamed measures using [Old Name] -> [New Name] patterns across ALL table files in the model
  3. Rename columns: Change column names in their declarations. IMPORTANT: Also update DAX references using 'Table'[Old Column] -> 'Table'[New Column] across ALL table files
  4. Reorganize display folders: Add or restructure displayFolder: properties
  5. Add descriptions: Add /// comments for measures and columns that lack them
  6. Update relationship references: Check relationships.tmdl for renamed tables/columns

Cross-file reference updates are critical. When renaming a measure or column, search the entire definition/ directory for all references:

# Find all references to a renamed measure
rg "OldMeasureName" <path>/definition/tables/
rg "OldMeasureName" <path>/definition/relationships.tmdl
Phase 5: Validate

After applying changes, verify:

  1. All TMDL files still parse correctly (no syntax errors)
  2. No orphaned references to old names remain in any file
  3. Display folders are consistent across tables
  4. Descriptions are present on all visible measures and columns

Run a final search to check for any missed references:

# Check for any remaining old names
rg -n "old_name_pattern" <path>/definition/

Naming Convention Rules

Consult references/naming-rules.md for the complete rule set including:

  • Human-readable name requirements
  • Abbreviation and acronym rules
  • Technical prefix rules
  • Aggregation, unit, and period syntax standards
  • Display folder organization patterns
  • Measure name construction order: [Aggregation] [Base Name] [Period] ([Unit])
  • Column naming patterns

Key Anti-Patterns to Detect

Quick-reference checklist for the most common issues:

Anti-PatternRuleExample Fix
snake_caseUse spacesnet_sales -> Net Sales
CamelCaseUse spacesNetSales -> Net Sales
UPPER_CASEUse spacesTOTAL_COST -> Total Cost
AbbreviationsSpell outDel. Mrgn -> Delivery Margin
Opaque acronymsSpell outTFS -> Total Freight Surcharge
Technical prefixRemoveFACT_Orders -> Orders
Inconsistent periodsStandardizeLY/PY/Last Year -> 1YP
Inconsistent unitsStandardizepct/%/(%) -> (%)
Missing descriptionsAdd/// docstrings on all visible objects
Flat foldersOrganizeNumbered hierarchy with subfolders

Downstream Report Impact

WARNING: Renaming model objects breaks downstream report visuals that reference those fields. After renaming:

  1. Identify all connected reports (.pbir files or Power BI Service reports)
  2. Rebind visuals to use the new field names
  3. Repair each report with pbir fields replace or pbir fields replace-table; never edit report JSON directly

Always warn the user about this before applying renames. If downstream reports exist, consider:

  • Making a backup of the model before changes
  • Planning a rebinding session after the rename
  • Using a C# script in Tabular Editor to batch-rename with rebinding

Additional Resources

Reference Files
  • references/naming-rules.md -- Complete naming convention rules with detection patterns, anti-pattern tables, and the measure name construction order
Fetching Docs

To retrieve current semantic model and TMDL reference docs, use microsoft_docs_search + microsoft_docs_fetch (MCP) if available, otherwise mslearn search + mslearn fetch (CLI). Search based on the user's request and run multiple searches as needed to ensure sufficient context before proceeding.

Comments

Markdown supported