Modernize Golang code to use recent language features, standard library improvements, and idiomatic patterns. Trigger proactively when writing or reviewing Go code and old-style patterns are detected, or when encountering a deprecation warning. Also use when the user explicitly asks for modernization, a Go version upgrade, or a CI/tooling refresh.
63
76%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/golang-modernize/SKILL.mdQuality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a well-crafted description that clearly communicates both what the skill does and when it should be triggered. It has strong trigger term coverage and is distinctly scoped to Go modernization. The main weakness is that the capabilities could be more specific—listing concrete modernization actions (e.g., replacing deprecated APIs, adopting generics, updating error handling patterns) would strengthen it further.
Suggestions
Add specific concrete actions like 'replace deprecated ioutil calls, adopt generics where applicable, update error wrapping to use fmt.Errorf with %w, migrate to slog for structured logging' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Golang code) and some actions ('modernize', 'use recent language features, standard library improvements, and idiomatic patterns'), but doesn't list multiple specific concrete actions like 'replace ioutil with os functions, use generics, update error wrapping patterns'. | 2 / 3 |
Completeness | Clearly answers both 'what' (modernize Golang code to use recent language features, standard library improvements, idiomatic patterns) and 'when' (proactively when old-style patterns detected, deprecation warnings, or when user asks for modernization/version upgrade/CI refresh). Explicit trigger guidance is provided. | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms: 'Go code', 'Golang', 'modernization', 'Go version upgrade', 'deprecation warning', 'old-style patterns', 'CI/tooling refresh'. These cover a good range of terms users would naturally say. | 3 / 3 |
Distinctiveness Conflict Risk | Clearly scoped to Go/Golang modernization specifically, with distinct triggers like 'deprecation warning', 'Go version upgrade', and 'old-style patterns'. Unlikely to conflict with general code review or other language-specific skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
62%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured modernization guide with a clear workflow, good prioritization framework, and useful reference tables. Its main weaknesses are the lack of concrete code examples in the main file (all deferred to missing reference files) and some verbosity in the introductory sections. The workflow design with consent checks, .modernize persistence, and sub-agent parallelization is thoughtful and practical.
Suggestions
Add at least 2-3 inline before/after code examples for the highest-priority modernizations (e.g., loop variable fix, math/rand/v2 migration) directly in SKILL.md so the skill is actionable even without the reference files.
Trim the scope paragraph and persona/modes preamble — Claude doesn't need the rationale for why pre-1.21 changes are excluded; just state the version range covered.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some unnecessary verbosity — the scope paragraph explaining what's included/excluded and why is somewhat redundant, and the persona/modes section at the top could be tighter. The deprecated packages table and priority guide are dense and useful, but the overall document is long (~200 lines) with some sections that could be trimmed. | 2 / 3 |
Actionability | The workflow steps are concrete (check go.mod, run golangci-lint, etc.) and the deprecated packages table is highly actionable. However, the actual before/after code examples are deferred to references/versions.md which is not provided in the bundle, and the skill itself contains zero executable code examples. The migration priority guide lists what to do but not how with concrete code. | 2 / 3 |
Workflow Clarity | The workflow is clearly sequenced with 9 numbered steps, includes validation checkpoints (step 8: run tests before dependency updates), has a consent check mechanism, and includes a feedback loop for ignored suggestions (.modernize file). The dual-mode operation (inline vs full-scan) is well-defined with clear behavioral boundaries. | 3 / 3 |
Progressive Disclosure | The skill references two external files (references/versions.md and references/tooling.md) with clear one-level-deep navigation, which is good structure. However, no bundle files were provided, so we cannot verify these references exist. The main SKILL.md itself is quite long with inline tables and priority lists that could arguably be split out, and the critical before/after examples are entirely absent from the main file. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_field | 'metadata' should map string keys to string values | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
8c7e016
Table of Contents
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.