Agent skill

Golang Observability

by context-labs in context-labs/whip

Go observability — always-on production signals: slog logging, Prometheus metrics, OpenTelemetry tracing, pprof profiling, alerting, Grafana.

MITAuto-check passedDevOps & Cloud

Install Golang Observability

skills CLI
$ npx skills add context-labs/whip --skill golang-observability -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install context-labs/whip golang-observability --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/context-labs/whip.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/golang-observability .claude/skills/golang-observability && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
golang-observability
GitHub stars
1.1k
Used in
1 other repo
Token cost
~3.3k tokens
SKILL.md length
1,251 words
Files
9 (incl. references)
Skills in repo
40
Repo updated
First seen
Licence
MIT

At a glance

Go observability — always-on production signals: slog logging, Prometheus metrics, OpenTelemetry tracing, pprof profiling, alerting, Grafana.

  • Works in 12 steps: Use structured logging with log/slog —… → Choose the right log level — Debug for… → Log with context — use… → …
  • Tasks that involve Observability
  • SKILL.md covers Best Practices Summary, Cross-References, The Five Signals and Detailed Guides, plus 4 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Golang Observability is an agent skill from context-labs/whip. Go observability — always-on production signals: slog logging, Prometheus metrics, OpenTelemetry tracing, pprof profiling, alerting, Grafana. Apply when instrumenting Go services or migrating zap/logrus/zerolog to slog. Not for performance deep-dives (→ golang-benchmark, golang-performance).

Its SKILL.md is about 3.3k tokens, which your agent loads only when the skill is triggered. The skill folder holds 10 other files, including reference files (for example `evals/evals.json`, `references/alerting.md` and `references/dashboards.md`). Compatibility notes: Designed for Claude Code, Codex or similar harness, and for projects using Golang.

It sits in DevOps & Cloud, covering Observability and Monitoring and alerting. It works with Go, OpenTelemetry, Prometheus and Grafana. The repository describes itself as: A fast coding-agent harness in Go. Tool-use loop, bubbletea TUI, provider-routable models with live catalog discovery, MCP support, background subagents. One binary, no runtime… The licence is MIT.

When your agent uses it

  • Tasks that involve Observability
  • Tasks that involve Monitoring and alerting

Example prompts

  • “/golang-observability”

Requirements

  • Compatibility (from SKILL.md): Designed for Claude Code, Codex or similar harness, and for projects using Golang.
  • Pre-approved tools (allowed-tools): Read, Edit, Write, Glob, Grep, Bash(go:*), Bash(golangci-lint:*), Bash(git:*), Agent, WebFetch, WebSearch, AskUserQuestion

Workflow steps

12 steps, taken from the first numbered list in SKILL.md.

  1. Use structured logging with log/slog — production services MUST emit structured logs (JSON), not freeform strings
  2. Choose the right log level — Debug for development, Info for normal operations, Warn for degraded states, Error for failures requiring…
  3. Log with context — use slog.InfoContext(ctx, ...) to correlate logs with traces
  4. Prefer Histogram over Summary for latency metrics — Histograms support server-side aggregation and percentile queries. Every HTTP endpoint…
  5. Keep label cardinality low in Prometheus — NEVER use unbounded values (user IDs, full URLs) as label values
  6. Track percentiles (P50, P90, P99, P99.9) using Histograms + histogram_quantile() in PromQL
  7. Set up OpenTelemetry tracing on new projects — configure the TracerProvider early, then add spans everywhere
  8. Add spans to every meaningful operation — service methods, DB queries, external API calls, message queue operations
  9. Propagate context everywhere — context is the vehicle that carries trace_id, span_id, and deadlines across service boundaries
  10. Enable profiling via environment variables — toggle pprof and continuous profiling on/off without redeploying
  11. Correlate signals — inject trace_id into logs, use exemplars to link metrics to traces
  12. A feature is not done until it is observable — declare metrics, add proper logging, create spans

What it can do on your machine

