Powerbi Fast Edit

Power BI Fast Edit

Make the smallest correct local change. Default to Fast mode unless the user explicitly requests verification, rollback protection, or publishing.

Modes

Do not perform Git operations, Desktop reloads, screenshots, GUI saves, or publishing in Fast mode.

Route each change

• Report canvas: edit PBIR files for pages, visuals, field bindings, filters, slicers, bookmarks, themes, formatting, positions, and sizes.
• Semantic model: use Power BI Modeling MCP for measures, calculated objects, tables, columns, relationships, partitions, Power Query, SQL/native queries, and metadata.
• Project persistence: persist model changes into the PBIP semantic-model definition/TMDL. If a live Desktop edit cannot be persisted file-side, tell the user to press Ctrl+S; do not automate the GUI save in Fast mode.
• Power BI Service: use report management or Fabric operations only when the user explicitly asks to publish, upload, replace, download, or delete a Service item.

Do not invoke Power BI planning, design, or management workflows for a concrete local edit. Use them only when explicitly requested or when the task is genuinely open-ended.

Fast workflow

1. Resolve the target

   • Locate the specified .pbip, .Report, and .SemanticModel paths.
   • If exactly one project is in scope, use it. If multiple plausible projects exist and the user did not identify one, ask one concise question.
   • Never scan unrelated report portfolios or repositories.

2. Parse the request

   • Accept plain language or the format in references/change-spec.md.
   • If the visual type, fields, aggregation, and placement are concrete, execute directly.
   • If the business metric or intended comparison is ambiguous, present no more than three concise alternatives and wait for selection.
   • Do not create a design brief for a small concrete edit.

3. Inspect only what is needed

   • Read the relevant existing page/visual files and the report theme.
   • Query only referenced model tables, columns, measures, and relationships.
   • Reuse the current session's inventory; do not repeat it after interruptions.
   • Before binding a new data visual, run at most one DAX preflight query when field viability is not already known. Check nonblank count, cardinality, and the requested aggregation together.
   • Never choose a category merely because its name sounds appropriate.

4. Resolve measures

   • Reuse an explicit existing measure when it matches the requested definition.
   • When no measure exists and the aggregation is unambiguous, create a small explicit measure and mention it in the result.
   • Ask before creating it only when the business definition, grain, sign, date basis, or filter context is ambiguous.
   • Prefer explicit measures over implicit aggregation for modern card and chart roles.

5. Edit once

   • Use Modeling MCP transactions or batch operations when available.
   • Use powerbi-report-author catalog describe VISUAL_TYPE only for unknown roles or capabilities. Do not load entire reference guides when the CLI can answer the question.
   • Copy schema versions and structural patterns from the same report; do not invent schema versions.
   • Generate unique IDs, add new pages to pages.json, and write all related PBIR files in one logical batch.
   • Preserve unrelated files and existing user changes.

6. Validate once

   • Run powerbi-report-author validate PATH_TO_REPORT --pretty after the complete batch.
   • Fix validation errors and rerun only when needed.
   • Report pre-existing warnings separately from warnings caused by the edit.
   • Do not reload or screenshot in Fast mode.

7. Report concisely

   • State what changed, any new model objects, validation result, and whether the user must save/reopen Desktop.
   • State explicitly that nothing was published.
   • Avoid narrating routine commands or restating the entire workflow.

Verify mode

After Fast mode validation:

1. Run powerbi-desktop status and select the correct PID.
2. If hasUnsavedChanges is true, ask the user to save or discard manually; do not automate keystrokes.
3. Reload the validated PBIP/PBIR once.
4. Capture one scale-1 screenshot per changed page.
5. Review only layout, rendering, bindings, formatting, and obvious blanks/errors.
6. Correct only observed problems, then validate and verify once more.

Safe mode

Before editing, create one checkpoint only:

• Prefer one Git commit when the PBIP is already in a repository.
• Otherwise make one timestamped backup of the affected project.
• Do not create both a branch and an empty commit unless requested.

Then follow Verify mode.

Efficiency rules

• Batch independent reads and commands.
• Do not spawn subagents for routine edits.
• Do not run update checks during every edit unless an installed dependency explicitly blocks execution.
• Do not read complete large Microsoft reference files for common visuals.
• Do not take screenshots solely because PBIR files changed; use Verify or Safe mode.
• Do not automate Power BI Desktop UI actions in Fast mode.
• Do not publish as part of a local edit.
• Stop only for a missing target, unresolved business definition, destructive model change, failed validation, or unavailable required tool.

Tool fallback

• If Modeling MCP is unavailable, report that model edits are blocked; report-only PBIR edits may continue.
• If Desktop Bridge is unavailable, Fast mode is unaffected. In Verify mode, ask the user to reopen Desktop manually.
• If the native editing sandbox is broken, batch the smallest scoped fallback write instead of repeatedly retrying patch wrappers. Report the environment issue once.