@luquimbo/bi-superpowers 1.0.0 → 1.1.1

package/src/content/skills/data-modeling.md

@@ -22,56 +22,60 @@ Best practices for designing semantic models in Power BI.
 
 ### Fact Tables
 - Contain measurable events/transactions
+- **Plural names** (multiple events): `Sales`, `Orders`, `Transactions`
+- **No `Fact_` prefix** — that's developer jargon, users see this in the model
 - Granularity: one row per event/transaction
-- Include foreign keys to dimension tables
-- Include numeric measures (Amount, Quantity, etc.)
+- Include foreign keys to dimension tables (hidden from report view)
+- Hide raw numeric columns; expose them through explicit measures
 
 ```
-Fact_Sales
-├── SalesID (PK)
-├── DateKey (FK)
-├── ProductKey (FK)
-├── CustomerKey (FK)
-├── StoreKey (FK)
-├── Quantity
-├── UnitPrice
-└── TotalAmount
+Sales                              ← plural, business name, no prefix
+├── SalesKey (PK, hidden)
+├── DateKey (FK, hidden)
+├── ProductKey (FK, hidden)
+├── CustomerKey (FK, hidden)
+├── StoreKey (FK, hidden)
+├── Quantity (hidden, exposed via [Quantity Sold] measure)
+├── Unit Price (hidden, used in measures)
+└── Sales Amount (hidden, used in [Sales] measure)
 ```
 
 ### Dimension Tables
 - Contain descriptive attributes
-- Include surrogate key (integer PK)
+- **Singular names** (describes one entity): `Customer`, `Product`, `Date`
+- **No `Dim_` prefix** — users see this name
+- Include surrogate key (integer PK, hidden)
 - Denormalized for simplicity
 - Include business key for lookups
 
 ```
-Dim_Product
-├── ProductKey (PK, surrogate)
-├── ProductID (business key)
-├── ProductName
+Product                            ← singular, business name, no prefix
+├── ProductKey (PK, surrogate, hidden)
+├── Product ID (business key, visible)
+├── Product Name
 ├── Category
 ├── Subcategory
 ├── Brand
-└── UnitCost
+└── Unit Cost
 ```
 
 ### Date Dimension
-Essential for time intelligence. Mark as Date Table in Power BI.
+Essential for time intelligence. Mark as Date Table in Power BI. Singular: `Date`, never `Dates` or `Dim_Date`.
 
 ```
-Dim_Date
-├── DateKey (PK, YYYYMMDD integer)
+Date                               ← singular, no prefix
+├── DateKey (PK, YYYYMMDD integer, hidden)
 ├── Date (actual date)
 ├── Year
 ├── Quarter
 ├── Month
-├── MonthName
+├── Month Name
 ├── Week
-├── DayOfWeek
-├── DayName
-├── IsWeekend
-├── IsHoliday
-└── FiscalYear (if different from calendar)
+├── Day of Week
+├── Day Name
+├── Is Weekend
+├── Is Holiday
+└── Fiscal Year (if different from calendar)
 ```
 
 ## Relationship Best Practices
@@ -117,55 +121,62 @@ Option 2: Duplicate dimension tables (clearer but redundant)
 
 ## Naming Conventions
 
