September 2026 agent skills: Fabric and Copilot changes

The September changes that affect existing skill setups

September brought useful changes to how teams install specialised skills and understand whether people use them. Microsoft's Fabric collection added a single-skill installation route, consolidated its Power BI report workflow and expanded report guidance. GitHub added Copilot CLI customisation metrics covering skills, agents, MCP servers, commands and plugins.

These changes address different parts of the same operational problem. A team needs to choose the right instructions, give them the right tool access and check whether the resulting workflow helps. Installing a larger collection does not answer all three questions. Neither does a rising invocation count.

This retrospective covers releases during the September publishing gap, with October follow-up information clearly identified. It is written on 30 October 2026. The historical dates below describe the upstream events, not an earlier publication date for this article.

The Fabric release timestamps fall on 11, 18 and 25 September respectively in Sydney. The v0.3.18 release body carries a 24 September heading, while GitHub's publication timestamp is 25 September. Keeping those dates distinct avoids treating a changelog heading as proof of release availability.

Fabric adds a single-skill installation route

Fabric v0.3.16 introduced APM manifests and documented installing a selected skill from the repository. It also addressed MCP setup references and local Claude Code authentication configuration. The important distinction is between choosing a skill and installing a complete plugin bundle.

For a team that needs one specific workflow, a selection mechanism is valuable. It can make the active set easier to understand and review. However, selection alone does not tell you everything the package manager will fetch, register or link. Read the installation plan and the package's dependency rules before treating the result as a minimal environment.

The v0.3.18 README documents an APM installation using the repository as the package root and a skill selector. For example, with APM already installed, a review-first invocation for the documented SQL warehouse skill is:

apm install microsoft/skills-for-fabric --skill sqldw-cli --target copilot --dry-run

This asks for a plan rather than applying the installation. Choose scope and target deliberately before removing the preview flag. The README explains that Copilot project scope writes MCP configuration for VS Code, while global scope reaches Copilot CLI's configuration. A visible skill and missing tools can therefore be a scope problem rather than a broken skill.

Do not replace the repository source with a guessed deep path. Fabric uses shared reference material, and its documented packaging explains how that material is made available. A folder that looks self-contained in a web interface may still rely on files elsewhere in the package.

Review instructions and tool access separately

The Fabric installation notes also distinguish skill activation from MCP registration and package materialisation. Read those notes as part of an installation review, particularly when the intended change is “add one workflow” rather than “configure every service in this collection”. The documented --only apm option allows skill deployment without registering MCP servers.

That distinction is familiar from Agent Skills vs MCP, but package managers make it easy to overlook. A skill tells the agent how to perform a task. A server connection supplies live access. A package can deliver both, so reviewing only SKILL.md is not enough to understand the installed environment.

For an internal rollout, use a small written decision record. The following is an illustrative checklist, not a Fabric manifest:

Requested workflow: inspect an existing warehouse design
Selected skill: sqldw-cli
Agent target: the tool our team actually uses
Installation scope: reviewed before applying
Live connections: reviewed separately from instructions
First task: read-only inspection of a non-production example
Success check: the agent can explain its inputs and required access

The point is to record why each component is present. If a colleague later asks why a server was registered, the answer should be more specific than “it came with the skill”. This record is especially useful when several developers use different clients but share the same repository.

Power BI report work becomes one routed workflow

Fabric v0.3.17 introduced powerbi-report-cli as one skill spanning report planning, design, authoring and management. The release replaced four separate report skills in the Power BI authoring bundle. It also added field-parameter guidance to semantic-model authoring and changed the FabricIQ connection details.

The editorial significance is consolidation. Counting files would make a four-to-one change look like a reduction in capability, even when the intended workflow becomes easier to select. This is one reason directory growth should count distinct useful workflows rather than every mirrored or repackaged instruction file.

For the person requesting a report, describe the outcome and the current stage. “Review this report plan before editing files” and “publish this approved report” are different requests. A unified entry point should make that distinction easier to express; it should not erase the difference between planning, local modification and an external write.

Consider a report that already exists. Before asking for visual changes, establish the audience, the decision the report supports and the data model it depends on. A visually attractive chart with the wrong measure is still wrong. Conversely, a correct query does not establish that the report explains the result clearly to its intended reader.