Read from SKILL.md and the folder at commit 8876467. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Edit
    • Write
    • Glob
    • Grep
    • Bash(go:*)
    • Bash(golangci-lint:*)
    • Bash(git:*)
    • Agent
    • WebFetch

    …and 2 more on the same allowed-tools line.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are go).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Links to these hosts (documentation or services it may open):

    • samber.github.io
    • github.com

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

  • Compatibility

    Designed for Claude Code, Codex or similar harness, and for projects using Golang.

    From compatibility in the SKILL.md frontmatter.

Context cost

Golang Observability loads about 3.3k tokens when it runs, and up to ~19k if it reads all its reference files. Until then it costs about 78 tokens; SKILL.md has 1,251 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~78
When it runs · the whole SKILL.md, loaded when a task matches
~3.3k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~19k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from context-labs/whip at commit 8876467, republished under its MIT licence (© context-labs). 1,251 words, ~3,337 tokens.

Download SKILL.mdSave it as .claude/skills/golang-observability/SKILL.md (or your agent's skills folder). This skill also uses 8 other files; get the full folder from GitHub.
name
golang-observability
description
Go observability — always-on production signals: slog logging, Prometheus metrics, OpenTelemetry tracing, pprof profiling, alerting, Grafana. Apply when instrumenting Go services or migrating zap/logrus/zerolog to slog. Not for performance deep-dives (→ golang-benchmark, golang-performance).
allowed-tools
Read, Edit, Write, Glob, Grep, Bash(go:*), Bash(golangci-lint:*), Bash(git:*), Agent, WebFetch, WebSearch, AskUserQuestion
compatibility
Designed for Claude Code, Codex or similar harness, and for projects using Golang.
user-invocable
true
license
MIT
metadata.author
samber
metadata.version
1.3.0
paths
**/*.go

Persona: You are a Go observability engineer. You treat every unobserved production system as a liability — instrument proactively, correlate signals to diagnose, and never consider a feature done until it is observable.

Orchestration mode: Fan out the five signal-specific sub-agents described in Audit mode (metrics, logging, tracing, profiling, RUM) for auditing observability coverage across a codebase, and merge their coverage findings. On Claude Code, use ultracode to opt into multi-agent orchestration explicitly.

Modes:

  • Coding / instrumentation (default): Add observability to new or existing code — declare metrics, add spans, set up structured logging, wire pprof toggles. Follow the sequential instrumentation guide.
  • Review mode — reviewing a PR's instrumentation changes. Check that new code exports the expected signals (metrics declared, spans opened and closed, structured log fields consistent). Sequential.
  • Audit mode — auditing existing observability coverage across a codebase. Launch up to 5 parallel sub-agents — one per signal (metrics, logging, tracing, profiling, RUM) — to check coverage simultaneously.

Community default. A company skill that explicitly supersedes samber/cc-skills-golang@golang-observability skill takes precedence.

Go Observability Best Practices

Observability is the ability to understand a system's internal state from its external outputs. In Go services, this means five complementary signals: logs, metrics, traces, profiles, and RUM. Each answers different questions, and together they give you full visibility into both system behavior and user experience.

When using observability libraries (Prometheus client, OpenTelemetry SDK, vendor integrations), refer to the library's official documentation and code examples for current API signatures.

Best Practices Summary

  1. Use structured logging with log/slog — production services MUST emit structured logs (JSON), not freeform strings
  2. Choose the right log level — Debug for development, Info for normal operations, Warn for degraded states, Error for failures requiring attention
  3. Log with context — use slog.InfoContext(ctx, ...) to correlate logs with traces
  4. Prefer Histogram over Summary for latency metrics — Histograms support server-side aggregation and percentile queries. Every HTTP endpoint MUST have latency and error rate metrics.
  5. Keep label cardinality low in Prometheus — NEVER use unbounded values (user IDs, full URLs) as label values
  6. Track percentiles (P50, P90, P99, P99.9) using Histograms + histogram_quantile() in PromQL
  7. Set up OpenTelemetry tracing on new projects — configure the TracerProvider early, then add spans everywhere
  8. Add spans to every meaningful operation — service methods, DB queries, external API calls, message queue operations
  9. Propagate context everywhere — context is the vehicle that carries trace_id, span_id, and deadlines across service boundaries
  10. Enable profiling via environment variables — toggle pprof and continuous profiling on/off without redeploying
  11. Correlate signals — inject trace_id into logs, use exemplars to link metrics to traces
  12. A feature is not done until it is observable — declare metrics, add proper logging, create spans
  13. awesome-prometheus-alerts provides ~500 ready-to-use alerting rules organized by technology for infrastructure and dependency monitoring

Cross-References

See samber/cc-skills-golang@golang-error-handling skill for the single handling rule. See samber/cc-skills-golang@golang-troubleshooting skill for using observability signals to diagnose production issues. See samber/cc-skills-golang@golang-security skill for protecting pprof endpoints and avoiding PII in logs. See samber/cc-skills-golang@golang-context skill for propagating trace context across service boundaries. See samber/cc-skills@promql-cli skill for querying and exploring PromQL expressions against Prometheus from the CLI.

Go 1.26+: slog multi-handler

For simple fan-out to multiple slog handlers, prefer stdlib slog.NewMultiHandler before adding third-party handler-composition dependencies.

go
logger := slog.New(slog.NewMultiHandler(
    slog.NewJSONHandler(os.Stdout, nil),
    auditHandler,
))

Use third-party slog handler libraries only when the stdlib handler composition is insufficient.

The Five Signals

SignalQuestion it answersToolWhen to use
LogsWhat happened?log/slogDiscrete events, errors, audit trails
MetricsHow much / how fast?Prometheus clientAggregated measurements, alerting, SLOs
TracesWhere did time go?OpenTelemetryRequest flow across services, latency breakdown
ProfilesWhy is it slow / using memory?pprof, PyroscopeCPU hotspots, memory leaks, lock contention
RUMHow do users experience it?PostHog, SegmentProduct analytics, funnels, session replay
Show full SKILL.md (638 more words)Show less

Detailed Guides

Each signal has a dedicated guide with full code examples, configuration patterns, and cost analysis:

  • Structured Logging — Why structured logging matters for log aggregation at scale. Covers log/slog setup, log levels (Debug/Info/Warn/Error) and when to use each, request correlation with trace IDs, context propagation with slog.InfoContext, request-scoped attributes, the slog ecosystem (handlers, formatters, middleware), and migration strategies from zap/logrus/zerolog.

  • Metrics Collection — Prometheus client setup and the four metric types (Counter for rate-of-change, Gauge for snapshots, Histogram for latency aggregation). Deep dive: why Histograms beat Summaries (server-side aggregation, supports histogram_quantile PromQL), naming conventions, the PromQL-as-comments convention (write queries above metric declarations for discoverability), production-grade PromQL examples, multi-window SLO burn rate alerting, and the high-cardinality label problem (why unbounded values like user IDs destroy performance).

  • Distributed Tracing — When and how to use OpenTelemetry SDK to trace request flows across services. Covers spans (creating, attributes, status recording), otelhttp middleware for HTTP instrumentation, error recording with span.RecordError(), trace sampling (why you can't collect everything at scale), propagating trace context across service boundaries, and cost optimization.

  • Profiling — On-demand profiling with pprof (CPU, heap, goroutine, mutex, block profiles) — how to enable it in production, secure it with auth, and toggle via environment variables without redeploying. Continuous profiling with Pyroscope for always-on performance visibility. Cost implications of each profiling type and mitigation strategies.

  • Real User Monitoring — Understanding how users actually experience your service. Covers product analytics (event tracking, funnels), Customer Data Platform integration, and critical compliance: GDPR/CCPA consent checks, data subject rights (user deletion endpoints), and privacy checklist for tracking. Server-side event tracking (PostHog, Segment) and identity key best practices.

  • Alerting — Proactive problem detection. Covers the four golden signals (latency, traffic, errors, saturation), awesome-prometheus-alerts provides ~500 ready-to-use rules by technology, Go runtime alerts (goroutine leaks, GC pressure, OOM risk), severity levels, and common mistakes that break alerting (using irate instead of rate, missing for: duration to avoid flapping).

  • Grafana Dashboards — Prebuilt dashboards for Go runtime monitoring (heap allocation, GC pause frequency, goroutine count, CPU). Explains the standard dashboards to install, how to customize them for your service, and when each dashboard answers a different operational question.

Correlating Signals

Signals are most powerful when connected. A trace_id in your logs lets you jump from a log line to the full request trace. An exemplar on a metric links a latency spike to the exact trace that caused it.

Logs + Traces: otelslog bridge
go
import "go.opentelemetry.io/contrib/bridges/otelslog"

// Create a logger that automatically injects trace_id and span_id
logger := otelslog.NewHandler("my-service")
slog.SetDefault(slog.New(logger))

// Now every slog call with context includes trace correlation
slog.InfoContext(ctx, "order created", "order_id", orderID)
// Output includes: {"trace_id":"abc123", "span_id":"def456", "msg":"order created", ...}
Metrics + Traces: Exemplars
go
// When recording a histogram observation, attach the trace_id as an exemplar
// so you can jump from a P99 spike directly to the offending trace
obs := histogram.WithLabelValues("POST", "/orders")
if eo, ok := obs.(prometheus.ExemplarObserver); ok {
    eo.ObserveWithExemplar(duration, prometheus.Labels{"trace_id": traceID})
} else {
    obs.Observe(duration)
}

Migrating Legacy Loggers

If the project currently uses zap, logrus, or zerolog, migrate to log/slog. It is the standard library logger since Go 1.21, has a stable API, and the ecosystem has consolidated around it. Continuing with third-party loggers means maintaining an extra dependency for no benefit.

Migration strategy:

  1. Add slog as the new logger with slog.SetDefault()
  2. Bridge handlers during migration route slog output through the existing logger: samber/slog-zap, samber/slog-logrus, samber/slog-zerolog
  3. Gradually replace all zap.L().Info(...) / logrus.Info(...) / log.Info().Msg(...) calls with slog.Info(...)
  4. Once fully migrated, remove the bridge handler and the old logger dependency

Definition of Done for Observability

A feature is not production-ready until it is observable. Before marking a feature as done, verify:

  • Metrics declared — counters for operations/errors, histograms for latencies, gauges for saturation. Each metric var has PromQL queries and alert rules as comments above its declaration.
  • Logging is proper — structured key-value pairs with slog, context variants used (slog.InfoContext), no PII in logs, errors MUST be either logged OR returned (NEVER both).
  • Spans created — every service method, DB query, and external API call has a span with relevant attributes, errors recorded with span.RecordError().
  • Dashboards and alerts exist — the PromQL from your metric comments is wired into Grafana dashboards and Prometheus alerting rules. Ready-to-use alert rules for common infrastructure dependencies are available at awesome-prometheus-alerts.
  • RUM events tracked — key business events tracked server-side (PostHog/Segment), identity key is user_id (not email), consent checked before tracking.

Common Mistakes

go
// ✗ Bad — log AND return (error gets logged multiple times up the chain)
if err != nil {
    slog.Error("query failed", "error", err)
    return fmt.Errorf("query: %w", err)
}

// ✓ Good — return with context, log once at the top level
if err != nil {
    return fmt.Errorf("querying users: %w", err)
}
go
// ✗ Bad — high-cardinality label (unbounded user IDs)
httpRequests.WithLabelValues(r.Method, r.URL.Path, userID).Inc()

// ✓ Good — bounded label values only
httpRequests.WithLabelValues(r.Method, routePattern).Inc()
go
// ✗ Bad — not passing context (breaks trace propagation)
result, err := db.Query("SELECT ...")

// ✓ Good — context flows through, trace continues
result, err := db.QueryContext(ctx, "SELECT ...")
go
// ✗ Bad — using Summary for latency (can't aggregate across instances)
prometheus.NewSummary(prometheus.SummaryOpts{
    Name:       "http_request_duration_seconds",
    Objectives: map[float64]float64{0.99: 0.001},
})

// ✓ Good — use Histogram (aggregatable, supports histogram_quantile)
prometheus.NewHistogram(prometheus.HistogramOpts{
    Name:    "http_request_duration_seconds",
    Buckets: prometheus.DefBuckets,
})

© context-labs, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 8 other files (references) in .agents/skills/golang-observability of context-labs/whip.

  • SKILL.md
  • evals/evals.json
  • references/alerting.md
  • references/dashboards.md
  • references/logging.md
  • references/metrics.md
  • references/profiling.md
  • references/rum.md
  • references/tracing.md

Open the folder on GitHubat commit 8876467

Used in 1 other repository

We found 1 copy of this SKILL.md (exact, near-identical or edited) in other folders, from 1 other GitHub owner. This page covers the copy in context-labs/whip, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Golang Observability next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Golang Observability compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Golang Observability this skillcontext-labs/whip1.1k1 repos~3.3kAutomated safety check: PassMIT
Archestra Dev Observabilityarchestra-ai/archestra4.4k—~1.2kAutomated safety check: PassCustom licence
Frontmcp Observabilityagentfront/frontmcp146—~4.6kAutomated safety check: PassApache-2.0
Monitoring Observabilityahmedasmar/devops-claude-skills203—~3.9kAutomated safety check: PassNone
Monitoring ExpertJeffallan/claude-skills12k—~1.6kAutomated safety check: PassMIT
Alloygrafana/skills281—~1.3kAutomated safety check: PassApache-2.0

Similar skills

  • Archestra Dev Observability

    archestra-ai/archestra

    A skill your agent uses when changing Archestra tracing, metrics, OpenTelemetry, Tempo, Grafana, Prometheus, LLM/MCP spans, observability labels, or local observability setup.

    4.4k GitHub stars~1.2k tokensUpdated today
    DevOps & CloudAuto-check passed
  • Frontmcp Observability

    agentfront/frontmcp

    A skill your agent uses when adding tracing, structured logging, metrics, or monitoring to a FrontMCP server.

    146 GitHub stars~4.6k tokensUpdated 3 days ago
    DevOps & CloudAuto-check passed
  • Monitoring Observability

    ahmedasmar/devops-claude-skills

    Monitoring and observability strategy, implementation, and troubleshooting.

    203 GitHub stars~3.9k tokensUpdated 6 mo ago
    DevOps & CloudAuto-check passed
  • Monitoring Expert

    Jeffallan/claude-skills

    Sets up application monitoring: structured logs, Prometheus metrics, OpenTelemetry tracing, Grafana dashboards, alert rules and load tests with k6 or Artillery.

    12k GitHub stars~1.6k tokensUpdated 6 days ago
    DevOps & CloudAuto-check passed
  • Alloy

    grafana/skills

    Official

    Build a unified telemetry pipeline with Grafana Alloy — one OpenTelemetry-compatible binary that collects metrics, logs, traces, and profiles and ships to Grafana Cloud / Prometheus / Loki / Tempo /…

    281 GitHub stars~1.3k tokensUpdated yesterday
    DevOps & CloudAuto-check passed
  • Observability Monitoring

    AnastasiyaW/codex-claude-code-config

    Design, audit, and troubleshoot production monitoring and observability using user-impact checks, layered telemetry, USE/RED, SLI/SLO/SLA, error budgets, cardinality controls, actionable alerting…

    154 GitHub stars~4.1k tokensUpdated yesterday
    DevOps & CloudAuto-check passed

More from context-labs/whip

All 40 skills in this repo
  • Golang Lint

    context-labs/whip

    Linting best practices and golangci-lint configuration for Go — running linters, configuring .golangci.yml, nolint suppressions, selecting linters.

    1.1k GitHub starsUsed in 2 repos~1.8k tokens
    Auto-check passed
  • Golang Project Layout

    context-labs/whip

    Golang project layouts and workspaces. An agent skill from context-labs/whip.

    1.1k GitHub starsUsed in 1 repo~1.8k tokens
    Auto-check passed
  • Golang Pkg Go Dev

    context-labs/whip

    Golang package/module docs via godig, a pkg.go.dev API client (CLI + MCP) — APIs, symbols, versions, importers, licenses, vulnerabilities.

    1.1k GitHub starsUsed in 2 repos~3k tokens
    Auto-check passed
  • Golang Stretchr Testify

    context-labs/whip

    Golang testing with stretchr/testify — assert, require, mock, suite: assertions, mock expectations, argument matchers, suite lifecycle, Eventually, JSONEq.

    1.1k GitHub starsUsed in 2 repos~1.8k tokens
    Auto-check passed
  • CI/CD with GitHub Actions for Golang — testing, linting, SAST, security scanning, coverage, Dependabot, Renovate, GoReleaser, release pipelines.

    1.1k GitHub stars~3.5k tokensUpdated 4 days ago
    Auto-check passed
  • Golang Data Structures

    context-labs/whip

    Golang data structures — slices/maps internals (capacity growth, preallocation, hash buckets), slices/maps packages, container/list/heap/ring, strings.Builder vs bytes.Buffer, generic collections…

    1.1k GitHub starsUsed in 1 repo~2.6k tokens
    Auto-check passed

Categories

Questions about Golang Observability

What does Golang Observability do?

Go observability — always-on production signals: slog logging, Prometheus metrics, OpenTelemetry tracing, pprof profiling, alerting, Grafana. Golang Observability is an agent skill from context-labs/whip. Go observability — always-on production signals: slog logging, Prometheus metrics, OpenTelemetry tracing, pprof profiling, alerting, Grafana.

When should I use Golang Observability?

Golang Observability fits situations like: tasks that involve Observability; tasks that involve Monitoring and alerting.

How do I install Golang Observability in Claude Code?

Run `npx skills add context-labs/whip --skill golang-observability -a claude-code`. Or copy the skill folder (.agents/skills/golang-observability in context-labs/whip) into .claude/skills/golang-observability in your project. Claude Code loads it when a task matches its description.

How do I install Golang Observability in Codex?

Run `npx skills add context-labs/whip --skill golang-observability -a codex`. Or copy the skill folder (.agents/skills/golang-observability in context-labs/whip) into .agents/skills/golang-observability in your project. Codex loads it when a task matches its description.

Can I use Golang Observability in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add context-labs/whip --skill golang-observability -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/golang-observability, .gemini/skills/golang-observability, .github/skills/golang-observability and .opencode/skills/golang-observability in your project.

What does Golang Observability need to run?

SKILL.md names no scripts, command-line tools or credentials: Golang Observability is instructions for the agent only. Its frontmatter pre-approves these tools: Read, Edit, Write, Glob, Grep, Bash(go:*), Bash(golangci-lint:*), Bash(git:*), Agent, WebFetch, WebSearch, AskUserQuestion. Compatibility (from SKILL.md): Designed for Claude Code, Codex or similar harness, and for projects using Golang..

Does Golang Observability access the network?

SKILL.md names 2 domains. As links in the text: samber.github.io and github.com. This is read from the text; nothing was executed.

Is Golang Observability safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Golang Observability use?

Golang Observability is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Golang Observability use?

About 3.3k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 16k tokens, read only when the agent opens those files.

What are the alternatives to Golang Observability?

Skills that share tags, products or a category with Golang Observability: Archestra Dev Observability (archestra-ai/archestra, 4.4k stars), Frontmcp Observability (agentfront/frontmcp, 146 stars), Monitoring Observability (ahmedasmar/devops-claude-skills, 203 stars) and Monitoring Expert (Jeffallan/claude-skills, 12k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Golang Observability?

context-labs (a GitHub organization) maintains it in context-labs/whip, which has 1,083 GitHub stars. The repository holds 40 skills in this directory. The repository was last updated on October 5, 2026.

Source: context-labs/whip on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.