-| Element | Convention | Example |
-|---------|------------|---------|
-| Fact tables | `Fact_` prefix | `Fact_Sales`, `Fact_Inventory` |
-| Dimension tables | `Dim_` prefix | `Dim_Product`, `Dim_Customer` |
-| Bridge tables | `Bridge_` prefix | `Bridge_CustomerProduct` |
-| Foreign keys | Match dimension key name | `ProductKey`, `CustomerKey` |
-| Measures | Business-friendly names | `Total Sales`, `Avg Order Value` |
+**Core principle:** user-visible names speak business language, technical elements stay hidden. No `dim`, `fact`, `tbl` prefixes — those leak SQL jargon into the user experience.
+
+| Element | Convention | Example | Anti-Pattern |
+|---------|------------|---------|--------------|
+| Fact tables | Plural, business name | `Sales`, `Orders`, `Transactions` | `Fact_Sales`, `fct_sales` |
+| Dimension tables | Singular, business name | `Customer`, `Product`, `Date` | `Dim_Customer`, `dim_customers` |
+| Bridge tables | `Bridge` prefix | `Bridge Customer Region` | `BridgeCustomerRegion` |
+| Foreign keys | `[Entity]Key`, hidden | `ProductKey`, `CustomerKey` | `prod_id`, `FK_Product` |
+| Surrogate PK | `[Entity]Key`, hidden | `CustomerKey` | `ID`, `pk_customer` |
+| Business key | `[Entity] ID` or `Code` | `Customer ID`, `Product Code` | `BusinessKey` |
+| Attribute columns | Natural language | `First Name`, `Order Date` | `FrstNm`, `OrdDt` |
+| Measures | Auto-explicative, no prefix | `Sales`, `Margin %`, `Sales YTD` | `Total Sales`, `Sum of Sales` |
+
+See `/governance` for the complete naming guide.
 
 ## Common Patterns
 
 ### Many-to-Many with Bridge Table
 ```
-Dim_Customer ──(1:*)── Bridge_CustomerProduct ──(*:1)── Dim_Product
+Customer ──(1:*)── Bridge Customer Product ──(*:1)── Product
 ```
 
 ### Slowly Changing Dimensions (SCD)
 ```
 Type 1: Overwrite (no history)
 Type 2: Add new row with version tracking
-  - StartDate, EndDate, IsCurrent flag
+  - Start Date, End Date, Is Current flag
 
-Dim_Customer_SCD2
-├── CustomerKey (surrogate, unique per version)
-├── CustomerID (business key)
-├── CustomerName
+Customer (SCD2)
+├── CustomerKey (surrogate, unique per version, hidden)
+├── Customer ID (business key)
+├── Customer Name
 ├── Address
-├── StartDate
-├── EndDate
-└── IsCurrent
+├── Start Date
+├── End Date
+└── Is Current
 ```
 
 ### Junk Dimension (Low-Cardinality Flags)
 Combine multiple low-cardinality attributes:
 ```
-Dim_OrderFlags
-├── OrderFlagKey
-├── IsRush
-├── IsGift
-├── IsOnline
-└── PaymentType
+Order Flags
+├── OrderFlagKey (hidden)
+├── Is Rush
+├── Is Gift
+├── Is Online
+└── Payment Type
 ```
 
 ### Degenerate Dimension
 Attributes stored in fact table (no separate dimension):
 ```
-Fact_Sales
+Sales
 ├── ...
-├── InvoiceNumber    (degenerate dimension)
-├── OrderNumber      (degenerate dimension)
+├── Invoice Number    (degenerate dimension)
+├── Order Number      (degenerate dimension)
 └── ...
 ```
 
@@ -191,9 +202,12 @@ Fact_Sales
 
 ## Model Validation Checklist
 
+- [ ] No technical prefixes (`Dim_`, `Fact_`, `tbl_`)
+- [ ] Dimensions are singular (`Customer`), facts are plural (`Sales`)
+- [ ] Foreign keys hidden from report view
+- [ ] Sumable source columns hidden (only explicit measures visible)
 - [ ] All relationships are single-direction (except where required)
 - [ ] Date table marked as Date Table
-- [ ] Foreign keys hidden from report view
 - [ ] No circular dependencies
 - [ ] Measures in dedicated folder or table
 - [ ] Appropriate data types assigned
@@ -210,14 +224,26 @@ Fact_Sales
 
 ### Snowflake Complexity
 ```
-❌ Dim_Product → Dim_Category → Dim_Department
-✓ Denormalize: Dim_Product (includes Category, Department)
+❌ Product → Category → Department
+✓ Denormalize: Product (includes Category, Department columns)
 ```
 
 ### Calculated Columns for Measures
 ```
 ❌ Calculated column: [Profit] = [Revenue] - [Cost]
-✓ Measure: Profit = SUM([Revenue]) - SUM([Cost])
+✓ Measure: Profit = SUM(Sales[Revenue]) - SUM(Sales[Cost])
+```
+
+### Technical Prefixes on User-Visible Tables
+```
+❌ Fact_Sales, Dim_Customer (developer jargon leaks to users)
+✓ Sales, Customer (business names)
+```
+
+### Visible Sumable Columns
+```
+❌ Quantity column visible — users drag it into visuals as Sum/Average
+✓ Hide Quantity, expose explicit measure: Quantity Sold = SUM(Sales[Quantity])
 ```
 
 ### Missing Date Dimension

