Provides a guide for setting up Golang project layouts and workspaces. Use this whenever starting a new Go project, organizing an existing codebase, setting up a monorepo with multiple packages, creating CLI tools with multiple main packages, or deciding on directory structure. Apply this for any Go project initialization or restructuring work.
82
80%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/golang-project-layout/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 solid skill description with strong trigger terms and completeness. Its main weakness is that the core capability is described somewhat vaguely as 'Provides a guide' rather than listing specific concrete actions the skill enables. The explicit 'Use this whenever...' clause with multiple scenarios is a notable strength.
Suggestions
Replace 'Provides a guide for setting up' with more specific concrete actions, e.g., 'Creates Go module structures, configures go.work workspaces, organizes package hierarchies, and sets up cmd/ directories for multiple binaries.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (Golang project layouts/workspaces) and mentions several scenarios (monorepo, CLI tools, directory structure), but the core action is vague — 'Provides a guide' rather than listing concrete actions like 'creates go.mod files, sets up package directories, configures workspace files'. | 2 / 3 |
Completeness | Clearly answers both 'what' (guide for setting up Golang project layouts and workspaces) and 'when' with explicit triggers ('Use this whenever starting a new Go project, organizing an existing codebase, setting up a monorepo...'). The 'Use this whenever' clause provides clear activation guidance. | 3 / 3 |
Trigger Term Quality | Good coverage of natural terms users would say: 'Go project', 'Golang', 'monorepo', 'multiple packages', 'CLI tools', 'directory structure', 'project initialization', 'restructuring'. These are terms a developer would naturally use when seeking help with Go project organization. | 3 / 3 |
Distinctiveness Conflict Risk | Clearly scoped to Go/Golang project layout and workspace setup, which is a distinct niche. The specific mention of Go monorepos, multiple main packages, and Go directory structure makes it unlikely to conflict with general project setup or other language-specific skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
70%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-organized Go project layout skill with strong progressive disclosure and workflow clarity. Its main weakness is moderate actionability — it tells Claude what to do but relies heavily on external references for the concrete details, and the inline content is more advisory than executable. The conciseness could be improved by trimming explanations of well-known concepts like 12-Factor App principles.
Suggestions
Add a concrete, copy-paste-ready project scaffolding example (e.g., a sequence of mkdir and file creation commands for a typical CLI or service project) to improve actionability.
Trim the 12-Factor App section to just a link or single line — Claude knows these principles, and listing them adds tokens without new information.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Generally efficient but includes some unnecessary framing (e.g., the persona line, explaining what 12-Factor App is). The table and checklist are well-structured, but some sections like module naming examples explain things Claude already knows about Go conventions. | 2 / 3 |
Actionability | Provides a useful initialization checklist with concrete commands (go mod init, gofmt), but most guidance is directional rather than executable. Code examples are limited to module naming good/bad patterns. The actual project setup lacks copy-paste-ready scaffolding commands or scripts. | 2 / 3 |
Workflow Clarity | The initialization checklist provides a clear, sequenced workflow with decision points (ask developer about architecture, ask about DI) before technical steps. The sequence is logical: decide architecture → decide DI → choose project type → right-size → initialize. For a project setup skill, this is well-structured with appropriate checkpoints. | 3 / 3 |
Progressive Disclosure | Excellent progressive disclosure with a concise overview that points to well-signaled one-level-deep references: directory-layouts.md, config.md, testing-layout.md, workspaces.md, plus cross-references to related skills. References are clearly labeled with context about what each contains. | 3 / 3 |
Total | 10 / 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 | |
b88f91d
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.