Prompt Engineering for PBIP — Copilot × Power BI

Part A · Foundations & best practices

Prompt Copilot like it can already read your PBIP

Because it can. The whole model and report are text on disk. This part covers how Copilot actually sees a PBIP repo, the five-part anatomy of a prompt that works, how to feed it the right context, and the safety habits that keep a helpful edit from quietly breaking your model.

0 / 0

A .pbix is an opaque binary; a .pbip is a folder of readable text. That single difference is what lets Copilot audit, diff, and edit your work. Before writing a prompt, know what's in the folder and what each file governs.

Learn this

Know the layout: a small .pbip pointer file, a <name>.SemanticModel/ folder, and a <name>.Report/ folder — each with a definition/ subfolder and a .platform file
The model is TMDL under SemanticModel/definition/: model.tmdl, relationships.tmdl, tables/*.tmdl (one file per table, with its columns and measures), and expressions.tmdl for shared Power Query (M)
The report is PBIR under Report/definition/: report.json, a pages/ tree, and visuals/ — plus theme files under StaticResources/
Why it matters: text means Copilot can read the whole model, grep across tables, and propose edits as a diff — and it means git tracks every change
Enable the PBIP + PBIR/TMDL formats in Power BI Desktop (Options → Preview features), and open the folder as a workspace so Copilot has the full tree

Go deeper

Field noteYour first move in any new PBIP repo: ask Copilot to map it. “List every file under the two definition folders and tell me, in one line each, what it governs.” Now you both share a mental model before you touch anything.

Most weak prompts are missing one of five ingredients. Name the role, point at the context, state the task, set the constraints, and specify the output format — and vague answers turn into precise, checkable ones.

Learn this

Role — front-load expertise: “Act as a Power BI performance reviewer” primes different behaviour than a blank ask
Context — name the files (#file/#folder), the grain of your fact table, and anything Copilot can't infer
Task — one clear verb and object: audit, rewrite, explain, generate. Split compound asks into steps
Constraints — the guardrails: “keep results numerically identical”, “don't edit yet”, “only touch the Sales table”
Format — ask for the shape you want back: a ranked markdown table, a diff, three options, a step-by-step plan

See it assembled

# role      Act as a Power BI performance reviewer.
# context   Read #folder:Sales.SemanticModel/definition/tables. The Sales
#           fact is daily grain; Date is a proper dimension.
# task      Find columns that inflate model size.
# constraintReport only — do NOT edit any files.
# format    A markdown table: column | issue | size impact | fix.

Go deeper

Field noteIf an answer disappoints, don't just re-ask — diagnose which of the five was missing. Nine times out of ten it's constraints or format.

Copilot is only as good as what's in its window. The skill is choosing the minimum context that fully specifies the job — too little and it guesses, too much and it drifts.

Learn this

Reference precisely: #file for a single table or measure, #folder for all tables, @workspace when the answer could be anywhere in the repo
Describe what Copilot can't see from the files: the fact grain, which tables are dimensions, refresh source, and expected row counts
Paste real evidence: VertiPaq Analyzer metrics, Best Practice Analyzer output, or a Performance Analyzer export — findings beat guesses
Point at the exact object when you can — a measure name, a table file — instead of “the slow one”
Prune ruthlessly: if a file isn't needed for this task, don't attach it — irrelevant context is a distraction, not a safety net

Go deeper

Field notePasting a VertiPaq Analyzer table into the prompt is the single highest-leverage move on this page. Copilot stops speculating about size and starts reasoning about your numbers.

The best results come from a conversation, not a one-shot. Get a plan before edits, keep changes small enough to review, and steer with specific corrections instead of starting over.

Learn this

Ask for a plan before edits: “List the changes you'd make and wait for my go-ahead” — you approve the approach before any file moves
Work in small diffs: one table or one measure at a time, so every change is reviewable and reversible
Correct, don't restart: “Good, but keep the format as Date, not Text” steers faster than re-writing the whole prompt
Demand reasoning: “Explain the trade-off” surfaces the risk, and often reveals a better option you hadn't asked for

Go deeper

DocsAgent mode in VS Code — how Copilot plans and applies multi-file editscode.visualstudio.com

Field note“Don't change anything yet” is the most useful five words in your vocabulary. It converts an edit tool into a review tool for exactly as long as you want.

Copilot editing TMDL and JSON directly is powerful and occasionally wrong. A few habits make every change safe to accept — or safe to throw away.

Learn this

Commit or branch before letting Copilot edit — a clean git state turns any bad edit into a one-command undo
Constrain the blast radius: “only edit files under tables/” or “change this one measure and nothing else”
Protect meaning: “keep the DAX numerically identical” and “preserve valid TMDL — don't break the schema”
Review the diff every time, then reopen the PBIP in Power BI Desktop to confirm it loads and measures still compute
Never paste secrets, connection strings, or real customer data into a prompt — treat the chat like a public code review

Go deeper

DocsPBIP & source control — why the folder format is git-friendlylearn.microsoft.com

Field noteTreat “git is clean” as the precondition for every editing prompt. If you can't git diff the result, you're not reviewing — you're hoping.

Part B · Prompting for model efficiency

Make the semantic model smaller and faster

The model is where performance is won or lost. These are the prompts that turn Copilot into a size auditor and a DAX optimizer — grounded in the same techniques as the VertiPaq / Best Practice Analyzer world, now applied straight to your TMDL.

0 / 0

Most bloated models share the same handful of causes. Teach Copilot to hunt for them by name and it becomes a fast, repeatable size review over your TMDL.

Prompt it to find

High-cardinality columns — the biggest driver of size; ask which columns have the most unique values and whether each is really needed
Oversized data types — Decimal where Int64 would do, or Text keys that should be integer surrogates
DateTime columns that should be split into Date + Time (or reduced to Date) to collapse cardinality
Auto date/time hidden tables — ask Copilot to flag it and recommend a single shared date dimension instead
Unused columns and measures — anything not referenced by a relationship, another measure, or a report visual
summarizeBy defaults — keys and codes set to Sum should be None so they don't produce nonsense implicit aggregates

Go deeper

Field noteAsk for the audit as a ranked table with an estimated size impact. Ranking forces prioritisation — you fix the two columns that matter instead of the twenty that don't.

Copilot is strong at DAX refactoring when you pin the rules. Give it the patterns to prefer and the invariant to protect, and ask it to explain the win so you learn as it edits.

Prompt it to prefer

Variables over repeated sub-expressions — readable and evaluated once
DIVIDE over the / operator for safe division without an error-guard wrapper
TREATAS / KEEPFILTERS and column filters over FILTER across an entire table
Fewer, deliberate context transitions — ask it to flag every CALCULATE that forces one
The invariant: “keep the result numerically identical” — and show before/after with a one-line explanation of why it's faster

Go deeper

Field noteHave Copilot rewrite, then paste both versions into DAX Studio Server Timings to confirm the speed-up is real. Trust the trace, not the claim.

Beyond column-level cleanup, the shape of the model decides how fast and maintainable it is. These prompts ask Copilot to reason about structure, not just syntax.

Prompt it to assess

Star-schema fit — are facts and dimensions cleanly separated, or is there a snowflake / flat table to reshape?
Relationship health — cardinality and cross-filter direction; flag every bidirectional relationship and justify or remove it
Aggregations — where a summary table would cut scan cost on a large fact
Calculation groups — to collapse dozens of near-identical time-intelligence measures into one
Incremental refresh readiness — is the fact partitioned on a date the policy can use?

Go deeper

Field noteDesign changes are the ones to plan first, edit later. Ask for the reshape as a proposal with trade-offs, decide, then let Copilot apply it one table at a time.

Part C · Prompting for report enhancements

Polish the report the model feeds

The report is JSON too — so Copilot can audit layout, enforce a theme, and catch accessibility gaps across every page at once. These prompts turn “make it look better” into specific, page-by-page fixes.

0 / 0

Consistency is what separates a polished report from a busy one — and it's exactly the kind of mechanical check Copilot does well across many pages.

Prompt it to check

Alignment & spacing — visuals off the grid, inconsistent gutters, or overlapping frames, listed per page
Hard-coded colours & fonts that override the theme — have Copilot point each one back to the theme file
Title hygiene — every visual has a meaningful title (or is intentionally title-off), no leftover “Sum of…”
Page density — flag pages with too many visuals; suggest what to split, drill into, or cut
One theme file — ask it to reconcile the report to a single theme JSON under StaticResources

Go deeper

Field noteTheme edits are low-risk and high-visibility — a great first “let Copilot actually edit” task once you've done a couple of report audits.

Accessibility gaps are easy to miss by eye and easy to catch in JSON. Copilot can sweep every page for the ones that matter most.

Prompt it to flag

Missing alt text on visuals that convey information
Colour as the only encoding — where a shape, label, or pattern should back it up
Low contrast in custom colours against the background
Tab order that doesn't follow the visual reading order of the page

Go deeper

DocsDesign Power BI reports for accessibilitylearn.microsoft.com

Field noteFrame it as “give me the page, the visual id, and the specific fix.” A finding you can't locate is a finding you won't act on.

A faster, richer report is often about doing more with fewer visuals. Ask Copilot to suggest interactivity that replaces clutter — and to name what's slowing a page down.

Prompt it to suggest

Field parameters — let users swap measures or dimensions instead of stacking near-duplicate visuals
Bookmarks & drill-through — move detail off the summary page into a focused view
Report tooltips — replace crowded cards with a hover detail page
Visual reduction — identify pages where the visual count is the performance bottleneck
Interaction cleanup — unnecessary cross-filtering that fires extra queries on every click

Go deeper

Field notePair this with Performance Analyzer: export the slowest page, paste it in, and ask Copilot which visuals to consolidate. Evidence in, targeted suggestions out.

Part D · Unlocking creativity

Prompt patterns and your own prompt library

The techniques that get you past “make it better” into ideas you wouldn't have reached alone — personas, self-critique, reverse-prompting — plus how to save your best prompts so the whole team (or future you) reuses them.

0 / 0

A handful of reusable shapes cover most of your creative work. Learn them once and mix them per task.

The patterns

Persona — “act as a skeptical BI architect / an exec / a new analyst” changes what Copilot notices
Few-shot — show one measure or visual done your way, then ask for the rest to match
Step-by-step — “think through it before answering” for anything with dependencies
Generate-then-critique — produce a draft, then have it argue against its own work and revise
Give me three — a simple, a polished, and an ambitious option, with a recommendation
Format-forcing — demand the answer as a table, diff, or checklist so it's immediately usable

Go deeper

DocsPrompt engineering for GitHub Copilot — patterns and examplesdocs.github.com

Field noteGenerate-then-critique is the sleeper. “Now poke holes in what you just proposed” routinely catches an over-engineered change before you accept it.

When you're stuck, the move is to change who's asking the questions. These flip the usual direction and shake loose options you wouldn't prompt for directly.

Try these

Reverse-prompt — “before you answer, ask me the 5 questions you most need” forces the real requirements out
Meta-prompt — “improve my prompt, then run the improved version” turns Copilot into your prompt editor
Diverge then converge — ask for ten rough ideas first, then narrow to the two worth building
What am I missing — “assume I have blind spots; list improvements I haven't thought of”
Role rotation — review the same page as an exec, then a data engineer, then an accessibility auditor

Field noteKeep a running note of prompts that surprised you in a good way. That note is the seed of your prompt library (D3) — and half of it graduates into the cheat-sheet below.

A great prompt you have to retype is a great prompt you'll stop using. Bake the recurring ones into the repo so Copilot applies them by default.

Learn this

Repo custom instructions — a .github/copilot-instructions.md that tells Copilot this is a PBIP project and how to edit it (starter in the cheat-sheet)
Prompt files — reusable *.prompt.md files for jobs you run often, invokable from chat
Version them — commit both so the whole team gets the same behaviour and prompts improve over time
Keep them short and specific — a few sharp rules beat a wall of vague guidance

Go deeper

Field noteCustom instructions are the compounding investment on this page. Write them once and every future prompt starts smarter — grab the starter from the cheat-sheet and adapt it to your repo.

Cheat-sheet · Copy, paste, run

The prompt library

Ready-to-run prompts for the jobs you repeat. Open the PBIP folder in VS Code with Copilot in agent mode, adjust the highlighted placeholders, and paste. Nothing here edits your files until you say so — every audit prompt reports first.

Map the repofirst thing in a new PBIP project

You are onboarding me to this Power BI Project. Read @workspace.
List every file under the .SemanticModel/definition and
.Report/definition folders and tell me, in one line each, what it
governs. Then summarise: what does this model represent, what is the
grain of each fact table, and which tables are dimensions? Ask me a
question if any table's grain is ambiguous. Don't change anything.

Full model auditreport only — no edits

Act as a Power BI performance reviewer. Read every .tmdl file under
#folder:YourModel.SemanticModel/definition/tables. Produce a
prioritised markdown table: Object (file, table, column/measure) |
Issue | Why it costs size or speed | Suggested TMDL fix. Check for:
high-cardinality columns, oversized data types, DateTime columns that
should be split or reduced to Date, columns with summarizeBy that
should be None, hidden or unused columns, columns not referenced by
any measure or relationship, and bidirectional relationships. Rank by
impact. Do NOT edit any files yet — report only.

Explain one measurelearn what it does + risks

Explain the measure [Measure Name] in #file:Sales.tmdl in
plain English: what it calculates, step by step. Then list any
correctness or performance risks — context transition, FILTER over a
whole table, repeated CALCULATE, missing DIVIDE. Don't rewrite it yet;
just tell me what to watch.

Plan the shrinkapprove before it edits

Here are my VertiPaq Analyzer metrics:
[paste the table]
Based on these and the TMDL in #folder:YourModel.SemanticModel/definition,
propose the top 10 changes that would most reduce model size, ranked
by expected impact. For each: the exact TMDL edit, the table/column,
and the trade-off — does it break any measure, relationship, or
report visual? Wait for my go-ahead, then apply them one table at a
time, pausing after each so I can review the diff.

Optimise DAXkeep the number identical

Optimise the measure [Measure Name] for a large fact table.
Prefer variables over repeated expressions, DIVIDE over the /
operator, TREATAS or KEEPFILTERS over FILTER across an entire table,
and avoid unnecessary context transition. Keep the result numerically
identical. Output the new DAX, then a short bullet list of exactly
what changed and why each change is faster.

Data-type & cardinality passreport first

Scan every column in #folder:YourModel.SemanticModel/definition/tables.
Flag columns whose data type is larger than needed (Decimal that
could be Int64; DateTime that should be Date or split into Date +
Time) and any high-cardinality text key that should be an integer
surrogate. Give me the TMDL edit for each, as a table of file |
column | current | suggested | why. Report only — don't apply.

Report consistency auditpage-by-page

Read the report under #folder:YourReport.Report/definition. For
each page list: visual count, fonts/colours that don't match the
theme, misaligned or overlapping visuals, and visuals missing a title
or alt text. Output a markdown checklist grouped by page, with the
visual id for each item. Don't edit anything yet.

Accessibility passlocate every fix

Review the report JSON in #folder:YourReport.Report/definition for
accessibility. Flag: visuals with no alt text, colour used as the
only encoding, low-contrast custom colours, and tab order that
doesn't follow reading order. For each finding give me the page, the
visual id, and the specific fix. Report only.

Apply the themelist changes before applying

Here is my theme file #file:theme.json. Find every visual in
#folder:YourReport.Report/definition that overrides theme colours
or fonts with hard-coded values, and rewrite them to inherit from the
theme instead. First list each change as page | visual | what changes.
Wait for my OK, then apply and show me the diff.

Give me three approachessimple / polished / ambitious

I want to [goal, e.g. show YoY growth by region on one page].
Propose 3 distinctly different ways to design this in Power BI: a
simple one, a polished one, and an ambitious one. For each: the
visuals, the DAX or field parameters needed, and the trade-offs. Then
recommend one and say why.

Reverse the promptsurface the real requirements

I'm about to redesign this report page for [audience]. Before
you suggest anything, ask me the 5 questions you most need answered to
do this well. Then wait for my answers.

Critique your own workcatch over-engineering

You just proposed those changes. Now switch roles: act as a skeptical
senior Power BI architect and try to poke holes in them. What could
break, what did you miss, what's over-engineered? Then give me your
revised recommendation.

What am I missingfind your blind spots

Read @workspace. Assume I'm a competent analyst with blind spots.
List 8 improvements I probably haven't thought of — across
performance, modelling, report UX, and maintainability — ranked by
effort-to-impact. One line each, with where to start.

.github/copilot-instructions.mdcommit it so every prompt starts smarter

# Copilot instructions — Power BI PBIP project

This repository is a Power BI Project (PBIP).
- The semantic model lives in *.SemanticModel/definition/ as TMDL.
- The report lives in *.Report/definition/ as PBIR JSON.
- Themes live under *.Report/StaticResources/.

When editing:
- Preserve valid TMDL and JSON — never break the schema.
- Keep DAX results numerically identical unless I ask otherwise.
- Prefer star-schema modelling, integer keys, and the smallest
  correct data type.
- Prefer variables, DIVIDE, and KEEPFILTERS/TREATAS over FILTER over
  whole tables.
- Explain the trade-off of any change, and show a diff before applying.
- When unsure about a table's grain or a measure's intent, ask before
  editing.

When reviewing:
- Report findings as a ranked table I can act on (file, issue, fix).
- Don't edit files during an audit unless I explicitly say to.

How to useSave this as .github/copilot-instructions.md at the repo root, tweak the rules to match your standards, and commit it. Copilot applies it automatically to every request in the workspace.

Stop guessing at prompts.
Turn Copilot into a PBIP reviewer that tightens the model and the report.

How to use this page

Prompt Copilot like it can already read your PBIP

How Copilot “sees” a PBIP repo

The anatomy of a prompt that works

Feeding Copilot the right context

Steering and iterating

Review-first and safety

Make the semantic model smaller and faster

Storage & size audits

DAX optimization prompts

Model design prompts

Polish the report the model feeds

Layout, consistency & theme

Accessibility & clarity

Interactivity & report performance

Prompt patterns and your own prompt library

Prompt patterns worth memorising

Techniques to unlock ideas

Save & reuse your best prompts

The prompt library

Audit & review

Model efficiency & DAX

Report polish

Creative & brainstorm

Custom-instructions starter