package/src/content/skills/dax.md

@@ -15,10 +15,13 @@ You are a **DAX Expert** specializing in efficient measure design, context manip
 
 ## MANDATORY RULES
 1. **USE VARIABLES.** Always use VAR/RETURN for any calculation used more than once.
-2. **FILTER ON DIMENSIONS.** Never filter directly on fact tables when a dimension exists.
-3. **SAFE DIVISION.** Always use DIVIDE() instead of / operator.
-4. **EXPLAIN CONTEXT.** Help users understand filter vs row context.
-5. **PERFORMANCE FIRST.** Suggest optimizations proactively.
+2. **FINAL VARIABLE IS `Result`.** Every measure with VAR/RETURN ends with `VAR Result = ... RETURN Result` (SQLBI convention).
+3. **PASCALCASE FOR VARIABLES.** No underscore prefix. `TotalSales`, not `_TotalSales`.
+4. **`@` PREFIX FOR TEMPORARY COLUMNS.** When adding columns inside `ADDCOLUMNS` or `SUMMARIZECOLUMNS`, prefix with `@` (e.g., `@Rank`, `@Sales`).
+5. **FILTER ON DIMENSIONS.** Never filter directly on fact tables when a dimension exists.
+6. **SAFE DIVISION.** Always use DIVIDE() instead of / operator.
+7. **EXPLAIN CONTEXT.** Help users understand filter vs row context.
+8. **PERFORMANCE FIRST.** Suggest optimizations proactively.
 
 ---
 
@@ -27,14 +30,26 @@ Best practices for writing and optimizing DAX in Power BI.
 
 ## Naming Conventions
 
+Conventions follow the SQLBI Style Guide. The principle: **measure names speak business language, code reads top-to-bottom**.
+
 | Element | Convention | Example |
 |---------|------------|---------|
-| Measures | PascalCase, descriptive | `TotalSalesAmount`, `AvgOrderValue` |
-| Calculated Columns | PascalCase, table prefix if ambiguous | `Sales[FullDate]`, `Product Category` |
-| Variables | Underscore prefix + PascalCase | `_Result`, `_FilteredTable`, `_CurrentDate` |
-| Measure Tables | `_Measures` or `Metrics` | `_Measures[TotalSales]` |
-| KPI Measures | Prefix with category | `KPI_Sales_Target`, `KPI_Margin_Actual` |
-| Debug/Test Measures | Underscore prefix | `_Debug_RowCount`, `_Test_SalesTotal` |
+| Measures | Auto-explicative, no prefix | `Sales`, `Margin %`, `Sales YTD` |
+| Time intelligence suffix | Space + period | `Sales YTD`, `Sales PY`, `Sales MTD` |
+| Variations | Space + variation + `%` | `Sales YoY %`, `Sales MoM %` |
+| Ratios | Space + `%` | `Margin %`, `Conversion %` |
+| Calculated Columns | Natural name | `Full Date`, `Product Category` |
+| Variables | PascalCase, no prefix | `TotalSales`, `FilteredTable`, `CurrentDate` |
+| Final variable | Always `Result` | `VAR Result = ...` `RETURN Result` |
+| Temporary columns | Prefix `@` | `@Rank`, `@Sales`, `@Delta` |
+| Measure Tables | Prefix `_`, hidden | `_Measures`, `_KPIs` |
+| Debug/Test Measures | `_` prefix, hidden | `_Debug Row Count` |
+
+**Anti-patterns:**
+- `Total Sales`, `Sum of Sales` (redundant, the aggregation is implied)
+- `_Result`, `_FilteredTable` (no underscore prefix on variables)
+- `YTD_Sales`, `Sales_YTD` (use space-separated suffix)
+- `MarginPct`, `MarginRatio` (use `Margin %` instead)
 
 ---
 
@@ -100,25 +115,47 @@ SumViaMeasure = SUMX(Products, [TotalSales])  // [TotalSales] filters to each pr
 - Intermediate calculations
 - Debugging complex measures
 
