CtrlK
BlogDocsLog inGet started
Tessl Logo

ax-go-agent-observability

Use when writing Go code with `github.com/ax-llm/ax/packages/go` for agent tracing, centralized and multi-tenant usage accounting, action logs, runtime diagnostics, replay, and production debugging.

62

Quality

78%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./packages/go/skills/ax-go-agent-observability/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

61%Weight 40%Scale 1-5

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

The body is well-structured and token-efficient with clear pointers to package docs and runnable examples, but it is more of an API reference than an instructional guide: most advertised capabilities lack inline executable code, and the main observability workflow is implicit rather than sequenced with validation steps.

Suggestions

Add complete, copy-paste-ready snippets (imports, defined `llm`/client values) for the core capabilities — especially tracing and action logs, which currently appear only as API identifier names.

Provide an explicit ordered workflow for the common path: register the usage observer → attach usageContext for attribution → run with a no-key example → verify events emitted → clear the observer at teardown.

Move the long "Relevant API Surface" identifier list into a separate reference file and keep only the handful of symbols used in the inline snippets.

DimensionReasoningScore

Conciseness

Mostly lean, package-specific facts with no explanation of concepts Claude already knows, but the inline "Relevant API Surface" identifier dump and "Package Facts" trivia ("Real network support: yes") could be trimmed since API.md and axir-api.json are already referenced.

4 / 5

Actionability

Two real Go snippets (Core Pattern, SetUsageObserver) provide some concrete guidance, but they reference undefined variables (`llm`, `usageQueue`) with no imports, and four of the six advertised capabilities (tracing, action logs, diagnostics, replay) get only API identifier names, not executable code.

3 / 5

Workflow Clarity

The sequence for the core task (register observer, attach usageContext, run, clear during teardown) is present but implicit and scattered across bullets, with no explicit checkpoints or feedback loops for verifying that usage events flow correctly.

3 / 5

Progressive Disclosure

Clear section headers and well-signaled pointers to API.md, axir-api.json, axir-capabilities.json, and examples/, with content appropriately split; the main gap is the long inline API identifier list that belongs in a separate reference file.

4 / 5

Total

14

/

20

Passed

Description

87%Weight 40%Scale 1-5

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 description: explicitly states trigger conditions tied to a specific Go package and enumerates concrete capability areas. Main weaknesses are the noun-phrase form of capabilities and missing common synonyms like observability/monitoring/telemetry.

Suggestions

Add natural synonyms such as "observability", "monitoring", "telemetry", or "metrics" to broaden trigger-term coverage.

Express capabilities as concrete actions (e.g., "Trace agent runs, account for multi-tenant usage, log actions") rather than noun phrases to sharpen specificity.

DimensionReasoningScore

Specificity

Lists six concrete capability areas ("agent tracing, centralized and multi-tenant usage accounting, action logs, runtime diagnostics, replay, and production debugging"), but presents them as noun phrases rather than explicit action verbs, leaving minor gaps versus the fully action-oriented anchor 5.

4 / 5

Completeness

Explicitly answers both what (the enumerated tracing/accounting/logs/diagnostics/replay/debugging capabilities) and when ("Use when writing Go code with `github.com/ax-llm/ax/packages/go`"), with concrete trigger phrases; the "Use when" clause is present and specific.

5 / 5

Trigger Term Quality

Good natural keyword coverage ("Go", "tracing", "usage accounting", "debugging") plus the package import path `github.com/ax-llm/ax/packages/go` as a strong trigger, but common synonyms such as "observability", "monitoring", "telemetry", or "metrics" are missing.

4 / 5

Distinctiveness Conflict Risk

Pinned to a single specific package import path with a clear observability niche; distinct triggers make it unlikely to fire for unrelated skills.

5 / 5

Total

18

/

20

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.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository
ax-llm/ax
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.