Arbitrary git subcommands are allowed beyond the Go design task
Source references: 3The tool declaration permits `Bash(git:*)` without limiting it to read-only commands, while the stated task is Go type design and its diagnostic steps only require Go tooling.
If the Skill is misapplied, an agent could stage or commit user changes, switch branches, rewrite history, or—where credentials and network access exist—push to a remote. The permission declaration alone does not show that any such action occurs.
The skill is for Go type and interface design, yet it permits every `git` subcommand rather than read-only inspection. If the host enforces this declaration and the model invokes such a command, it could alter history, delete branches, or push to remotes, affecting the user's repository or remote account. Those powers are not necessary for the stated design tasks. The user can ask the author to remove this permission or allow only specific read-only git commands.
name: golang-structs-interfacesdescription: 'Golang struct and interface design patterns — composition, embedding, type assertions, type switches, interface segregation, dependency injection via interfaces, struct field tags, and pointer vs value receivers. Use this skill when designing Go types, defining or implementing interfaces, embedding structs or interfaces, writing type assertions or type switches, adding struct field tags for JSON/YAML/DB serialization, or choosing between pointer and value receivers. Also use when the user asks about "accept interfaces, return structs", compile-time interface checks, or composing small interfaces into larger ones.'user-invocable: trueShow 2 other places
install: []allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent AskUserQuestionpaths:**Diagnose:** 1- `go vet ./...` — `copylocks` reports every value copy of a lock-bearing struct 2- `go test -race ./...` — surfaces the data races a silent copy introduces