gentleman-system
Provides standardized OS detection and command execution helpers for system-level tasks.
Install
mkdir -p .claude/skills/gentleman-system && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/2375" && unzip -o skill.zip -d .claude/skills/gentleman-system && rm skill.zipInstalls to .claude/skills/gentleman-system
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.
System detection and command execution patterns for Gentleman.Dots. Trigger: When editing files in installer/internal/system/, adding OS support, or modifying command execution.Key capabilities
- →Detects OS environment (Termux, macOS, Linux variants)
- →Normalizes command execution for different platforms
- →Checks availability of package managers like brew or pkg
- →Standardizes sudo and logging in system commands
How it works
Matches the runtime environment against a priority list and assigns appropriate execution functions based on the detected operating system.
Inputs & outputs
When to use gentleman-system
- →Adding support for a new operating system
- →Implementing OS-specific command execution
- →Checking for package manager availability
- →Adding system health checks
About this skill
When to Use
Use this skill when:
- Adding support for new operating systems
- Modifying OS detection logic
- Working with command execution (sudo, brew, pkg)
- Adding new system checks
- Implementing backup/restore functionality
Critical Patterns
Pattern 1: OSType Enum
All OS types are defined in detect.go:
type OSType int
const (
OSMac OSType = iota
OSLinux
OSArch
OSDebian // Debian-based (Debian, Ubuntu)
OSTermux // Termux on Android
OSUnknown
)
Pattern 2: SystemInfo Structure
Detection results in SystemInfo struct:
type SystemInfo struct {
OS OSType
OSName string
IsWSL bool
IsARM bool
IsTermux bool
HomeDir string
HasBrew bool
HasPkg bool // Termux package manager
HasXcode bool
UserShell string
Prefix string // Termux $PREFIX or empty
}
Pattern 3: OS Detection Priority
Termux is checked FIRST (runs on Linux but is special):
func Detect() *SystemInfo {
info := &SystemInfo{...}
// Check Termux FIRST
if isTermux() {
info.OS = OSTermux
info.IsTermux = true
info.HasPkg = checkPkg()
return info
}
// Then check standard OS
switch runtime.GOOS {
case "darwin":
info.OS = OSMac
case "linux":
if isArchLinux() {
info.OS = OSArch
} else if isDebian() {
info.OS = OSDebian
}
}
return info
}
Pattern 4: Command Execution Functions
Use the right function for each context:
// Basic command (no sudo, no logs)
system.Run("git clone ...", nil)
// With real-time logs
system.RunWithLogs("git clone ...", nil, func(line string) {
SendLog(stepID, line)
})
// Homebrew commands
system.RunBrewWithLogs("install fish", nil, logFunc)
// Sudo commands (password prompt)
system.RunSudo("apt-get install -y git", nil)
system.RunSudoWithLogs("pacman -S git", nil, logFunc)
// Termux pkg commands (no sudo needed)
system.RunPkgInstall("fish git", nil, logFunc)
system.RunPkgWithLogs("update", nil, logFunc)
Decision Tree
Adding new OS support?
├── Add OSType constant in detect.go
├── Add detection function (isNewOS())
├── Update Detect() with priority order
├── Update SystemInfo if new fields needed
└── Add OS case in installer.go steps
Running a command?
├── Needs sudo? → RunSudo() or RunSudoWithLogs()
├── Needs brew? → RunBrewWithLogs()
├── On Termux? → RunPkgInstall() or RunPkgWithLogs()
├── Needs logs? → RunWithLogs()
└── Simple exec? → Run()
Checking if tool exists?
├── Use CommandExists("toolname")
└── Returns bool
Code Examples
Example 1: Termux Detection
func isTermux() bool {
// Check TERMUX_VERSION environment variable
if os.Getenv("TERMUX_VERSION") != "" {
return true
}
// Check PREFIX contains termux path
prefix := os.Getenv("PREFIX")
if strings.Contains(prefix, "com.termux") {
return true
}
// Check for Termux-specific paths
if _, err := os.Stat("/data/data/com.termux"); err == nil {
return true
}
return false
}
Example 2: Platform-Specific Execution
func installTool(m *Model) error {
var result *system.ExecResult
switch {
case m.SystemInfo.IsTermux:
// Termux: use pkg (no sudo)
result = system.RunPkgInstall("tool", nil, logFunc)
case m.SystemInfo.OS == system.OSArch:
// Arch: use pacman with sudo
result = system.RunSudoWithLogs("pacman -S --noconfirm tool", nil, logFunc)
case m.SystemInfo.OS == system.OSMac:
// macOS: use Homebrew
result = system.RunBrewWithLogs("install tool", nil, logFunc)
case m.SystemInfo.OS == system.OSDebian:
// Debian/Ubuntu: use Homebrew (installed by us)
result = system.RunBrewWithLogs("install tool", nil, logFunc)
default:
return fmt.Errorf("unsupported OS: %v", m.SystemInfo.OS)
}
return result.Error
}
Example 3: Homebrew Prefix Detection
func GetBrewPrefix() string {
if runtime.GOOS == "darwin" {
// Apple Silicon uses /opt/homebrew
// Intel uses /usr/local
if runtime.GOARCH == "arm64" {
return "/opt/homebrew"
}
return "/usr/local"
}
return "/home/linuxbrew/.linuxbrew"
}
Example 4: File Operations
// Ensure directory exists
if err := system.EnsureDir(filepath.Join(homeDir, ".config/tool")); err != nil {
return err
}
// Copy single file
if err := system.CopyFile(src, dst); err != nil {
return err
}
// Copy directory contents
if err := system.CopyDir("Gentleman.Dots/Config/*", destDir+"/"); err != nil {
return err
}
ExecResult Structure
type ExecResult struct {
Output string // stdout
Stderr string // stderr
ExitCode int // exit code
Error error // error if any
}
// Usage
result := system.Run("command", nil)
if result.Error != nil {
// Handle error
}
if result.ExitCode != 0 {
// Non-zero exit
}
Commands
cd installer && go test ./internal/system/... # Run system tests
cd installer && go test -run TestDetect # Test OS detection
cd installer && go test -run TestExec # Test command execution
Resources
- Detection: See
installer/internal/system/detect.gofor OS detection - Execution: See
installer/internal/system/exec.gofor command running - Backup: See
installer/internal/system/backup.gofor backup/restore - Tests: See
installer/internal/system/*_test.gofor patterns
When not to use it
- →Standard Go applications without system-level hardware detection
- →Cross-platform tools that avoid shell execution
Limitations
- →New OS support requires manual updates to the detection logic
- →Depends on predictable shell environment behavior
How it compares
Abstracts away messy platform-specific shell logic into consistent internal Go functions.
Compared to similar skills
gentleman-system side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| gentleman-system (this skill) | 1 | 7mo | Review | Intermediate |
| upgrading-golang | 1 | 5mo | Review | Intermediate |
| agent-module-architecture | 2 | 3mo | No flags | Intermediate |
| gentleman-installer | 1 | 7mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by Gentleman-Programming
View all by Gentleman-Programming →You might also like
upgrading-golang
chainloop-dev
Upgrades Go version across the entire Chainloop codebase including source files, Docker images, CI/CD workflows, and documentation. Use when the user mentions upgrading Go, golang version, or updating Go compiler version.
agent-module-architecture
TencentBlueKing
Agent 构建机模块架构指南(Go 语言),涵盖 Agent 启动流程、心跳机制、任务领取执行、升级更新、与 Dispatch 交互。当用户开发 Agent 功能、修改心跳逻辑、处理任务执行或实现 Agent 升级时使用。
gentleman-installer
Gentleman-Programming
Installation step patterns for Gentleman.Dots TUI installer. Trigger: When editing installer.go, adding installation steps, or modifying the installation flow.
go-agent-development
TencentBlueKing
Go Agent 开发指南,涵盖 Agent 架构设计、心跳机制、任务执行、日志上报、升级流程、与 Dispatch 模块交互。当用户开发构建机 Agent、实现任务执行逻辑、处理 Agent 通信或进行 Go 语言开发时使用。
goto-remote-command
chinglinwen
Use this skill in the goto/goterm project when an agent needs to execute remote commands over SSH with the goto CLI, debug batch remote execution, preserve raw stdout/stderr/exit status, or update remote-command docs, tests, or behavior.
opencode-cli
SpillwaveSolutions
This skill should be used when configuring or using the OpenCode CLI for headless LLM automation. Use when the user asks to "configure opencode", "use opencode cli", "set up opencode", "opencode run command", "opencode model selection", "opencode providers", "opencode vertex ai", "opencode mcp servers", "opencode ollama", "opencode local models", "opencode deepseek", "opencode kimi", "opencode mistral", "fallback cli tool", or "headless llm cli". Covers command syntax, provider configuration, Vertex AI setup, MCP servers, local models, cloud providers, and subprocess integration patterns.