CtrlK
BlogDocsLog inGet started
Tessl Logo

golang-observability

Golang everyday observability — the always-on signals in production. Covers structured logging with slog, Prometheus metrics, OpenTelemetry distributed tracing, continuous profiling with pprof/Pyroscope, server-side RUM event tracking, alerting, and Grafana dashboards. Apply when instrumenting Go services for production monitoring, setting up metrics or alerting, adding OpenTelemetry tracing, correlating logs with traces, migrating legacy loggers (zap/logrus/zerolog) to slog, adding observability to new features, or implementing GDPR/CCPA-compliant tracking with Customer Data Platforms (CDP). Not for temporary deep-dive performance investigation (→ See `samber/cc-skills-golang@golang-benchmark` and `samber/cc-skills-golang@golang-performance` skills).

80

1.25x
Quality

92%

Does it follow best practices?

Impact

100%

1.25x

Average score across 1 eval scenario

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

85%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, highly actionable body with executable code, validation checklists, and clean one-level-deep progressive disclosure into verified reference files. Its only weakness is a couple of generic explanatory sentences that assume too little of Claude and could be trimmed for token efficiency.

Suggestions

Drop or sharply trim the opening definition ('Observability is the ability to understand a system's internal state from its external outputs. In Go services, this means five complementary signals...') — Claude already knows what observability is; lead directly with the five-signal taxonomy and the table.

Remove the generic 'When using observability libraries ... refer to the library's official documentation and code examples for current API signatures' sentence, which adds no skill-specific guidance; reserve such pointers for the per-signal reference files where a specific API is actually discussed.

DimensionReasoningScore

Conciseness

The body is largely lean and actionable, but opens with a concept Claude already knows ('Observability is the ability to understand a system's internal state from its external outputs') and includes generic advice ('refer to the library's official documentation and code examples for current API signatures') that adds no skill-specific value, matching the level-2 'mostly efficient but includes some unnecessary explanation' anchor rather than the every-token-earns-its-place level 3.

2 / 3

Actionability

Provides complete, executable Go code (otelslog bridge, exemplar observation with type-assertion fallback, slog multi-handler, and ✗/✓ 'Common Mistakes' blocks) plus a concrete 4-step migration strategy and a 'Definition of Done' checklist — copy-paste ready with no pseudocode, matching the level-3 anchor.

3 / 3

Workflow Clarity

Multi-step processes are sequenced with explicit checkpoints: the numbered migration strategy, the 'Definition of Done' verification checklist, and Audit mode's parallel sub-agent orchestration; the level-2 'checkpoints missing or implicit' does not apply because validation is explicit.

3 / 3

Progressive Disclosure

A concise overview points one level deep to seven real, verified reference files (logging.md, metrics.md, tracing.md, profiling.md, rum.md, alerting.md, dashboards.md), each signaled with a descriptive one-liner under 'Detailed Guides' — matching the level-3 clear-overview-with-well-signaled-references anchor.

3 / 3

Total

11

/

12

Passed

Description

100%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong, third-person description that states concrete capabilities, gives explicit 'Apply when' triggers covering natural user phrasings, and explicitly fences off neighboring skills. It hits the top anchor on all four dimensions with no fluff or over-claims.

DimensionReasoningScore

Specificity

Lists multiple concrete capabilities — 'structured logging with slog, Prometheus metrics, OpenTelemetry distributed tracing, continuous profiling with pprof/Pyroscope, server-side RUM event tracking, alerting, and Grafana dashboards' — matching the level-3 anchor of several specific actions rather than a vague domain.

3 / 3

Completeness

It answers both 'what' (the 'Covers ...' capability list) and 'when' (an explicit 'Apply when ...' trigger clause), satisfying the level-3 anchor that requires explicit triggers; it is not the level-2 case where 'when' is only implied.

3 / 3

Trigger Term Quality

The 'Apply when' clause enumerates natural user phrasings — 'instrumenting Go services for production monitoring, setting up metrics or alerting, adding OpenTelemetry tracing, correlating logs with traces, migrating legacy loggers (zap/logrus/zerolog) to slog' — giving broad coverage of terms users would actually say.

3 / 3

Distinctiveness Conflict Risk

It carves a clear niche (always-on Go production observability) and explicitly disambiguates from adjacent skills via 'Not for temporary deep-dive performance investigation (→ See ... golang-benchmark and ... golang-performance skills)', making wrong-skill activation unlikely.

3 / 3

Total

12

/

12

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_field

'metadata' should map string keys to string values

Warning

Total

15

/

16

Passed

Repository
samber/cc-skills-golang
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.