agentsclimarketplace

Vigilante issue implementation on go

Skill aliengiraffe/vigilante/skills/vigilante-issue-implementation-on-go

Vigilante is a sandbox-first orchestration layer for coding agents. It isolates every task in a git worktree, enforces strict credential scoping, and gives you full audit logs — so your agents can't burn down production.

Install
npx -y skills add aliengiraffe/vigilante --skill vigilante-issue-implementation-on-go

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

Implement a GitHub issue end-to-end when Vigilante dispatches work for a Go repository with idiomatic tooling and security guidance.

SKILL.md

4.0 KB, as published. Nobody here has run it

Vigilante Go Issue Implementation

Focus

  • Read the prompt for detected tech stacks, process hints, and Go security guidance before changing code.
  • Follow idiomatic Go conventions from Effective Go for naming, formatting, error handling, and package structure.
  • Keep changes scoped to the issue and do not broaden into unrelated style or lint fixes.

Go Tooling Workflow

  • Formatting: run gofmt or go fmt on all touched Go files. If the repository uses goimports, use that instead. Do not hand-format Go code.
  • Testing: run targeted go test ./path/to/package/... for changed packages first, then broader go test ./... when changes cross package boundaries. Use -race when practical.
  • Vetting: run go vet ./... on touched packages to catch common mistakes.
  • Vulnerability checking: run govulncheck ./... when it is installed and the change touches dependencies or security-sensitive code. If govulncheck is not available, note its absence and continue with other validation — do not fabricate output.
  • Linting: use the repository's established lint tooling. Prefer golangci-lint when configured (.golangci.yml or .golangci.yaml), or staticcheck when that is the project standard. If no project linter is configured, go vet is sufficient. Do not introduce a different linter unless the issue specifically requires it.
  • Dependencies: run go mod tidy after any dependency changes. Prefer standard library packages when they cover the need.

Effective Go Style

  • Use MixedCaps for multi-word names, not underscores.
  • Keep exported identifiers descriptive and unexported identifiers short.
  • Return errors rather than panicking.
  • Write doc comments on exported identifiers starting with the identifier name.
  • Keep packages focused and APIs minimal.

Security

  • Use crypto/rand for security-sensitive random values, not math/rand.
  • Prefer standard library crypto packages over third-party alternatives.
  • Use crypto/subtle.ConstantTimeCompare for comparing secret values.
  • Consider fuzz tests for parsers and input-handling logic (Go 1.18+ func FuzzXxx).
  • Do not store secrets, tokens, or credentials in source files.

Mixed-Language Repositories

  • A Go repository may include a frontend layer such as HTMX templates served from Go, a React or Next.js app in a subdirectory, or another frontend framework colocated with the Go backend.
  • Scope Go tooling (gofmt, go test, go vet, govulncheck, Go linters) to Go source files and packages only. Do not run Go tools against frontend code.
  • When the repository also has a Node.js or TypeScript frontend, respect its own toolchain (package manager, bundler, linter, test runner) for frontend-scoped changes. Check the prompt for detected tech stacks and process hints.
  • When an issue touches both Go backend and frontend code, validate each side with its own toolchain rather than validating only one side.
  • Do not assume a Go repository is Go-only. Read process hints and workspace signals in the prompt to understand the full repository structure.

Workflow

  • Follow the base vigilante-issue-implementation workflow for issue comments, validation, push, and PR creation, including stacked base-branch detection (Base branch: directive in the issue body).
  • Use vigilante commit for all commit-producing operations. Do not use git commit or GitHub CLI commit flows directly.
  • Any commit or amend must preserve the user's existing git author, committer, and signing configuration. Commit on behalf of the user and do not overwrite git config with a coding-agent identity.
  • Do not add Co-authored by: trailers or any other agent attribution for Codex, Claude, Gemini, or similar coding-agent identities.
  • Repository-specific instructions (AGENTS.md, README.md, CI config) remain authoritative when they are more specific than the generic Go guidance in this skill.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.