+**Conventions (SQLBI Style Guide):**
+- **PascalCase** without underscore prefix
+- **Final variable always `Result`** — clearly marks the measure's output
+- **Temporary columns prefixed with `@`** to distinguish from model columns
+
 ```dax
--- Good: Use variables
-SalesYoY =
-VAR _CurrentSales = [TotalSales]
-VAR _PriorYearSales =
+-- Good: PascalCase vars, Result final var
+Sales YoY % =
+VAR CurrentSales = [Sales]
+VAR PriorYearSales =
     CALCULATE(
-        [TotalSales],
+        [Sales],
         SAMEPERIODLASTYEAR('Date'[Date])
     )
-VAR _Change = _CurrentSales - _PriorYearSales
-RETURN
-    DIVIDE(_Change, _PriorYearSales)
+VAR Delta = CurrentSales - PriorYearSales
+VAR Result = DIVIDE(Delta, PriorYearSales)
+RETURN Result
+
+-- Good: Temporary column with @ prefix
+Top 10 Products Sales =
+VAR RankedProducts =
+    ADDCOLUMNS(
+        VALUES(Product[Product Name]),
+        "@Rank", RANKX(VALUES(Product[Product Name]), [Sales], , DESC)
+    )
+VAR Top10 = FILTER(RankedProducts, [@Rank] <= 10)
+VAR Result = SUMX(Top10, [Sales])
+RETURN Result
 
 -- Bad: Repeated calculations (slower, harder to read)
-SalesYoY_Bad =
+Sales YoY Bad =
 DIVIDE(
-    [TotalSales] - CALCULATE([TotalSales], SAMEPERIODLASTYEAR('Date'[Date])),
-    CALCULATE([TotalSales], SAMEPERIODLASTYEAR('Date'[Date]))
+    [Sales] - CALCULATE([Sales], SAMEPERIODLASTYEAR('Date'[Date])),
+    CALCULATE([Sales], SAMEPERIODLASTYEAR('Date'[Date]))
 )
+
+-- Bad: Underscore prefix on variables (old convention)
+Sales YoY Old =
+VAR _CurrentSales = [Sales]
+VAR _PriorYearSales = CALCULATE([Sales], SAMEPERIODLASTYEAR('Date'[Date]))
+RETURN DIVIDE(_CurrentSales - _PriorYearSales, _PriorYearSales)
 ```
 
 ### Safe Division
@@ -627,29 +664,30 @@ Running_Total = CALCULATE(...)  -- Use measures
 ## Formatting Standards
 
 ```dax
--- Simple measure (one line)
-TotalSales = SUM(Sales[Amount])
+-- Simple measure (one line, no VAR/RETURN needed)
+Sales = SUM(Sales[Amount])
 
 -- Medium complexity (few lines)
-Margin = DIVIDE([Profit], [Revenue], 0)
+Margin % = DIVIDE([Profit], [Revenue], 0)
 
--- Complex measure (structured with comments)
-ComplexMeasure =
-// Purpose: Calculate year-over-year change with handling for missing prior year
-VAR _CurrentSales = [TotalSales]
-VAR _PriorYearSales =
+-- Complex measure (structured with comments, Result as final var)
+Sales YoY % =
+// Purpose: Year-over-year change with handling for missing prior year
+VAR CurrentSales = [Sales]
+VAR PriorYearSales =
     CALCULATE(
-        [TotalSales],
+        [Sales],
         SAMEPERIODLASTYEAR('Date'[Date])
     )
-VAR _Change = _CurrentSales - _PriorYearSales
-VAR _HasPriorYear = NOT(ISBLANK(_PriorYearSales))
-RETURN
+VAR Delta = CurrentSales - PriorYearSales
+VAR HasPriorYear = NOT(ISBLANK(PriorYearSales))
+VAR Result =
     IF(
-        _HasPriorYear,
-        DIVIDE(_Change, _PriorYearSales),
+        HasPriorYear,
+        DIVIDE(Delta, PriorYearSales),
         BLANK()
     )
+RETURN Result
 ```
 
 ---

package/src/content/skills/governance.md

@@ -22,57 +22,100 @@ You are a **BI Governance Specialist** who establishes and enforces naming conve
 
 ## Naming Conventions
 
