Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/car12o/claude-workflowsnpx agentmods add skills/car12o/claude-workflows/go-project-layoutWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/car12o/claude-workflows/go-project-layout)<a href="https://agentmods.dev/skills/car12o/claude-workflows/go-project-layout"><img src="https://agentmods.dev/badge/skills/car12o/claude-workflows/go-project-layout.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00038 | $0.01036 |
| Opus 5 | $0.00019 | $0.00518 |
| Sonnet 5 | $0.00008 | $0.00207 |
| Haiku 4.5 | $0.00004 | $0.00104 |
Grade C, and why
go-project-layout scanned grade C with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
rm -rf bin/ coverage.out How it starts
The opening of the file, as written. The whole thing — 147 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Go Project Layout
Directory Structures
Minimal (library / small tool):
go.mod, main.go, main_test.go, README.md
Standard (single service):
cmd/server/main.go
internal/{domain,service,repository,handler}/
go.mod, Makefile, .golangci.yml
Service (multi-binary):
cmd/{api,worker}/main.go
internal/{domain,service,repository,handler,config}/
pkg/ # public libraries (sparingly)
migrations/
go.mod, Makefile, .golangci.yml, Dockerfile
Package Design
- Single responsibility: one package = one clear purpose
- Minimal exports: only export what consumers need
- No circular imports: dependencies flow one direction
internal/by default;pkg/only for genuinely reusable libraries- Flat over nested: avoid deep hierarchies
go.mod (Go 1.24)
module github.com/org/project
go 1.24
tool (
golang.org/x/tools/cmd/goimports
github.com/golangci/golangci-lint/cmd/golangci-lint
golang.org/x/vuln/cmd/govulncheck
)
Makefile
.PHONY: build test lint fmt vet tidy coverage run clean check
build:
go build -trimpath -o bin/ ./cmd/...
test:
go test -race ./...
coverage:
go test -race -coverprofile=coverage.out ./...
go tool cover -func=coverage.out
fmt:
gofmt -s -w . && goimports -w .
vet:
go vet ./...
lint:
golangci-lint run
tidy:
go mod tidy && go mod verify
clean:
rm -rf bin/ coverage.out
check: fmt vet lint test build
.golangci.yml
run:
timeout: 5m
go: "1.24"
linters:
enable:
# Defaults (explicit for clarity)
- errcheck
- govet
- staticcheck
- unused
- gosimple
- ineffassign
# Error handling
- errorlint # error wrapping correctness
- errname # error variable naming (ErrFoo)
# Security
- gosec # security issues
- bodyclose # unclosed HTTP response bodies
- noctx # HTTP requests without context
# Code quality
- gocritic # diagnostic + style + performance
- revive # extensible linter
- unconvert # unnecessary type conversions
- wastedassign # dead assignments
- forcetypeassert # unchecked type assertions
- exhaustive # enum switch exhaustiveness
- nilnil # confusing (nil, nil) returns
- usestdlibvars # use stdlib constants (http.StatusOK vs 200)
- misspell # spelling in comments/strings
- prealloc # slice pre-allocation opportunities
# Conditional (common in Go 1.24+ projects)
- sloglint # log/slog best practices
- testifylint # testify best practices
issues:
exclude-dirs: [vendor]
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 7d ago First seen · 147 lines · 38 tokens per session scan C c996df8b66ba
go-project-layout is a skill published in the GitHub repository car12o/claude-workflows (2 stars, last pushed 6mo ago), licensed MIT. It adds 38 tokens to every session and 1,036 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it C with 1 finding (recursive force delete). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
golang-continuous-integration
GitHub Actions CI/CD pipeline configuration for Golang projects — workflow files for test, lint, SAST, coverage and vulnerability-scan jobs, Dependabot and Renovate config files, GoReleaser release pipelines, Docker build/push, repository security settings, and AI-driven PR review. Use when setting up or improving Go…
go-ci
Continuous integration for Go projects: GitHub Actions pipelines, caching, golangci-lint setup, test/coverage gates, vulnerability scanning, build matrices, and Makefile targets. Use when: "set up CI", "GitHub Actions for Go", "add lint to the pipeline", "CI is slow", "coverage gate", "build matrix", "write a…
go-ci-workflow
Use when creating or refactoring GitHub Actions CI workflows for Go repositories. Covers repository-shape detection, Make-driven delegation with formal fallbacks, Go setup, caching, tool pinning, permissions, reusable workflows, and quality gate design.
scaffold-go
Scaffold a complete Go project with CI/CD, release pipeline, Makefile, sr.yaml, .envrc, and standard files. Uses go toolchain and make as the native build system. Loads on top of scaffold-project (run that first for cross-language standard files). Use when creating a new Go CLI, service, or module, or when the user…
go-ci-setup
Set up a Go CI/CD pipeline with formatting, vetting, static analysis, tests, vulnerability scanning, and container build. Use when: creating CI for Go, adding checks to workflow. Do not use: for local development setup, non-CI automation.
setup-go-project
Scaffold a new Go project with a Makefile, golangci-lint, GitHub Actions CI, and two-layer git hooks (pre-commit + pre-push). Use when the user says "set up a new Go project", "scaffold a Go project", "create a new Go CLI", or similar.