What a Claude skill actually changes about a Power BI developer's job

There's a part of the Power BI developer's job nobody puts on the résumé.

It's not the data modelling. It's not the DAX you're proud of. It's the fourth time this month you've added the same kind of slicer to the same kind of chart. It's renaming forty columns, writing measure descriptions you'll never re-read, auditing every title on a 30-page report for the one that's off-brand, rebuilding a tooltip from scratch because the design changed again. The fiddly, exacting, deterministic surgery on the report that eats the hours but never shows up in the demo.

That's the work a skill is built to absorb. And understanding how it does that — not as magic, but as engineering — tells you exactly how the job is about to change.

A skill is not a prompt

This is the distinction most people miss, so it's worth being blunt: a skill is not a clever prompt, and it is not a chatbot that writes Power BI for you. A prompt runs once and improvises. A skill is a structured, reusable capability — and the structure is the whole point.

Strip one open and you find the same parts every time, each doing one job:

The brain (SKILL.md) — when to use it, what to ask you for, which step runs next, how to read the result, what to do when something fails. Orchestration, not "do magic."
The muscle (scripts) — the precise, deterministic execution: parse the files, apply the change, validate the output. Same input, same output, every time. This is where "AI might hallucinate" is replaced by "code that just works."
The knowledge (references) — the written-down expertise the skill consults before it acts: which approach your model needs, the rules for the edge cases, where the obvious answer quietly fails.
The transparency (README) — what it does, when not to use it, its known limits, how to fork it. No black box.
The materials (assets) — the ready-made icons, templates, and styling it ships with, so the output is on-brand on the first pass.

The reason that split matters to you, the developer: the judgment lives in plain language you can read and challenge, and the execution lives in code that can't drift. You're never trusting a model's mood. You're running a capability that behaves the same on Tuesday as it did last month.

What I learned taking my own library apart

I run a library of 35+ of these skills — 44,000+ lines of engineering behind them. Recently I measured what they actually cost and how they behave, because "AI tool" claims deserve numbers. Three findings are worth sharing:

1. They're almost free until you use them. Every skill advertises itself to the model in about a paragraph. Dozens of skills sit available at the cost of roughly a single screenshot — the full instructions only load when a skill is actually invoked. "Loads only what each task needs" isn't a slogan; it's measurable.

2. The heaviest skill has the lightest instructions. The most capable skill in the set carries the smallest set of loaded instructions, because thousands of lines of logic live in scripts that run without ever being read into the model's context. Capability and context cost are decoupled. That's why a big library stays fast.

3. The real weight is your project, not the skill. On a realistic report, reading every model and report file to "understand it" would run past a million tokens — more than fits in context at once. A single discovery step compresses that to a short summary, on the order of 200× smaller. The skill doesn't dump your project into a chatbot and hope; it looks, summarises, then acts surgically.

None of that is the flashy part. It's the boring engineering that decides whether a tool survives contact with a real, messy, 100-visual production report — and most don't.

The anatomy, inside one afternoon

Make it concrete. Say you need a rolling time-period control on a chart — the kind of thing that, by hand, means new tables, new measures, a new slicer, rewired interactions, and bookmark state that all has to agree. By hand that's an afternoon, and a fair chance of a half-finished result a week later when a bookmark quietly drops a filter.

As a skill it's one run. The brain decides what your model needs and what to ask you. The muscle makes the exact edits across the data and report layers and validates them. The knowledge already encodes the edge cases that would otherwise bite — the ones I learned the hard way, written down once so they're never re-learned. You review the result, not the wiring.

That's the shift in one sentence: you stop doing the surgery and start directing it.

What actually changes for you

Not your job title. The altitude of your work.

The repetitive, exacting tasks — the ones that were necessary but never valuable — stop being where your hours go. What's left is the part that was always the actual job: the modelling decisions, the data design, the questions the report should answer, the judgment about whether an output is right. The skill is fast and tireless and consistent; it is not the one deciding what's worth building. You are.

There's a quieter benefit, too. When the tedious 20% is automated correctly, consistency stops being a discipline problem. Every chart gets the same well-made tooltip. Every report passes the same title audit. The floor under your team's output rises, and it stays risen, because a skill runs forever where a one-off effort runs once.

Why this is landing now

Three things turned this from a neat idea into something you should have an opinion on:

Microsoft made the Power BI report layer programmable "in a fully supported way," and is rolling that format out as the 2026 default — the report became code.
Anthropic published the skill format as an open standard, with the same progressive-disclosure design measured above — so this isn't a private trick, it's an emerging way of working.
And Microsoft itself is now shipping agent skills for Power BI — which is the clearest signal that this is the direction, not a detour.

The developers who do well in that world won't be the ones who can hand-edit a visual.json fastest. They'll be the ones who can build and direct the capabilities that do it — and who know the difference between a tool that demos and one that holds.

A prompt runs once. A skill runs forever. The job is moving from doing the work to engineering the things that do the work — and that's a better job.

Pawel