Name: ax-go-typesafe
Rating: 56.00000000000001 (1 reviews)
Author: ax-llm

ax-go-typesafe

Use when writing Go code with `github.com/ax-llm/ax/packages/go` for Typesafe Jev boolean/class signatures, value descriptions, configurable Noul conversion, native Noul/Choice/Score, structured criteria and hybrid generation.

Quality

70%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./packages/go/skills/ax-go-typesafe/SKILL.md

Quality

Content

57%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.

A factually dense, well-sectioned reference-style skill whose Core Pattern and guardrails give real traction, but it buries that value in jargon-heavy prose and an inline symbol dump. The biggest gains are structural: offload the API surface list to a reference file and add one executable example each for native scoring and hybrid generation.

Suggestions

Move the ~30-symbol "Relevant API Surface" list into a references file (e.g. references/api-surface.md) and keep only the handful of symbols needed for the Core Pattern inline.

Add a short executable Go example for native Score/criteria and one for the two-program hybrid pattern, mirroring the Core Pattern's concreteness instead of describing them in prose.

Collapse the multi-language name enumerations ("system_one / systemOne / SystemOne") to the Go spelling only, or state once that other languages use camelCase variants.

Add an explicit validation step in the workflow, e.g. "run the no-key example first to confirm the signature and request mapping before using real credentials".

Dimension	Reasoning	Score
Conciseness	The body is dense with package-specific facts Claude cannot know (thresholds, tolerances, rejection rules), which earns its tokens, but it is padded by triple-name enumerations ("system_one / systemOne / SystemOne", "describe_values / describeValues / DescribeValues") and a ~30-symbol inline API list. Mostly efficient with some tightening possible — anchor 3, not 4, because several sentences could be trimmed without losing information.	3 / 5
Actionability	The Core Pattern is concrete, executable Go covering the main boolean/class case, and the Guardrails are directive ("Start from package examples for exact native syntax before inventing a new call shape"). Falls short of anchor 5 because native Score/criteria and hybrid-generation usage is described in prose but never shown as runnable code, leaving gaps for the second-most-important use case.	4 / 5
Workflow Clarity	There is an implicit sequence (When To Use → Package Facts → Core Pattern → constraint details → Guardrails) and a pointer to runnable examples, but no explicit ordered workflow or validation checkpoints (e.g. verify a signature compiles or run the no-key example before touching a real provider). Anchor 3 (sequence present, checkpoints implicit) rather than 2 because the guidance is well-sectioned and unambiguous about which tool to pick.	3 / 5
Progressive Disclosure	Sections are clearly organized and external material is named at one level (package examples under src/examples/go/generation/, the docs URL), but no bundle files exist and the long "Relevant API Surface" symbol enumeration is inline content that clearly belongs in a separate references file. Anchor 3 (content that should be separate is inline) rather than 4.	3 / 5
	Total	13 / 20 Passed

Description

71%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 highly niche, distinguishable description with an explicit use-when clause and a specific feature list. Its main weakness is trigger-term coverage that leans on package-internal jargon rather than natural user phrasing, plus a keyword-style what-list instead of plain capability statements.

Suggestions

Add natural trigger synonyms users would actually say, e.g. "Ax", "ax-llm", "Go SDK", or "typed LLM outputs in Go", alongside the import path.

Rewrite the feature keyword list as plain capability statements (e.g. "Build typed boolean/class Ax signatures, configure Noul conversion thresholds, and use native scoring") so the 'what' reads as actions rather than a keyword dump.

Broaden the when-clause slightly to cover related moments (e.g. "when generating or debugging Go code for the ax-llm Ax package").

Dimension	Reasoning	Score
Specificity	The description lists several concrete capability areas — "Typesafe Jev boolean/class signatures", "value descriptions", "configurable Noul conversion", "native Noul/Choice/Score", "structured criteria and hybrid generation" — tied to a named package. It falls between anchor 3 (1-2 concrete actions) and anchor 5 (comprehensive action list) because the items are feature keywords rather than plain-action verbs, leaving minor gaps in coverage.	4 / 5
Completeness	Both parts are present: the "what" is the feature list and the "when" is the explicit "Use when writing Go code with ..." clause. Not a 5 because the what-portion is a keyword enumeration rather than clearly stated capabilities, and the when-clause is a single narrow condition; comfortably above anchor 3's missing/weak when.	4 / 5
Trigger Term Quality	"writing Go code" and the literal import path `github.com/ax-llm/ax/packages/go` are real triggers, but the rest relies on package-internal jargon ("Jev", "Noul") and misses natural synonyms a user would actually say ("Ax", "ax-llm", "Go SDK", "typed LLM outputs"). Matches anchor 3 (some relevant keywords, missing common variations) rather than 4, which requires broader natural-term coverage.	3 / 5
Distinctiveness Conflict Risk	The exact package path plus unique terms ("Typesafe Jev", "Noul") carve out a clear niche with distinct triggers; no realistic overlap with unrelated skills. Fits anchor 5.	5 / 5
	Total	16 / 20 Passed

Validation

93%

Warnings & errors only

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

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: ax-llm/ax
Path: packages/go/skills/ax-go-typesafe/SKILL.md
Commit: 3f630a0

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

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.