.pi/agent/skills/go-understanding/SKILL.md
Comprehensive analysis of unfamiliar Go packages — structure, public API, dependencies, coding patterns. Use when exploring a new package or preparing for complex refactoring.
npx skillsauth add popoffvg/dotfiles go-understandingInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Systematic workflow for understanding Go codebases before making modifications.
Use when:
Skip when:
Always choose the specific package you want to work with, then:
Read package documentation in order:
doc.go - Package documentation and examplesindex.out - Generated documentation indexREADME.md - Project-specific informationReport documentation usefulness:
index.out or doc.go, report itUse gopls MCP tools for comprehensive analysis:
# Understand workspace structure
mcp__gopls__go_workspace
# Find relevant symbols and patterns
mcp__gopls__go_search "pattern"
# Get detailed file context
mcp__gopls__go_file_context "/path/to/file.go"
# Understand package API
mcp__gopls__go_package_api "package/path"
Read target files with focus on:
Read tests to understand:
Summarize your findings:
This understanding phase should be used before:
go-modify - For code modificationsgo-test-debug - For test debugginggo-debug - For debugging workflowsdoc.go - Always read firstindex.out - Generated docsREADME.md - Project contextgo_workspace - Structure overviewgo_search - Find symbolsgo_file_context - Detailed analysisgo_package_api - Interface understanding.claude/rules/go-coding.md for project-specific conventionsEval checklist:
Test inputs:
Can change: analysis workflow, output structure, depth of dependency analysis, pattern categorization Cannot change: skip-when criteria (single file, familiar code), read-only nature, four-dimension coverage Min sessions before eval: 5 Runs per experiment: 3
tools
Improve a whole CLAUDE.local.md — the private, per-project rules captured from user corrections. Wraps each conditional rule in a <task-relevant> block so it only surfaces for matching work, merges duplicates, generalizes one-off facts, drops stale entries, and routes raw project facts to engram. Use when the user says "improve claude.local", "clean up the local rules", "claude.local is bloated", or after the Stop hook has appended many rules.
testing
WM pipeline and conventions shared across all phases. Agents must read this before spec, impl, or verify work.
development
One entry point for spec writing, implementation, and bug fixing. Default is new (write spec → grill loop → produce notes → author TODO bodies). Other subcommands: verify (audit), revise (sync to shipped), prototype (settle a decision), code-map (diagram), impl (execute one TODO), fix (analyze cause, correct thoughts, fix behavior), help (this page). Invoke as /code <subcommand>.
development
Red-Green-Refactor cycle for bug fixes. Before fixing a bug, first write a failing test that reproduces it (Red), then make the minimal change to pass (Green), then clean up the code (Refactor). Use on any bug fix, error correction, failing test repair, or when user says "fix this bug".