The guide to writing an agent skill is relevant here. A skill's discovery description and routing instructions should help the agent choose the right stage. A larger instruction body is not automatically better if it makes unrelated stages difficult to distinguish.

Late-September Fabric changes emphasise validation

Fabric v0.3.18 expanded report guidance around interactions, previews, model binding and publishing checks. It also added project-osmos guidance for longer Fabric and OneLake tasks and updated Synapse migration workflows.

The useful lesson is that generating an artifact and validating it are different jobs. A report file can be syntactically valid while binding to the wrong model. A preview can look plausible while a particular filter or drillthrough route behaves incorrectly. A migration plan can be useful before any source rows are moved.

For a report change, define a small acceptance walkthrough. Start from the intended opening state, apply the filters a reader will use, follow a navigation action and check the resulting measure. If the work changes model binding, include an explicit check of the intended model rather than relying on visual similarity.

Keep the walkthrough proportional to the change. A typography adjustment does not need the same checks as a semantic-model migration. The test should target the risk introduced by the work, not simply repeat that the agent wrote a file successfully.

The same reasoning applies to long-running tasks. Record the approved objective and the current evidence before continuing. A later session should be able to tell whether a step was planned, attempted or completed. That reduces the chance that a resumed workflow repeats an external operation merely because its earlier result was poorly recorded.

Copilot adds customisation adoption metrics

GitHub's 17 September announcement introduced CLI customisation metrics. Its categories include skills, custom agents, MCP servers, slash commands and plugins. The counters do not all describe the same event, and plugin skill interactions overlap with skill interactions.

For adoption reporting, decide which question each metric is meant to answer. “Are people trying the workflow?” differs from “does the workflow improve the outcome?” The first may be informed by invocations. The second needs evidence about completed work, review effort or the quality of the result.

Avoid a dashboard that combines every category into one large activity total. That may count overlapping events and make the result look more precise than it is. Instead, give each measure a plain-language label and retain the category definition beside it.

An illustrative internal scorecard might pair a usage trend with a small review sample:

This is a suggested evaluation design, not a GitHub API response schema. Use the current API documentation when implementing a report.

October changes how custom names appear

On 22 October, GitHub expanded the reports to include configured names for customer-defined customisations. The update also increased the number of entries shown and described client-version requirements. It does not retroactively rename earlier report days.

That creates a break in how an adoption chart should be interpreted. A newly visible named skill may previously have contributed to an aggregate custom category. Its first named appearance is not necessarily the first day anyone used it.

Annotate that change in reporting. Keep the historical aggregate alongside the new detail if it helps explain continuity, but do not allocate earlier anonymous counts to individual skills without evidence. Doing so would turn an unknown into a fabricated historical trend.

Configured names can also reveal internal information. Before sharing a report externally, inspect its labels as well as its numeric values. An aggregate report can still contain sensitive project terminology even when it contains no individual user's name.

Troubleshoot rollout problems before judging a skill

When a skill appears unused, first establish whether it was available in the intended client. A package may have been installed in a different scope, the active session may not have refreshed, or the workflow may need a connection that was never configured. These are deployment questions, not evidence that the instructions lack value.

When a report appears empty, distinguish absence of activity from unavailable telemetry. GitHub's metrics documentation describes limitations in coverage. A chart should preserve the difference between a real zero and data that is missing, otherwise a setup problem can look like a behavioural change.

When a report workflow produces the wrong result, isolate the stage. Check the requirement, the model, the generated artifact and the preview separately. Rewriting the entire prompt before locating the error can hide the original cause and make the next result harder to compare.

For structured checks, see how to test an agent skill. Keep test inputs synthetic where possible and record what was actually verified. The security guide covers the separate review of instructions, scripts and access to external systems.

What to carry into the next rollout

Use September's changes to make installation and evaluation more deliberate. Select a workflow because it serves a real task, inspect the package and connection plan, and verify that the intended client can use it. For reporting, preserve the definitions behind the numbers and explain changes in what the telemetry exposes.

For a small team, that can be a short review record rather than a new governance system. Name the workflow, the reviewed version, its live dependencies and the first acceptance check. Add a note when an update changes scope, packaging or the meaning of an important metric.

Browse the skill directory for individual workflows, but return to the canonical source before installation. A useful catalogue entry should help you choose and inspect a skill. It should not replace the judgement involved in connecting that skill to a team's data and production tools.