axiomhq / gilfoyle

The one skill, gilfoyle, does incident response and root-cause analysis by querying an observability stack directly: OTel metrics through a custom query language (MPL) and logs through Axiom's own APL, plus Grafana alert and datasource checks, Pyroscope flamegraph diffing, and posting results to Slack. Its scripts are grouped into seven categories — 5 for Axiom, 4 each for Grafana and Pyroscope, 1 for Slack, plus memory, setup, and test scripts — and it keeps a persistent memory of past incidents and queries under ~/.config/gilfoyle/memory/. Setup runs scripts/init, which writes a single TOML config for whichever deployments you actually have and can migrate existing ~/.axiom.toml or ~/.grafana.toml files into it.

This is for on-call and SRE engineers already running Axiom, Grafana, or Pyroscope as their observability stack. Its usefulness scales directly with how many of those you have configured; none of the four integrations is optional the way a no-account reference skill would be — the package's single dependency class is an account key, and that's accurate for every query that actually touches real data.

READ THE FULL ANALYSIS＋

A hard local dependency the dependency label doesn't capture. The README states Gilfoyle "uses timeout (GNU coreutils)" and tells macOS users to brew install coreutils before anything else works — a local-tool requirement on top of whichever accounts you configure.

The tone is part of the product. The README's voice throughout is deliberately abrasive — "Doesn't care about your feelings," "Unlike you, I learn" — worth knowing before handing this persona to a team that wants a plain incident report rather than commentary.