Use when packaging a Go project with go.mod, when an element needs go_module sources for offline builds, or when setting up GOPATH vendoring in BuildStream
75
68%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./.opencode/skills/packaging-go-projects/SKILL.mdQuality
Discovery
72%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 description has strong trigger terms and distinctiveness for its specific niche (Go + BuildStream integration), but is structured backwards - it only explains when to use the skill without first stating what it actually does. The description would benefit from leading with concrete capabilities before the trigger conditions.
Suggestions
Add a leading statement describing concrete actions (e.g., 'Configures go_module sources in BuildStream elements, sets up vendor directories, and manages Go dependencies for reproducible offline builds.')
Restructure to follow the pattern: '[What it does]. Use when [triggers]' rather than starting with 'Use when'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Go project packaging, BuildStream) and mentions some actions like 'packaging', 'offline builds', and 'GOPATH vendoring', but doesn't list comprehensive concrete actions - it's more about when to use than what specific operations it performs. | 2 / 3 |
Completeness | The description is entirely a 'Use when...' clause explaining when to use it, but lacks a clear 'what does this do' statement. It implies capabilities but doesn't explicitly state what actions the skill performs. | 2 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'Go project', 'go.mod', 'go_module sources', 'offline builds', 'GOPATH vendoring', 'BuildStream' - these are specific technical terms that match how users would describe their needs. | 3 / 3 |
Distinctiveness Conflict Risk | Very specific niche combining Go modules with BuildStream - the combination of 'go.mod', 'go_module sources', and 'BuildStream' creates a distinct trigger profile unlikely to conflict with general Go or general build system skills. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, actionable skill with excellent concrete examples and complete YAML configurations for Go packaging patterns. The main weaknesses are the lack of explicit validation/verification steps in workflows and the monolithic structure that could benefit from progressive disclosure to separate reference files. The decision flowchart is a nice touch for pattern selection.
Suggestions
Add explicit validation steps after build commands (e.g., 'Verify binary exists and runs: `./<binary> --version`') to improve workflow clarity
Split the three detailed patterns into separate reference files (e.g., PATTERN-1-VENDORED.md) and keep SKILL.md as a concise overview with the decision flowchart
Trim the overview section - Claude doesn't need explanation of why sandboxes lack network access or what Go modules are
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is comprehensive but includes some explanatory content that could be trimmed (e.g., the overview section explaining what Go modules are). The tables and pattern explanations are useful but occasionally verbose with details Claude could infer. | 2 / 3 |
Actionability | Excellent actionability with complete, copy-paste ready YAML configurations for all three patterns. Includes specific commands, real file paths, and concrete examples that can be directly used. | 3 / 3 |
Workflow Clarity | The decision flowchart is helpful for pattern selection, but the actual build workflows lack explicit validation checkpoints. There's no 'verify the build succeeded' or 'check for common errors' steps between build and install phases. | 2 / 3 |
Progressive Disclosure | Content is well-structured with clear sections, but it's a monolithic document (~200 lines) that could benefit from splitting detailed patterns into separate files. The 'Real Examples' section appropriately references external files, but the main content is all inline. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
f062bf8
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.