Most of my coding-agent skills so far have been for workflow automation — committing, deploying, reviewing. But I recently wrote two skills for external services — betterstack-log-export and postmark-setup — and they turned out to work differently.

Write skills during the task, not before

betterstack-log-export started when I was tracking down why a weekly email report was failing. I needed to filter Better Stack logs by time range and fields like from and level. I figured out the right approach — both the manual UI export and the curl/ClickHouse query — and set an in-session reminder to turn it into a skill.

postmark-setup was even more direct. I was deploying DevSnoop and needed Postmark servers. I gave the agent my account token, told it to follow the pattern from my existing betterstack-source-setup skill, and the new skill was written and used in the same session.

I wrote both during or right after the actual task, which meant I already knew what to encode instead of guessing at it.

What to put in the skill

Most of the time goes into deciding what belongs in the skill.

For betterstack-log-export, what mattered:

  • UI path for one-offs: Telemetry → filter view → gear → Download → NDJSON
  • curl path for repeatable queries: Integrations → Connect ClickHouse HTTP client
  • EU/US cluster split — which of my projects are on which cluster
  • Collection names — t337893_theblue_logs, t337893_theblue_s3, etc.
  • Credential locations: ~/.config/betterstack/eu.env and ~/.config/betterstack/us.env
  • Query pattern: UNION ALL over hot + archived logs — not obvious from the docs
  • JSONExtract patterns for nested fields (JSONExtractRaw for nested objects)
  • Concurrency limit: Standard tier allows 4 concurrent log queries, so retry on failures

None of this is in the Better Stack docs as a package. It’s my account topology, my file layout, and the things I discovered by doing it once.

For postmark-setup, different knowledge but the same idea:

  • Create both dev and prod servers, not just one
  • Naming convention: <ProjectName> dev and <ProjectName> prod
  • The returned Server API token works as both SMTP username and password — not obvious
  • Update .env for dev, .env.kamal for prod
  • Remind about sender signature/domain verification in the Postmark UI

That last one is easy to forget. Without it in the skill, the agent finishes the API work, everything looks fine, and then email silently fails in production.

Include both the UI path and the API path

betterstack-log-export covers two ways to get at logs:

  • Manual/one-off: filter in the UI and download NDJSON from the gear menu
  • Repeatable/scripted: query the ClickHouse HTTP API with curl

I discovered the UI download first, before reaching for the API. It’s faster when you just need to eyeball what happened. The curl path is for reproducible filters, row counts, or anything you might run again.

An agent that only knows the API will always reach for curl. Sometimes the right answer is downloading 200 rows from the UI and piping them through jq. Encoding both paths means the agent can pick the right one.

Keep credentials outside the skill

Both skills store credentials under ~/.config/<service>/ and source them at runtime. Nothing in the skill body, nothing in the repo.

source ~/.config/betterstack/eu.env

Skills are text files — they can end up in shared directories, version control, or another agent’s context. Keeping credentials out means you don’t have to think about it when you share or reorganize skills.

The pattern came from betterstack-source-setup, which predates the log-export skill. When I wrote postmark-setup, I followed the same layout: ~/.config/postmark/api.env, sourced at runtime.

Trim it down

The first version of betterstack-log-export was much longer than the current one. More explanation, more examples than the agent would ever need. Most of that was useful while I was figuring things out, but the agent at runtime just needs to know which cluster to hit, where the credentials are, and what SQL pattern to use.

I trimmed it in the same session. The current version has one section each for the quick path, clusters, credentials, query pattern, and guardrails.

What the agent can’t get from docs

The agent can read Better Stack’s API docs or Postmark’s SMTP reference on its own. What it can’t figure out is which cluster my project is on, what naming convention I use for servers, or that the returned API token doubles as the SMTP password. That’s the knowledge that gets lost between sessions and re-discovered every time — unless a skill holds it.

Use the skill immediately

postmark-setup was used in the same session it was written — I set up DevSnoop’s dev and prod servers with it right away. If the skill was wrong or incomplete, I’d have found out on the spot.

betterstack-log-export was used within a few sessions, running real queries against real log data. The JSONExtract patterns were refined once during actual use. The first version is a starting point — it gets better when you exercise it.