Check Updates
At most once per week, compare your local skills-for-fabric marketplace version to GitHub releases and surface changelog context before other Fabric skills run.
Overview
check-updates is a journey-wide agent skill that compares skills-for-fabric marketplace versions to GitHub releases—usable whenever a solo builder needs to verify skill freshness before committing to Fabric-guided work.
Install
npx skills add https://github.com/microsoft/skills-for-fabric --skill check-updatesWhat is this skill?
- Weekly cadence: run once per week when any skills-for-fabric skill is first invoked
- Compares local version against GitHub releases and shows changelog when updates exist
- Persistent marker at ~/.config/fabric-collection/last-update-check.json keyed by plugin name
- Skips repeat checks if the plugin entry is within the last 7 days (UTC date comparison)
- Triggers include "check for updates", "am I up to date", "what version", "update skills", "show changelog"
- 7-day UTC cadence between update checks per plugin
- Shared state file ~/.config/fabric-collection/last-update-check.json
Adoption & trust: 54 installs on skills.sh; 427 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You invoke Fabric marketplace skills without knowing whether local copies lag GitHub releases or what changed in newer versions.
Who is it for?
Builders using skills-for-fabric daily who want a low-friction weekly version gate tied to shared ~/.config/fabric-collection state.
Skip if: Projects not using skills-for-fabric, or teams that enforce updates only through corporate package mirrors without GitHub release access.
When should I use this skill?
Triggers: "check for updates", "am I up to date", "what version", "update skills", "show changelog"—and once per week on first skills-for-fabric skill invocation.
What do I get? / Deliverables
After the skill runs, you either see release and changelog context for an available update or confirm the weekly check marker so other Fabric skills can proceed without redundant version polling.
- Update availability verdict vs GitHub releases
- Changelog summary when a newer version exists
- Updated last-update-check.json entry for the plugin
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Confirm Fabric research skills are current before trusting competitive analysis prompts.
See whether new Fabric skills shipped before wiring them into your agent config.
Verify deployment-related Fabric skills match latest release notes before a production push.
Weekly changelog pass to decide if marketplace updates warrant reinstall.
How it compares
Use this meta check instead of manually diffing the marketplace repo every session you open an agent.
Common Questions / FAQ
Who is check-updates for?
Solo builders and small teams on the skills-for-fabric marketplace who want automatic version awareness before Fabric-specific skills execute.
When should I use check-updates?
At session start when any Fabric skill loads (weekly at most); during Idea when picking research skills; during Build or Ship when Fabric helpers touch your repo; and during Operate when you audit agent tooling versions—or when you explicitly ask to check updates or show the chan
Is check-updates safe to install?
Review the Security Audits panel on this Prism page; the skill reads local config and queries GitHub releases—confirm you trust the marketplace source before auto-following upgrade prompts.
SKILL.md
READMESKILL.md - Check Updates
# Check for Updates This skill checks for updates to the skills-for-fabric marketplace at the start of each session. ## When to Run Run this check **once per week** when any skills-for-fabric skill is first invoked. Skip if already checked within the last 7 days. ## Session State The update check marker is stored in a **persistent, user-level directory** shared across all sessions and all plugins in the Fabric Skills marketplace: ```text ~/.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: ```json { "fabric-skills": "2026-02-17", "another-plugin": "2026-02-16" } ``` Before checking, read `~/.config/fabric-collection/last-update-check.json`: - If the file exists and the entry for the current plugin is within the last **7 days** (compared to the current **UTC date**), skip the check. - If the file is missing, the plugin entry is absent, or the date is more than 7 days old (compared to the current **UTC date**), run the update check. > **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\`. ## Update Check Procedure ### Step 1: Get Local Version Read the `version` field from the local plugin manifest. Two install layouts exist: - **GitHub Copilot CLI plugin install** (`~/.copilot/installed-plugins/fabric-collection/fabric-skills/`): the manifest is `.github/plugin/plugin.json` — there is no `package.json` here. - **Manual git clone**: the manifest is `package.json` at the repo root. Read whichever is present. Both files contain a top-level `"version": "<semver>"` field. ### Step 2: Determine Repository Owner and Name 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: - **Copilot CLI plugin install** (`.github/plugin/plugin.json`) — plain URL string: ```text "repository": "https://github.com/<owner>/<repo>" ``` - **Manual git clone** (`package.json` at the repo root) — object whose `url` ends with `.git`: ```text "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 `repository` URL says, that is the correct owner. (LLMs sometimes "auto-correct" underscores to hyphens — don't.) ### Step 3: Fetch Latest Release 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. **