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 gul-labs/craftsman-marketplace --skill craft-observabilitygit clone --depth 1 https://github.com/gul-labs/craftsman-marketplaceWrote 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/gul-labs/craftsman-marketplace/craft-observability)<a href="https://agentmods.dev/skills/gul-labs/craftsman-marketplace/craft-observability"><img src="https://agentmods.dev/badge/skills/gul-labs/craftsman-marketplace/craft-observability/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/gul-labs/craftsman-marketplace/craft-observability"><img src="https://agentmods.dev/badge/skills/gul-labs/craftsman-marketplace/craft-observability.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.00148 | $0.03163 |
| Opus 5 | $0.00074 | $0.01581 |
| Sonnet 5 | $0.00030 | $0.00633 |
| Haiku 4.5 | $0.00015 | $0.00316 |
Grade A, and why
craft-observability 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 12d 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 — 189 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Observability Craft
This skill encodes one engineer's standard for making a service observable, applied the same way across every repo. The method and opinions live here; the project specifics (which logger, which DSN, which dashboard) live in the target repo's code and config — always discover them, never assume or hardcode.
Operating principle — discover before you build
Different repos already have different pieces. Before adding anything, spend two minutes mapping what exists so you extend rather than duplicate:
package.json/ lockfile → is@sentry/*,pino/winston,prom-client,@opentelemetry/*already present?grepfor an existing logger,Sentry.init,/health,/metrics, or an env schema (env.ts,config.ts) — wire into these, don't fork them.- Deployment target (serverless vs long-lived) decides the metrics approach — see
references/serverless-vs-server.mdbefore reaching forprom-client.
State what you found, then propose the smallest set of additions that closes the gaps.
The four pillars (do them in this order)
- Errors — Sentry first. It's the highest signal-per-minute. See
references/sentry.md. - Structured logs — JSON logs with a request/trace id, never
console.login production code. Seereferences/logging.md. - Metrics & dashboards — Grafana over a metrics source appropriate to the runtime. See
references/grafana.md. - SLOs & alerts — alerts ride on user-facing symptoms, not raw resource graphs. See
references/slo-alerts.md.
A service is "observable enough to ship" when an on-call engineer can answer is it broken?, since when?, and where? from these four without SSH-ing into anything.
Then the fifth thing, which the four pillars don't give you. The pillars make the service
observable; they say nothing about whether the transaction the product exists to perform actually
completed, or whether a human is on the other end of an alert. Before calling a service production-
ready, close that gap: the core business transaction visible end to end, stuck and half-finished
work detectable, a named person receiving alerts, and the whole loop proven once by breaking it on
purpose. See references/operational-readiness.md.
What ships with it
8 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 12d ago First seen · 189 lines · 148 tokens per session scan A d88030fb0c25
craft-observability is a skill published in the GitHub repository gul-labs/craftsman-marketplace (1 stars, last pushed today), licensed MIT. It adds 148 tokens to every session and 3,163 once invoked, about $0.0007 per session on Opus 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.
Other skills, from other repositories
plumb-line-audit
Use when auditing a diff or repository against the plumb-line principles — finds laundered uncertainty, boundary leaks, hardcoded priors, overstated maturity, outputs lacking recorded lineage, and baseline drift with no explanation. Read-only: it reports, never auto-fixes.
plumb-line-bootstrap
Use when setting up a project with the plumb-line discipline — interviews the builder to find their source-truth layer and layering, generates a domain-neutral ruleset, and installs parameterized enforcement (boundary check, test gate, pre-commit gate, branch guard) for the project's language. Ships no default layers…
plumb-line-remediate
Use when applying findings from a plumb-line audit report — the builder has a report (or pasted findings) and wants the fixes made. Opt-in and separate from the audit, which is read-only and never fixes.
plumb-line-adopt
Use when a builder wonders what plumb-line would do for their codebase or which part to adopt — or when, mid-task, their work shows a fit signal (adding a mock or fallback near a production path, mixing fixture, cached, or LLM/agent-produced data with real data) and visible uncertainty would help. Inspects the repo…
plumb-line-method
Use when a builder wants to learn or be reminded of the plumb-line method — the discipline of epistemic honesty enforced by tooling. Teaches the thesis, the nine portable principles, the maturity vocabulary, and the one-line test. Pure knowledge; takes no actions.
loud-errors
Use when you spot a swallowed, vague, or context-losing error — an empty catch, a bare except: pass, catch (e) { console.log(e) } that then continues, throw new Error("something went wrong"), an error logged then ignored, or a caught exception that drops its cause. Makes failures loud and specific: each error says…