Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add tmj-90/gaffer --skill observability-designergit clone --depth 1 https://github.com/tmj-90/gafferWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/tmj-90/gaffer/observability-designer)<a href="https://agentmods.dev/skills/tmj-90/gaffer/observability-designer"><img src="https://agentmods.dev/badge/skills/tmj-90/gaffer/observability-designer/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/tmj-90/gaffer/observability-designer"><img src="https://agentmods.dev/badge/skills/tmj-90/gaffer/observability-designer.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00067 | $0.01253 |
| Opus 5.5 | $0.00027 | $0.00501 |
| Sonnet 5.5 | $0.00013 | $0.00251 |
| Haiku 4.5 | $0.00007 | $0.00125 |
Grade A, and why
observability-designer scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 86 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Design production-ready observability
Instrument a service so the on-call engineer can answer three questions without shipping
new code: is it broken for users, where, and why. Build on OpenTelemetry conventions so
signals correlate across services and vendors; page only on user-visible symptoms.
Line-level logging and span code belongs to the structured-logging-and-tracing skill;
SLO targets and burn-rate math belong to slo-architect.
Signals and what each must carry
| Signal | Minimum contract |
|---|---|
| Resource | Every signal carries service.name (required by OTel), service.version, deployment.environment.name |
| Metrics | RED per endpoint (rate, errors, duration histogram), USE per resource (utilisation, saturation, errors). Use OTel semantic-convention names where they exist, e.g. http.server.request.duration |
| Traces | W3C traceparent propagated on every inbound and outbound hop (HTTP, queue messages, jobs); spans at process and dependency boundaries |
| Logs | Structured JSON with trace_id and span_id on every line emitted inside a request, so logs join traces |
Cardinality rule: metric labels come from bounded sets (route template, status class, method). Never label by user ID, request ID, raw URL or error message — those go on spans and logs.
Procedure
- Read what exists.
search_lorefor APM tooling, dashboard conventions, alert routing. Grep the repo for the telemetry SDK, exporter config, metric names and alert rule files. Extend in place; do not add a second telemetry stack. - Map the service contract. List the user-facing operations (endpoints, jobs, consumers) and each dependency. Each operation gets RED metrics and a span; each dependency gets a client span and error/latency metrics.
- Instrument the golden signals first — latency, traffic, errors, saturation — for every user-facing path. Latency as a histogram (not a gauge of averages) so percentiles and SLO ratios can be computed.
- Make integrity failures observable. Anything that can lose or duplicate data must emit a signal when it happens: lock/lease acquisition failures and takeovers of a "stale" lock, optimistic-concurrency conflicts and retries, dropped or dead-lettered messages, write acknowledgements vs. persisted count. Live runs lost acknowledged writes silently when a stale-lock lease was broken while the holder was merely paused; a counter on lease takeovers would have made it visible.
- Design dashboards top-down. Service overview (the four golden signals + SLO status) → per-operation → per-dependency. Each panel answers one question; titles state the unit; SLO target drawn as a reference line.
- Define alerts. Page only on symptoms users feel (SLO burn rate via
slo-architect, or error/latency ratio when no SLO exists). Cause signals (CPU, disk, queue depth) go to dashboards or tickets unless they predict imminent user impact (disk full in < 4h). Every alert has: condition, window, severity (page/ticket), owner, runbook link to a specific section (therunbook-generatorskill). - Cut noise. Require the condition to hold for a window (
for:), deduplicate by service, group related alerts, silence during declared maintenance, delete alerts that paged without action in the last quarter. - Verify (below), then evidence each acceptance criterion with the
record-evidenceskill and stop.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago Changed · +29 lines b379113c9ca7
- 2mo ago First seen · 57 lines · 67 tokens per session scan A 24db902f962a
observability-designer is a skill published in the GitHub repository tmj-90/gaffer (2 stars, last pushed 2d ago), licensed Apache-2.0. It adds 67 tokens to every session and 1,253 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
observability-designer compared with skills from other repositories
| Mod | Type | Stars | Last push | Licence | Scan | Tokens | Works with |
|---|---|---|---|---|---|---|---|
| observability-designertmj-90/gaffer | Skill | 2 | 2d ago | Apache-2.0 | A | 67 | Claude Code, Codex |
| plan-creationQBall-Inc/the-bulwark | Skill | 8 | yesterday | MIT | A | 38 | Claude Code |
| bulwark-brainstormQBall-Inc/the-bulwark | Skill | 8 | yesterday | MIT | A | 50 | Claude Code |
| test-auditQBall-Inc/the-bulwark | Skill | 8 | yesterday | MIT | A | 0 | Claude Code |
| anthropic-validatorQBall-Inc/the-bulwark | Skill | 8 | yesterday | MIT | A | 40 | Claude Code |
| code-reviewQBall-Inc/the-bulwark | Skill | 8 | yesterday | MIT | A | 61 | Claude Code |
| create-subagentQBall-Inc/the-bulwark | Skill | 8 | yesterday | MIT | A | 42 | Claude Code |