plugins/fabric-operations/skills/check-updates/SKILL.md
Check for skills-for-fabric marketplace updates at session start. Compares local version against GitHub releases and shows changelog if updates are available. Use when the user wants to: (1) check for skill updates, (2) see what's new in skills-for-fabric, (3) verify current version. Triggers: "check for updates", "am I up to date", "what version", "update skills", "show changelog".
npx skillsauth add microsoft/skills-for-fabric check-updatesInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
This skill checks for updates to the skills-for-fabric marketplace at the start of each session.
Run this check once per week when any skills-for-fabric skill is first invoked. Skip if already checked within the last 7 days.
The update check marker is stored in a persistent, user-level directory shared across all sessions and all plugins in the Fabric Skills marketplace:
~/.config/fabric-collection/last-update-check.json
This file contains a JSON object mapping plugin names to the UTC date (YYYY-MM-DD) of their last update check:
{
"fabric-skills": "2026-02-17",
"another-plugin": "2026-02-16"
}
Before checking, read ~/.config/fabric-collection/last-update-check.json:
IMPORTANT — use UTC consistently: Always use the current UTC date when saving and comparing the last-update-check timestamp. Do not use the local system timezone, as it varies across environments and can cause the check to run too often or be skipped. In shell, use
date -u +%Y-%m-%d(Linux/macOS) or(Get-Date).ToUniversalTime().ToString("yyyy-MM-dd")(PowerShell).
Note: Create the
~/.config/fabric-collection/directory if it does not exist. On Windows, use$env:USERPROFILE\.config\fabric-collection\.
Read the version field from the local plugin manifest. Two install layouts exist:
~/.copilot/installed-plugins/fabric-collection/fabric-skills/): the manifest is .github/plugin/plugin.json — there is no package.json here.package.json at the repo root.Read whichever is present. Both files contain a top-level "version": "<semver>" field.
Read the repository field from the same manifest you used in Step 1, and parse the URL to get owner and repo. The two layouts store the field differently:
.github/plugin/plugin.json) — plain URL string:
"repository": "https://github.com/<owner>/<repo>"
package.json at the repo root) — object whose url ends with .git:
"repository": { "type": "git", "url": "https://github.com/<owner>/<repo>.git" }
There is no bare plugin.json at the repo root in either layout, and there is no top-level package.json in the Copilot CLI plugin install — always use the path that matches your actual layout.
CRITICAL: Use the owner string exactly as it appears in the URL. Do NOT alter, normalize, or "correct" the owner name — including underscores, mixed case, or any other punctuation. Whatever the manifest's
repositoryURL says, that is the correct owner. (LLMs sometimes "auto-correct" underscores to hyphens — don't.)
Use the available tools in your environment to get the latest version. Try methods in strict order — only fall back to the next method if the previous one fails or is unavailable.
IMPORTANT: Methods A and B work with both public and private repositories. Method C only works with public repos. Always attempt A or B first.
Method A — Git CLI (preferred for git-clone installs)
Only available if the skills-for-fabric directory is a Git working tree (i.e. it has a .git entry — either a directory in a normal clone, or a file in a worktree/submodule). The Copilot CLI plugin install at ~/.copilot/installed-plugins/fabric-collection/fabric-skills/ has no .git entry — for that install layout, skip to Method B. If you want a tool-agnostic check, run git rev-parse --is-inside-work-tree and only proceed if it prints true.
If you do have a Git clone, fetch the remote package.json without pulling:
git fetch origin main --quiet
git show origin/main:package.json
Extract the version field from the JSON output. This method is the most reliable because it uses the already-configured remote URL and authentication, and avoids any owner/repo name parsing.
Method B — GitHub MCP tools (preferred for agentic environments)
If you have access to GitHub MCP server tools (e.g., get_file_contents), use them to read the remote package.json. Use the owner and repo extracted in Step 2 exactly as parsed (do not modify the strings):
get_file_contents(owner: "<owner>", repo: "<repo>", path: "package.json")
Extract the version field from the response. This method works with private repositories because MCP tools use authenticated GitHub access.
Method C — GitHub REST API (fallback only, public repos)
⚠️ Only use this method if Methods A and B both fail or are unavailable. This method does not work with private repositories.
If the repository is public, make a GET request using the owner/repo from Step 2:
GET https://api.github.com/repos/<owner>/<repo>/releases/latest
Extract the tag_name field (e.g., v0.2.0) and remove the v prefix.
Note: This method returns 404 for private repositories. If you receive a 404 error, do NOT assume the repository doesn't exist — retry with Method A or B.
Compare the local version with the remote version using semantic versioning:
Show a brief confirmation and proceed:
✅ skills-for-fabric v0.1.0 is up to date.
Show detailed information:
╔══════════════════════════════════════════════════════════════════╗
║ 🔄 skills-for-fabric Update Available ║
║ ║
║ Current: v0.1.0 → Latest: v0.2.0 ║
╚══════════════════════════════════════════════════════════════════╝
## What's New in v0.2.0
[Display relevant CHANGELOG.md entries here]
## Update Commands
Choose the update method based on how you installed skills-for-fabric.
### GitHub Copilot CLI (recommended)
/plugin update fabric-skills@fabric-collection
If you originally installed the plugin under the legacy id, this also works:
/plugin update skills-for-fabric@fabric-collection
The plugin was renamed in 0.3.0 (skills-for-fabric → fabric-skills),
but the legacy id is kept as a deprecated alias of fabric-skills, so
either /plugin update command pulls the canonical payload.
(Optional cleanup) To migrate your installed entry from the legacy id
to the canonical fabric-skills id:
/plugin uninstall skills-for-fabric@fabric-collection
/plugin install fabric-skills@fabric-collection
### Manual (Git clone)
cd /path/to/skills-for-fabric
git pull
(There are no installation scripts to re-run on 0.3.0+.)
─────────────────────────────────────────────────────────────────
Would you like to update now? (The current skill will still work)
After completing the check (regardless of result), update ~/.config/fabric-collection/last-update-check.json with today's UTC date (YYYY-MM-DD) for the current plugin. Create the directory and file if they don't exist. Preserve entries for other plugins already in the file.
~/.config/fabric-collection/last-update-check.jsonIf the update check fails (network error, API rate limit, etc.):
⚠️ Could not check for skills-for-fabric updates (network error).
Continuing with current version (v0.1.0).
Run '/skill check-updates' manually to retry.
Users can manually check for updates at any time:
/skill check-updatesCHANGELOG.md in repository rootdevelopment
Build a guided requirements-to-implementation workflow for new Power BI reports and dashboards from semantic models, datasets, or PBIP projects. Use when the user wants to: (1) plan then implement a report, (2) define audience, scope, page plan, design direction, dependencies, and delivery target, (3) create a locked report spec with approval before PBIR authoring. For direct edits to existing report files, use `powerbi-report-authoring`. For design-only critique or redesign, use `powerbi-report-design`. Triggers: "build me a dashboard", "create a new report", "plan then implement", "define and build Power BI report", "walk me through creating a report".
tools
Manage Power BI report workspace items in Microsoft Fabric via `az rest` CLI against the Fabric REST API. Use when the user wants to: (1) create reports from PBIR definitions, (2) get or download report definitions, (3) update report definitions or properties, (4) list workspace reports, (5) delete reports. For report layout authoring (pages, visuals, filters, formatting), use `powerbi-report-authoring`. Triggers: upload Power BI report, download PBIR definition, publish Power BI report to Fabric, manage Power BI reports.
development
Generate Power BI report visual design guidance before PBIR files are written. Use when the user wants to: (1) choose tone, signature, page archetypes, chart types, layout, color, typography, theme direction, or accessibility approach, (2) redesign/restyle an existing report, apply a brand, or critique chart/layout choices, (3) produce a design contract for `powerbi-report-authoring`. For end-to-end requirements, approval, and build sequencing, use `powerbi-report-planning`. Triggers: "design Power BI report", "make dashboard look professional", "choose chart type", "apply brand to report", "redesign report", "create design brief".
tools
Create and modify Power BI report files in PBIR/PBIP format using the `powerbi-report-author` and `powerbi-desktop` CLIs. Use when the user wants to: (1) implement an approved report spec or design brief, (2) add or edit pages, visuals, filters, slicers, bookmarks, themes, or formatting, (3) validate PBIR and verify rendering in Power BI Desktop. For open-ended visual design, use `powerbi-report-design` first. For end-to-end requirements and approval workflow, use `powerbi-report-planning` first. Triggers: "edit PBIR", "create Power BI report page", "add visual to PBIP", "format report visual", "validate Power BI report", "reload Desktop screenshot", "implement an approved PBIP report spec", "edit PBIR pages/visuals".