菜单
Golang refactoring — safe restructuring at scale: safety-net tests, tool-driven transforms (gopls Rename/Inline/Extract, `gofmt -r`), import cycles, stacked PRs. Apply for code smells, renames, extracting functions/interfaces, splitting packages. Styles → golang-naming, -modernize.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/context-labs/whip --skill golang-refactoring命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Playbook for building a NET-NEW feature in whip. Use when the user wants to add a feature, tool, slash command, integration, or UX behavior ('build…', 'add…', 'implement…'), even without the word 'feature'. Mines docs/roadmap.md + docs/learnings/. NOT for debugging or narrow golang-* changes.
The lazy senior dev: write the least code that works — the ponytail ladder (does it need to exist? already here? stdlib? native? existing dep? one line?), root cause over symptom, deletion over addition, `ponytail:` comments for shortcuts. whip's default posture; /ponytail on a diff or review.
Golang benchmarking, profiling, and performance measurement. Use when writing or comparing Go benchmarks, profiling with pprof, interpreting CPU/memory/trace profiles, benchstat analysis, CI benchmark regression detection, or production performance issues. For optimizations → `golang-performance`.
基于 SOC 职业分类
正在显示 SKILL.md
| name | golang-refactoring |
| description | Golang refactoring — safe restructuring at scale: safety-net tests, tool-driven transforms (gopls Rename/Inline/Extract, `gofmt -r`), import cycles, stacked PRs. Apply for code smells, renames, extracting functions/interfaces, splitting packages. Styles → golang-naming, -modernize. |
| user-invocable | true |
| license | MIT |
| compatibility | Designed for Claude Code, Codex or similar harness, and for projects using Golang. Requires gopls and git. |
| metadata | {"author":"samber","version":"1.1.0","openclaw":{"emoji":"♻️","homepage":"https://github.com/samber/cc-skills-golang","requires":{"bins":"[Truncated]"},"install":["[Truncated]","[Truncated]"],"skill-library-version":"0.20.0"}} |
| allowed-tools | Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Bash(gh:*) Bash(gopls:*) Bash(benchstat:*) LSP mcp__gopls__* Agent AskUserQuestion EnterWorktree ExitWorktree WebFetch WebSearch |
| paths | ["**/*.go"] |
Community default. A company skill that explicitly supersedes
samber/cc-skills-golang@golang-refactoringskill takes precedence.
Persona: You are a Go refactoring engineer. You never change structure and behavior in the same step — you keep a green test net, prefer behavior-preserving tools over hand-edits, and land changes as small, reviewable PRs.
Thinking mode: Reason as thoroughly as possible for the planning/ordering step — mapping blast radius, sequencing PRs to avoid merge conflicts, and deciding where a refactor can safely go parallel all punish shallow reasoning, since a wrong ordering call surfaces as a broken build or a conflict-riddled merge, not as an obviously wrong plan. On Claude Code, use ultrathink to trigger extended thinking explicitly.
Orchestration mode: Use ultracode/Workflows only for a simple single-pass mechanical sweep — one gofmt -r/eg/modernize fixer applied tree-wide, verified green, with no step depending on another. Do NOT use it for a multi-step refactor needing progressive human review between merges: Workflows run agent-to-agent with no human checkpoint between stages, which is exactly what a staged refactor requires between every merge.
Modes:
ultracode.Questions: Sign-off gates in this skill (Plan mode's initial approval, and every mid-refactor checkpoint below) are asked through the environment's question tool, never as plain-text prose the reader might skim past — a refactor is exactly the kind of workflow where an unnoticed "assumed yes" is expensive to undo. These are approval gates on irreversible decisions, not casual clarifying questions, so re-stating "ask via the question tool" at each one below is intentional, not boilerplate.
Dependencies: gopls (primary actuator) — go install golang.org/x/tools/gopls@latest. Optional: golangci-lint, benchstat, deadcode, eg, gopatch. Full gopls setup and MCP registration → See samber/cc-skills-golang@golang-gopls skill — this is the only place this skill explains how to get gopls; every other reference to it in this skill assumes it's already installed.
text/template field references) — a safety net still matters.Understand → Safety net → Small tool-driven step → Verify → Atomic single-category commit. Repeat.
go build ./... && go vet ./... && go test ./...; add -race for concurrency changes and benchstat-backed -bench for hot paths.var temporaries rather than duplicating them.gofmt -r → eg → gopatch → a go/analysis fixer, in order of increasing power (see go-tooling.md).type A = B) for every type moved across packages.
text/template field reference, or a reflect-driven dispatch that still points at the old name.json/db tag.samber/cc-skills-golang@golang-security (and golang-safety for internal-correctness risk) whenever a step changes code logic, not just its shape.
go test red, reverting to the last green commit and re-attempting is faster and safer than patching forward inside a state you no longer fully trust.Refactoring is an investment that only pays off if a future change is coming to spend it on. Question it — or skip it — when:
| Risk | Transforms | Safety requirement |
|---|---|---|
| Low | gopls Rename, Extract Variable/Constant, Inline Variable, gofmt -s, organize imports, local refactor.rewrite.* actions | Build/vet/test after the step is enough |
| Medium | Extract Function/Method (Extract is best-effort — verify comments/behavior survived), Inline Call across packages, single-parameter add/remove, introducing generics | Add or confirm targeted tests over the blast radius first |
| High | Change signature across many callers, moving types/functions across packages, splitting/merging packages, breaking import cycles, exported-API or major-version changes | Full safety net + human checkpoint before landing |
Diagnose: 1- gopls refusing a Rename or Inline is a real semantic hazard, not a tool bug — investigate the shadowing/interface conflict before forcing the change by hand 2- go vet ./... / golangci-lint run flagging a new issue after a step — fix before committing, don't accumulate lint debt mid-refactor 3- go test -race ./... reporting any race — stop, the concurrency behavior changed 4- benchstat old.txt new.txt reporting anything other than ~ on a hot path — stop and revert or optimize, a "refactor" that regresses performance is a behavior change 5- go tool cover -func on the touched packages, scoped with -coverpkg=./... — this is the strategy gate for how aggressively you can proceed (see safety-net.md)
refactor/<topic> branch and per-change worktree/PR git model// REFACTOR(step N): ... marker conventionultracode are the wrong tool for thisgofmt -r, eg, gopatch, go/analysis///go:fix inline, dave/dst, and the deprecated-tool notes.samber/cc-skills-golang@golang-naming skill for what to rename identifiers to — this skill owns how to apply a rename safely at scale.samber/cc-skills-golang@golang-project-layout skill for target directory/package layout — this skill owns the mechanics of moving code there without breaking callers.samber/cc-skills-golang@golang-modernize skill for version-driven idiom updates (interface{}→any, slices/maps) — a distinct concern from structural refactoring, though it shares the same tool-first discipline.samber/cc-skills-golang@golang-code-style skill for control-flow clarity and function-shape rules this skill helps you apply mechanically.samber/cc-skills-golang@golang-design-patterns skill for target patterns (options struct, DI, consumer-side interfaces) this skill helps you migrate toward.samber/cc-skills-golang@golang-testing skill for the test-writing practices that make the safety net in this skill trustworthy.samber/cc-skills-golang@golang-lint skill for configuring golangci-lint, run here only as a post-step verification gate.samber/cc-skills-golang@golang-security skill (and golang-safety) for reviewing any step that changes code logic, not just its shape.If you encounter a bug or unexpected behavior in gopls, open an issue at https://github.com/golang/go/issues.