CtrlK
BlogDocsLog inGet started
Tessl Logo

packaging-go-projects

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

Quality

68%

Does it follow best practices?

Impact

Pending

No eval scenarios have been run

SecuritybySnyk

Advisory

Suggest reviewing before use

Optimize this skill with Tessl

npx tessl skill review --optimize ./.opencode/skills/packaging-go-projects/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

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'

DimensionReasoningScore

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

DimensionReasoningScore

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.

Validation11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository
projectbluefin/dakota
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.