You know how it goes. You're deep in some code, implementing a new feature or reading about another cool thing you can do with your brain and AI power, when — BUZZ — the work chat blows up. 15 seconds later, you're on an emergency call with the top dogs asking what we can do about it.

Sometimes it happens so fast that users never even notice the issue, chalking it up to a "network error" or "overheated device" — while deep in the Kibana logs, in the silence of traces and spans, the issue grows until it's finally caught by an alert and lands in your inbox as "This isn't an emergency, but it looks suspicious...". Some of you may have a first-class aggregation system that does the job for you, delivering the full picture along with your morning cappuccino. In my case, I have to read Kibana logs across different Kibana instances, check traces in Datadog, dig through the Wiki, JIRA, or even GitHub, and finally tie all the strings together.

One day, filling out yet another investigation report — two-thirds of which were log excerpts showing the same broken workflow — it hit me: "Why am I still doing this?" The investigation and deduction are the fun part. The tedious part is logging into every resource, defining the same time interval five times, copying and combining logs, and tracking down trace IDs (which can mutate as a message travels through different systems).

The trick: don't design the SKILL, discover it

Here's what I want you to take away: don't sit down to design a complex SKILL from scratch. Do the work with the AI, then ask it to codify the workflow into a SKILL afterwards. The conversation is the spec.

This works because a SKILL is just a program written at a higher level of abstraction. And the easiest way to write that program is to run it manually first, with the AI watching.

How it played out

I already had a Swiss Army knife of skills I use in regular work:

• a git reader (curl-based)
• an Atlassian Wiki skill (read/write Wiki pages)
• a JIRA skill (read/write tickets)
• a Datadog reader (query traces)

So the next time an alert landed, instead of opening five tabs, I just started asking:

"Check the logs for this time interval for %USER%."
"Analyze the Datadog traces for error responses and cross-reference them against the collected logs — find matches, highlight suspicious patterns."
"Build an issue timeline and list the systems involved."

And here's the kicker — the GitHub skill. Once you know the application version, you can pull the sources, find the exact module producing the error, point right to it in the report, and even run a simulation against the affected app to nail down the root cause.

When the report was ready, instead of clearing the context, I asked: "Create a new SKILL based on this conversation." Review, save, done. That's issue-investigator.

From the first alert to a complete report: 5 minutes on a simple issue, a few hours on the gnarly PROD ones — end-to-end, with me reading the result instead of assembling it.

Keep your skills sharp

A SKILL built from one real investigation isn't finished — it's a v1. Every time you reuse it and spot a rough edge, polish it. That's how a SKILL stays sharp.

And once it is sharp — share it with your team. If you cut down the time you spend on tedious work, you boost your own efficiency. Spread that tool across your team and you boost everyone's. That's the multiplier you don't get from solving the problem alone.

And when every team works this way, SKILLs stop being personal productivity hacks — they become the operating system of the company.