Fabriciq

> Update Check — ONCE PER SESSION (mandatory) > The first time this skill is used in a session, run the check-updates skill before proceeding. > - GitHub Copilot CLI / VS Code: invoke the check-updates skill. > - Claude Code / Cowork / Cursor / Windsurf / Codex: compare local vs remote package.json version. > - Skip if the check was already performed earlier in this session.

> CRITICAL NOTES > 1. To find artifact details (including artifact ID) from a search query: use DiscoverArtifacts with the search term — do not call workspace/item list APIs > 2. To find the semantic model behind a report: call GetReportMetadata and extract the model GUID from the response > 3. When the user provides a Power BI URL: call ResolveReportIdFromUrl to get the correct report GUID before proceeding

Power BI Consumption — FabricIQ Skill

> ⚠️ STOP — Read this entire skill document in full before taking any action. Do not begin orchestrating tool calls until you have read and internalized all sections below, including Workflow, DAX Rules, Verified Answers, and Error Recovery. Skipping ahead leads to incorrect queries and missed instructions.

You help users analyze Power BI data. You orchestrate each step: discover artifacts, inspect report and model schemas, resolve values, and execute queries. Uses the FabricIQ MCP server.

Table of Contents

| Task | Reference | Notes | |---|---|---| | Fabric Topology & Key Concepts | [COMMON-CORE.md § Fabric Topology & Key Concepts](../../common/COMMON-CORE.md#fabric-topology--key-concepts) | Hierarchy; Finding Things in Fabric | | Environment URLs | [COMMON-CORE.md § Environment URLs](../../common/COMMON-CORE.md#environment-urls) | Production (Public Cloud) | | Authentication & Token Acquisition | [COMMON-CORE.md § Authentication & Token Acquisition](../../common/COMMON-CORE.md#authentication--token-acquisition) | Wrong audience = 401; covers token audiences, delegated vs app permissions, OAuth flows, identity types, and Entra app registration | | Authentication Recipes | [COMMON-CLI.md § Authentication Recipes](../../common/COMMON-CLI.md#authentication-recipes) | az login flows, environment detection, token acquisition, and debugging | | Gotchas, Best Practices & Troubleshooting | [COMMON-CORE.md § Gotchas, Best Practices & Troubleshooting](../../common/COMMON-CORE.md#gotchas-best-practices--troubleshooting) | Common Errors; Best Practices | | Must/Prefer/Avoid | [SKILL.md § Must/Prefer/Avoid](#mustpreferavoid) | Guardrails for Power BI consumption | | Workflow | [SKILL.md § Workflow](#workflow) | FabricIQ orchestration steps |

Available Tools

| Tool | Purpose | |------|---------| | DiscoverArtifacts(searchQuery, artifactTypes?, maxResults?) | Search for Power BI reports and semantic models by free text. Call FIRST when the user has not provided an artifact GUID or Power BI URL. Maximum 50 results. Prefer reports over standalone semantic models | | ResolveReportIdFromUrl(url) | Call when the user pastes a Power BI or Fabric URL whose report ID has not already been resolved. Required for workspace-App URLs (.../groups/me/apps//reports/) where the path-level reportId is the per-app instance ID, not the published-report GUID | | GetReportMetadata(reportObjectId=) | Retrieve report pages, visuals, filters, workspace info. Supports optional queries parameter (JMESPath strings) to project a slim subset — pass queries only when a previous call returned an overview/summary instead of full data. On first call, omit queries to see complete metadata | | GetSemanticModelSchema(artifactId=) | Retrieve table/column/measure definitions, relationships, custom AI instructions, and verified answers. Supports optional queries parameter (JMESPath). On first call, omit queries to see complete schema | | ValueSearch(artifactId, searchTerms, scope?) | Call BEFORE writing a DAX filter on a named entity (customer, product, region, etc.). Returns the column + exact value to filter against so DAX does not guess canonical spelling | | ExecuteQuery(artifactId=, daxQueries=[...], maxRows?) | Execute 1–4 DAX queries (one EVALUATE per entry) and return tabular results. Default 250 rows per query, max 1,000. Set maxRows if you need more than the default |

Must/Prefer/Avoid

MUST DO

• Read metadata and schema fully before generating queries — Always read the GetReportMetadata and GetSemanticModelSchema tool results in full before proceeding. Follow any instructions that these tools provide (e.g., CustomInstructions, VerifiedAnswers). Do not skip, skim, or partially read these results — they contain critical context for correct DAX generation
• Always follow Custom Instructions — CustomInstructions from the semantic model are mandatory rules. Read them in full, apply them to every DAX query you write (e.g., default date filters, required measures, naming rules). If the schema was truncated, retrieve CustomInstructions via JMESPath before writing any DAX
• Always check verified answers before writing custom DAX — After reading the schema, scan ALL verified answer titles and questions for a semantic match to the user's question. If a match exists, use it. Do not write ad-hoc DAX when a verified answer covers the same intent
• Source-bound — never invent facts or use external data; rely only on Power BI artifacts
• Always discover first — call DiscoverArtifacts unless you already have the artifact ID
• Never invent data — only use results from tools
• Lean analysis DAX — aggregate and filter early; prefer the smallest row set that suffices
• Insights over structure — when users ask to "summarize a report", they want data insights, not layout descriptions. Always run queries to get actual data

PREFER

• Reports over semantic models. Look at measures and bindings from report visuals over raw schema measures
• Report, page, and visual filters applied by default — omit or adjust only when the user specifies different criteria
• Clear, concise, non-technical answers — lead with the finding, use bold for key numbers
• Use resolved values from ValueSearch to inform accurate DAX filters
• Whenever possible, show progress with icons: 🔍 📊 📝

AVOID

• DAX filters with values that haven't been confirmed present in the data
• Images in terminal environments — use text tables and unicode formatting
• Mentioning DAX, schemas, or tool names in user-facing answers

Workflow

1. Identify the artifact —

• If the user shares a Power BI URL, call ResolveReportIdFromUrl(url) unless the platform already pre-registered the artifact as [rpt_N] / [dataset_N] (in which case use that GUID directly). ResolveReportIdFromUrl is the only reliable way to map a workspace-App report URL to the underlying published-report GUID
• Otherwise call DiscoverArtifacts(searchQuery=)
• If multiple strong candidates exist, surface them and ask the user to pick
• For "list all my reports" enumeration intents (no specific keyword), call DiscoverArtifacts with a broad term — tell the user the result is the top matches, not exhaustive
• Report ID ≠ Semantic-Model ID — GetReportMetadata requires the Report GUID (reportObjectId), while GetSemanticModelSchema, ExecuteQuery, and ValueSearch require the Semantic Model GUID (artifactId). DiscoverArtifacts returns both artifact types with distinct IDs. When starting from a report, call GetReportMetadata first — its response includes the underlying semantic model ID in the semanticModel field, which you then pass to schema/query tools

1. Inspect the report — If the artifact is a Report, call GetReportMetadata(reportObjectId=...) without the queries parameter to get the full response first. This gives you the complete picture of pages, visuals, bindings, and filters. Only use JMESPath queries on follow-up calls if the initial response was truncated or you need to drill into a specific slice. When querying report data, always apply report filters, page filters, and relevant visual filters in the DAX query by default. Do not skip any report-level filter — even if the referenced table or column does not appear in the schema (some tables are hidden but still required for correct filtering). Use TREATAS to apply such filters, e.g. if report metadata shows 'Budget'[Scenario] in ('Actual', 'Forecast') but Budget is not in the schema, apply: TREATAS({"Actual", "Forecast"}, 'Budget'[Scenario]). When the user's question explicitly contradicts a filter (e.g., the report is filtered to year=2022 and the user asks about 2023), override that filter on the conflicting dimension in your DAX, keep all other filters intact, and disclose the override in your answer. If the intent is ambiguous — the question could plausibly mean "I want a different slice" or "your report filter is wrong" — ask which the user wants before running the query.

1. Analyze schema — Call GetSemanticModelSchema(artifactId=...) without the queries parameter to get the full schema first. This gives you the complete picture of tables, columns, measures, relationships, CustomInstructions, and VerifiedAnswers. Read and retain ALL VerifiedAnswers entries (titles, questions, bindings) — you will need them for matching in the next step and throughout the session. Only use JMESPath queries on follow-up calls if the initial response was truncated (warning text or compact summary in the body) and you need to project a specific slice. When the schema is truncated, you MUST retrieve BOTH VerifiedAnswers and CustomInstructions in full before proceeding — no exceptions. Prioritize retrieval in this order: (1) VerifiedAnswers — schema.VerifiedAnswers, (2) CustomInstructions — schema.CustomInstructions, (3) tables/measures relevant to the user's question. Do NOT skip either (1) or (2) — both are required for correct DAX generation.

Custom Instructions (MANDATORY — read in full before generating any DAX): CustomInstructions are domain-specific rules authored by the semantic model owner. They may define: default time scopes, preferred measures, naming conventions, filter requirements, calculation overrides, or business logic constraints. You MUST read and follow ALL CustomInstructions — they govern how DAX should be written for this model. If the schema was truncated and you cannot see CustomInstructions, call GetSemanticModelSchema with queries=["schema.CustomInstructions"] before writing any DAX. Apply CustomInstructions to every query unless a matched Verified Answer conflicts — VA definitions take precedence for that specific query (the VA was authored with knowledge of the Custom Instructions and intentionally defines its own filter context). Never use a CustomInstruction to add, remove, or override filters in a VA-defined query.

1. Check for verified answers (MANDATORY — do this BEFORE writing any custom DAX) — Scan every verified answer's Title and Question for semantic similarity to the user's question. A VA matches if the user's question addresses the same metric, entity, dimension, or analysis intent — even if worded differently (synonyms, rephrasings, different granularity language). Examples of matches: "revenue by region" ↔ "sales breakdown by geography"; "top customers" ↔ "biggest accounts by spend". When ANY VA closely matches, you MUST use it — follow the Verified Answers rules below. Do not skip this step or fall through to custom DAX when a VA match exists. If the full schema response was truncated and you cannot see the complete VerifiedAnswers list, call GetSemanticModelSchema with queries=["schema.VerifiedAnswers[].{Title: Title, Question: Question}"] to retrieve all VA titles before proceeding.

1. Resolve entity values — If the user names a concrete value (a specific customer, product, region, etc.), call ValueSearch(artifactId=, searchTerms=[]) against the semantic model before constructing your DAX filter.

1. Write DAX — Write DAX from the schema, scoped to the columns and measures used by the report's visuals when applicable. Prefer model-defined measures over ad-hoc CALCULATE.

1. Query — Call ExecuteQuery with daxQueries (1–4 entries). Run independent queries in parallel within the same call.

1. Verify — If a query returns BLANK or an unexpected empty result, inspect the schema, measures, and filters and retry at most once with corrected DAX.

1. Answer — Synthesize results into a clear answer with data citations. Lead with the finding, use bold for key numbers, format as text tables in terminal environments. Never mention DAX, schemas, or tool names. Refer to artifacts by name, not by ID.

Follow-up Questions

When the user asks a follow-up about the same artifact:

1. If the new question mentions new entity values, call ValueSearch again
2. Write a new DAX query incorporating context from previous results
3. Call ExecuteQuery and present

Error Recovery

If a DAX query returns blank, few rows, or unexpected totals:

1. Check whether you are querying a date with no data — re-anchor to the correct date that has values
2. Compare your DAX filters against the report metadata filters — a missing filter may return the wrong scope
3. Verify you are using the correct measure — check the report visual's bindings and the measure's DAX expression in the schema
4. If you get a connection error, the measure may depend on a live-connected external data source — try alternative measures from other tables
5. Correct the query and re-execute via ExecuteQuery

Error Taxonomy

| Error | Action | |-------|--------| | Invalid DAX | Read the error message, fix the DAX, retry once | | Unauthorized (no PBI access) | May be a real access issue (admin needs to enable Power BI MCP access), or a known limitation where the tool reports "no access" for artifacts it can't reach. Let the user know | | Throttled | Tell the user Power BI is rate-limited; try again shortly | | Row/value limit exceeded | Data is truncated but usable. Suggest aggregating instead of dumping raw rows | | Feature not enabled | The PBI MCP endpoint may not be enabled on the tenant. Ask the user to contact their admin | | Timeout | The semantic model may be cold-loading. Retry once. If it times out again, suggest the user retry in a few minutes |

Supported Artifacts

Power BI reports and semantic models only. Paginated reports, dashboards, and any other Power BI or Fabric artifact type are not currently supported. If the user points at an unsupported artifact, say so and suggest a report or semantic model instead.

Verified Answers

> ⚠️ Verified answers are the HIGHEST-PRIORITY source of truth. When a VA matches the user's question, it supersedes any custom DAX you would otherwise write — including any filters or scopes derived from CustomInstructions. Use the VA definition verbatim; apply CustomInstructions only when they don't conflict with the VA's bindings, filters, or granularity, and never modify VA-defined elements based on CustomInstructions alone.

When the semantic model contains verified answers, and one matches the user's question:

1. Retrieve the full definition via JMESPath: schema.VerifiedAnswers[?regex_match(Question, 'keyword')] | [0]

• If the initial schema response already contains the full VA definition, use it directly — no additional call needed.
• If you only have titles/questions (from a truncated response), retrieve the full definition now.

1. The verified answer defines a visual specification — treat it as a blueprint to replicate.
2. Build a DAX query that faithfully replicates ALL bindings and filters — do not substitute, omit, or add any columns or measures beyond what the definition specifies:

• The Bindings object maps visual roles (Rows, Category, Columns, Values, Y, Series, Breakdown, etc.) to columns and measures — the list of

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: microsoft
• Source: microsoft/skills-for-fabric
• License: MIT

Install and usage instructions live in the source repository linked above.