+Conventions follow SQLBI Style Guide, Chris Webb, and Microsoft's semantic model best practices. The guiding principle: **user-visible names speak business language, technical elements stay hidden**.
+
 ### Tables
 
+**Rules:**
+1. **No technical prefixes.** Never use `dim`, `fact`, `tbl`, `t_`. These are for developers; users see tables in visuals and shouldn't read SQL jargon.
+2. **Dimensions singular, facts plural.** A dimension describes one entity (`Customer`, `Product`, `Date`). A fact contains many events (`Sales`, `Orders`, `Transactions`).
+3. **Spaces allowed for user-visible tables.** Use natural language: `Purchase Orders`, not `PurchaseOrders` or `PO_Header`.
+4. **Business names, not source names.** Match the language users speak, not the database schema.
+
 | Type | Convention | Example | Anti-Pattern |
 |------|-----------|---------|-------------|
-| Dimension | Singular noun | `Customer`, `Product`, `Date` | `Customers`, `DimCustomer`, `tbl_Customer` |
-| Fact | Singular noun or verb | `Sale`, `Order`, `Inventory` | `FactSales`, `fct_Sales` |
-| Bridge | Prefix with `Bridge` | `BridgeCustomerRegion` | `CustomerRegion_Bridge` |
-| Measure table | Prefix `_` | `_Measures`, `_KPIs` | `Measures Table`, `CalcMeasures` |
-| Config/Utility | Prefix `_` | `_Parameters`, `_DateConfig` | `Parameters` |
-| Calculated table | Document clearly | `CalendarTable` (with comment) | Unmarked calculated tables |
+| Dimension | Singular, business name | `Customer`, `Product`, `Date` | `Customers`, `DimCustomer`, `tbl_Customer` |
+| Fact | Plural, business name | `Sales`, `Orders`, `Transactions` | `FactSales`, `fct_sales`, `Sale` |
+| Bridge | Prefix with `Bridge` | `Bridge Customer Region` | `CustomerRegion_Bridge` |
+| Measure table | Prefix `_` (hidden) | `_Measures`, `_KPIs` | `Measures Table` |
+| Config/Utility | Prefix `_` (hidden) | `_Parameters`, `_DateConfig` | `Parameters` |
 
 ### Columns
 
+**Rules:**
+1. **Descriptive and readable.** `Order Date`, not `OrdDt`. Spaces allowed.
+2. **Foreign keys hidden with special marker.** Use `CustomerKey` suffix or `_Customer` prefix to sort them together. **Always hide from report view.**
+3. **No abbreviations** except universal ones (`YTD`, `PY`, `MTD`, `QTD`, `YoY`). Avoid `Qty`, `Amt`, `Vta`, `Cant`.
+4. **Consistency.** If you use spaces in one table, use them everywhere.
+
 | Type | Convention | Example |
 |------|-----------|---------|
-| Key (primary) | `[TableName]Key` | `CustomerKey`, `ProductKey` |
-| Key (alternate) | `[TableName]ID` or `[TableName]Code` | `CustomerID`, `ProductCode` |
-| Attribute | PascalCase, descriptive | `FirstName`, `OrderDate`, `ProductCategory` |
-| Flag/Boolean | `Is[Condition]` | `IsActive`, `IsDeleted`, `HasDiscount` |
-| Amount/Currency | Suffix with `Amount` | `SalesAmount`, `DiscountAmount` |
-| Count | Suffix with `Count` | `OrderCount`, `ItemCount` |
-| Date | Suffix with `Date` | `OrderDate`, `ShipDate`, `HireDate` |
+| Primary key (surrogate) | `[Table]Key`, hidden | `CustomerKey`, `ProductKey` |
+| Primary key (business) | `[Entity] ID` or `[Entity] Code` | `Customer ID`, `Product Code` |
+| Attribute | Natural language | `First Name`, `Order Date`, `Product Category` |
+| Flag/Boolean | `Is [Condition]` or `Has [Condition]` | `Is Active`, `Has Discount` |
+| Amount/Currency | Include unit in name | `Sales Amount`, `Discount Amount` |
+| Count | Include `Count` suffix | `Order Count`, `Item Count` |
+| Date | Include `Date` suffix | `Order Date`, `Ship Date` |
 
 ### Measures
 
