Agent Skills the Team Runs On

Objective

Until this year, a custom dashboard was not something we built. If a question needed a view, it went into the BI tool, and if the BI tool could not do it well, the answer was that the question was awkward.

I brought a different route in: build the thing, in our stack, from a brief. The problem is that this only scales if it is not me doing it every time. A coding agent starts every session knowing nothing about how we work — it re-derives the same conventions, asks the same questions, and occasionally invents a plausible answer where a house rule already existed.

The fix is not a longer prompt. It is putting the conventions somewhere the agent loads when the task matches, so the knowledge arrives on the relevant turn instead of sitting in context on every turn.

Approach

Four skills, each one earned by a mistake I did not want to see twice.

Dashboard scaffolding. Our dashboards share a stack, a design system in light and dark, a deploy config shape and a set of layout conventions. Crucially, the deployment conventions in there are our data engineers’, not mine — written down by the people who own that part. So a dashboard I build arrives deploy-ready without me guessing at their job, and a new dashboard starts consistent instead of arriving at consistency through review.

Repository workflow. Several repositories have protected main branches, so a push fails and the tempting recovery is a hard reset that eats uncommitted work. This skill makes the workflow explicit: ask how the change should be delivered, branch and open a merge request rather than pushing, never reset without checking status first — and treat notebooks as the exception, since they are always mid-experiment.

Analytics queries. Report suites, segments, metrics and dimensions all have exact identifiers. Without them the agent asks four clarifying questions before every query. With them it just answers, using the defaults we would have picked anyway.

Segmentation changes. Adding an audience means a coordinated edit across two files with invariants that break silently when they drift. This skill states the invariants and the order of operations, turning a delicate manual edit into a bounded one.

What I learned

The description matters more than the body. A skill that never triggers is worth nothing, so each description lists what a request might actually look like — including phrasings that never mention the skill by name. Getting that wrong is the most common failure, and it fails invisibly: the agent carries on without the knowledge and does something reasonable but wrong.

Second lesson: the useful content is the quirks, not the happy path. A model can infer a sensible git workflow. It cannot infer that a particular subprocess hangs on Windows unless an environment variable is set, or that one plotting config silently renders nothing. Those specifics are the whole value.

Outcome

The skills are used across the team, not just by me — which was the point, and the part that turned a personal habit into how we work.

The consequence is bigger than tooling. Custom dashboards went from “not something we do” to the default answer, and with the workbooks they replaced now redundant, we are retiring the commercial BI stack. The saving is real and not the point — what changed is that the constraint which used to shape what we were willing to ask has gone.