go-skills
Enforces coding standards and project structure for LlamaFarm CLI development, focusing on maintainability and Go idioms.
Install
mkdir -p .claude/skills/go-skills && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/5526" && unzip -o skill.zip -d .claude/skills/go-skills && rm skill.zipInstalls to .claude/skills/go-skills
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Shared Go best practices for LlamaFarm CLI. Covers idiomatic patterns, error handling, and testing.Key capabilities
- →Wrap errors with context using fmt.Errorf
- →Protect shared state with sync.Mutex or sync.RWMutex
- →Communicate between goroutines using channels
- →Validate all external input for security
How it works
This skill provides guidelines and patterns for Go development, covering error handling, concurrency, testing, and security, to maintain consistency within the LlamaFarm CLI.
Inputs & outputs
When to use go-skills
- →Writing idiomatic CLI command implementations
- →Handling errors consistently across the project
- →Managing concurrent tasks in the TUI
About this skill
Go Skills for LlamaFarm CLI
Shared Go best practices for LlamaFarm CLI development. These guidelines ensure idiomatic, maintainable, and secure Go code.
Tech Stack
- Go 1.24+
- Cobra (CLI framework)
- Bubbletea (TUI framework)
- Lipgloss (terminal styling)
Directory Structure
cli/
cmd/ # Command implementations
config/ # Configuration types and loading
orchestrator/ # Service management
utils/ # Shared utilities
version/ # Version and upgrade handling
internal/ # Internal packages
tui/ # TUI components
buildinfo/ # Build information
Quick Reference
Error Handling
- Always wrap errors with context:
fmt.Errorf("operation failed: %w", err) - Use sentinel errors for expected conditions:
var ErrNotFound = errors.New("not found") - Check errors immediately after function calls
Concurrency
- Use
sync.Mutexfor shared state protection - Use
sync.RWMutexwhen reads dominate writes - Use channels for goroutine communication
- Always use
deferfor mutex unlocks
Testing
- Use table-driven tests for comprehensive coverage
- Use interfaces for mockability
- Test file names:
*_test.goin same package
Security
- Never log credentials or tokens
- Redact sensitive headers in debug logs
- Validate all external input
- Use
context.Contextfor cancellation
Checklist Files
| File | Description |
|---|---|
| patterns.md | Idiomatic Go patterns |
| concurrency.md | Goroutines, channels, sync |
| error-handling.md | Error wrapping, sentinels |
| testing.md | Table-driven tests, mocks |
| security.md | Input validation, secure coding |
Go Proverbs to Remember
- "Don't communicate by sharing memory; share memory by communicating"
- "Errors are values"
- "A little copying is better than a little dependency"
- "Clear is better than clever"
- "Design the architecture, name the components, document the details"
Common Patterns in This Codebase
HTTP Client Interface
type HTTPClient interface {
Do(req *http.Request) (*http.Response, error)
}
Process Management with Mutex
type ProcessManager struct {
mu sync.RWMutex
processes map[string]*ProcessInfo
}
Cobra Command Pattern
var myCmd = &cobra.Command{
Use: "mycommand",
Short: "Brief description",
RunE: func(cmd *cobra.Command, args []string) error {
// Implementation
return nil
},
}
Bubbletea Model Pattern
type myModel struct {
// State fields
}
func (m myModel) Init() tea.Cmd { return nil }
func (m myModel) Update(msg tea.Msg) (tea.Model, tea.Cmd) { /* ... */ }
func (m myModel) View() string { return "" }
Prerequisites
How it compares
This skill offers specific Go best practices tailored for the LlamaFarm CLI, unlike general Go programming guides.
Compared to similar skills
go-skills side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| go-skills (this skill) | 1 | 6mo | No flags | Intermediate |
| effective-go | 323 | 9mo | No flags | Beginner |
| go-dev-guidelines | 14 | 9mo | No flags | Intermediate |
| opentelemetry-instrumentation-extension | 3 | 6mo | Review | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by llama-farm
View all by llama-farm →You might also like
effective-go
openshift
Apply Go best practices, idioms, and conventions from golang.org/doc/effective_go. Use when writing, reviewing, or refactoring Go code to ensure idiomatic, clean, and efficient implementations.
go-dev-guidelines
jumppad-labs
This skill should be used when writing, refactoring, or testing Go code. It provides idiomatic Go development patterns, TDD-based workflows, project structure conventions, and testing best practices using testify/require and mockery. Activate this skill when creating new Go features, services, packages, tests, or when setting up new Go projects.
opentelemetry-instrumentation-extension
docker
Extend OpenTelemetry instrumentation when new functionality is added to the MCP Gateway. Use when (1) new operations/functions are added, (2) reviewing code for missing instrumentation, (3) user requests otel/telemetry additions, or (4) working with state-changing operations. Analyzes git diff, suggests instrumentation points following project standards in docs/telemetry/README.md, implements with approval, writes tests, updates documentation, and verifies with debug logging and docker logs.
golang
MadAppGang
Use when building Go backend services, implementing goroutines/channels, handling errors idiomatically, writing tests with testify, or following Go best practices for APIs/CLI tools.
code-formatting
openshift
MANDATORY: When writing Go tests, you MUST use 'When...it should...' format for ALL test names. When writing any Go code, you MUST remind user to run 'make lint-fix' and 'make verify'. These are non-negotiable HyperShift requirements.
tidb-test-guidelines
pingcap
Decide where to place TiDB tests and how to write them (basic structure, naming, testdata usage). Use when asked about test locations, writing conventions, shard_count limits, casetest categorization, or when reviewing test changes in code review.