-| Type | Convention | Example |
-|------|-----------|---------|
-| Base aggregation | PascalCase, descriptive | `TotalSales`, `OrderCount` |
-| Time intelligence | Suffix with period | `TotalSales_YTD`, `Revenue_PY` |
-| Ratio/Percentage | Suffix with `Pct` or `Ratio` | `MarginPct`, `ConversionRatio` |
-| KPI | Prefix with `KPI_` | `KPI_Revenue_Actual`, `KPI_Revenue_Target` |
-| Ranking | Prefix with `Rank_` | `Rank_TopProducts` |
-| Debug/Test | Prefix with `_` | `_Debug_RowCount`, `_Test_Total` |
-| Format string | Include in measure | Use format strings, not calculated strings |
+**Rules:**
+1. **Auto-explicative names.** The name alone should tell you what it calculates. No documentation required.
+2. **No redundant prefixes.** Use `Sales`, not `Total Sales`, `Sum of Sales`, or `Amount of Sales`. The aggregation is implied.
+3. **Space-separated suffixes for time intelligence.** `Sales YTD`, `Sales PY`, `Sales YoY %`, `Sales MTD`.
+4. **Space-separated suffixes for ratios and percentages.** `Margin %`, `Growth %`, `Conversion Rate`.
+5. **Never prefix with the table name.** Just `Sales`, not `Transactions[Sales]` in the visible name.
+6. **Explicit measures, hidden source columns.** Create DAX measures for every numeric calculation. Hide sumable columns (or set summarization to `Don't summarize`) so users can't drag raw columns into visuals.
+7. **Organize in display folders** when the measure count grows: `Sales`, `Sales\Time Intelligence`, `Sales\Comparatives`.
+
+| Type | Convention | Example | Anti-Pattern |
+|------|-----------|---------|-------------|
+| Base aggregation | Noun, no prefix | `Sales`, `Customers`, `Units Sold` | `Total Sales`, `Sum of Sales`, `Sales Amount Total` |
+| Time intelligence | Noun + period suffix | `Sales YTD`, `Sales PY`, `Sales MTD` | `YTD_Sales`, `Sales_PriorYear` |
+| Variation | Noun + variation + `%` | `Sales YoY %`, `Sales MoM %` | `YoY_Pct_Sales` |
+| Ratio/Percentage | Noun + ` %` | `Margin %`, `Conversion %` | `MarginPct`, `ConversionRatio` |
+| KPI vs target | Noun + vs Target | `Sales vs Target`, `Sales vs Budget %` | `KPI_Sales` |
+| Ranking | `Rank: ` prefix or `Rank` suffix | `Rank: Top Products`, `Product Rank` | `RANK_Products` |
+| Debug/Test | `_` prefix (hidden) | `_Debug Row Count` | `Debug: Row Count` (visible) |
 
 ### Variables (DAX)
 
-| Convention | Example |
-|-----------|---------|
-| Prefix with `_` + PascalCase | `_CurrentSales`, `_PriorYear` |
-| Descriptive names | `_FilteredTable`, `_MaxDate` |
-| Avoid single letters | `_Result` not `_R` |
+**Rules:**
+1. **PascalCase.** No underscore prefix. `TotalSales`, `AverageMargin`, `FilteredTable`.
+2. **Final variable always named `Result`.** SQLBI convention for readability — the reader knows immediately where the measure ends.
+3. **Temporary columns prefixed with `@`.** When you add a column inside `ADDCOLUMNS` or `SUMMARIZECOLUMNS`, use `@Rank`, `@Sales`, `@Delta`. Distinguishes them from model columns.
+
+```dax
+// Good: PascalCase vars, Result final var, @ for temp columns
+Sales YoY % =
+VAR CurrentSales = [Sales]
+VAR PriorYearSales =
+    CALCULATE([Sales], SAMEPERIODLASTYEAR('Date'[Date]))
+VAR Delta = CurrentSales - PriorYearSales
+VAR Result = DIVIDE(Delta, PriorYearSales)
+RETURN Result
+
+// Temporary column example
+Top Products =
+VAR RankedProducts =
+    ADDCOLUMNS(
+        VALUES(Product[Product Name]),
+        "@Rank", RANKX(VALUES(Product[Product Name]), [Sales], , DESC)
+    )
+VAR Result =
+    FILTER(RankedProducts, [@Rank] <= 10)
+RETURN Result
+```
 
 ### Power Query
 
 | Element | Convention | Example |
 |---------|-----------|---------|
-| Query name | PascalCase matching table | `Customer`, `Sale` |
-| Staging query | Prefix with `stg_` | `stg_Customer_Raw` |
-| Helper function | Prefix with `fn` | `fnCleanText`, `fnGetFiscalYear` |
-| Parameter | Prefix with `prm` | `prmServerName`, `prmStartDate` |
+| Query name | Matches destination table | `Customer`, `Sales` |
+| Staging query | Prefix `stg `, hidden | `stg Customer Raw` |
+| Helper function | Prefix `fn` | `fnCleanText`, `fnGetFiscalYear` |
+| Parameter | Prefix `prm` | `prmServerName`, `prmStartDate` |
 | Step names | Descriptive, PascalCase | `FilteredActiveRows`, `RenamedColumns` |
 
 ---
@@ -81,26 +124,28 @@ You are a **BI Governance Specialist** who establishes and enforces naming conve
 
 ### Recommended Folder Structure
 
+Display folders separate measures with `\` (backslash). Use them as soon as you have more than ~10 measures.
+
 ```
 _Measures/
-├── 📁 Core Metrics
-│   ├── TotalSales
-│   ├── TotalCost
-│   └── GrossMargin
+├── 📁 Core
+│   ├── Sales
+│   ├── Cost
+│   └── Gross Margin
 ├── 📁 Time Intelligence
-│   ├── TotalSales_YTD
-│   ├── TotalSales_PY
-│   └── TotalSales_YoY
-├── 📁 KPIs
-│   ├── KPI_Revenue_Actual
-│   ├── KPI_Revenue_Target
-│   └── KPI_Revenue_Status
+│   ├── Sales YTD
+│   ├── Sales PY
+│   └── Sales YoY %
+├── 📁 Targets
+│   ├── Sales Target
+│   ├── Sales vs Target
+│   └── Sales vs Target %
 ├── 📁 Rankings
-│   ├── Rank_TopProducts
-│   └── Rank_TopCustomers
+│   ├── Rank: Top Products
+│   └── Rank: Top Customers
 └── 📁 _Debug (hidden in production)
-    ├── _Debug_RowCount
-    └── _Test_Total
+    ├── _Debug Row Count
+    └── _Test Sales
 ```
 
 ---
@@ -139,11 +184,13 @@ Every model should have:
 ### Measure Documentation Template
 
 ```dax
-// Description: Calculates total sales for the current year to date
+// Description: Calculates sales for the current year to date
 // Business rule: Includes all confirmed and shipped orders, excludes cancelled
 // Owner: [team/person]
 // Last modified: [date]
-TotalSales_YTD = TOTALYTD([TotalSales], 'Date'[Date])
+Sales YTD =
+VAR Result = TOTALYTD([Sales], 'Date'[Date])
+RETURN Result
 ```
 
 ---
@@ -165,11 +212,17 @@ TotalSales_YTD = TOTALYTD([TotalSales], 'Date'[Date])
 ### Code Review Checklist
 
 - [ ] Measures use VAR/RETURN for repeated calculations
+- [ ] Final variable in every measure is named `Result`
+- [ ] Variables use PascalCase (no underscore prefix)
+- [ ] Temporary columns use `@` prefix (e.g., `@Rank`)
 - [ ] DIVIDE() used instead of / operator
 - [ ] No FILTER on fact tables (use dimension filters)
-- [ ] Variables follow naming conventions
 - [ ] Complex measures have comments
 - [ ] No hardcoded values (use parameters)
+- [ ] No technical prefixes on tables (`Dim_`, `Fact_`)
+- [ ] Foreign keys hidden from report view
+- [ ] Sumable source columns hidden (only explicit measures visible)
+- [ ] Measure names are auto-explicative (no `Total`, `Sum of`)
 
 ---