Token导航 LogoToken导航TokenDH.com
前端设计敏感数据github未标认证来源可访问许可证需确认审计提醒

go-dev去开发

Agent Skill

go-dev 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

306

周安装

13

GitHub Stars

公开资料未说明

下载量

107
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:go-dev(去开发)
来源仓库:https://github.com/marsolab/skills
仓库路径:skills/go-dev
安装命令:
npx skills add https://github.com/marsolab/skills --skill go-dev
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/marsolab/skills --skill go-dev

简介

go-dev 用于处理 GitHub 仓库、Issue、Pull Request 等协作信息,辅助开发流程。

  • 适合在 Codex、Claude、Cursor、Gemini CLI 中围绕代码变更、协作事项进行整理时使用。
  • 通过 GitHub 安装,使用 npx skills add 命令添加,需结合原始 README 确认具体用法。
  • 安装前应核实权限范围、维护状态,以及是否涉及联网、命令执行或文件读写操作。
  • go-dev 属于前端设计类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

Go Development

Write Go code that is readable, maintainable, and production-ready using battle-tested patterns from major production codebases.

For comprehensive coverage of all idioms, patterns, and pitfalls, read references/go-styleguide.md. This file focuses on quick decisions and workflows.

MCP

Always use Context7 MCP to fetch the latest documentation.

Libraries

  • Prefer well-maintained, zero-dependency libraries from the awesome-go list.
  • HTTP routing: Chi.
  • Logging: log/slog (structured, leveled, stdlib since Go 1.21).
  • Configuration: flags or environment variables — no external config frameworks.
  • Database access: sqlc for typesafe SQL code generation.
  • Migrations: goose.
  • Testing: stdlib testing package. Avoid third-party assertion libraries.

Linters

Run golangci-lint on every commit and pull request. Use the bundled .golangci.yml config:

# Setup linting for a project
scripts/setup_golangci_lint.sh /path/to/project

# Run all linters
golangci-lint run ./...

# Auto-fix
golangci-lint run --fix ./...

Run goimports before committing to keep imports formatted.

Quick Decision Trees

When to use generics?

Use generics (Go 1.18+) when:

  • Writing data structures (trees, caches, pools) that work across types.
  • Utility functions that operate on slices, maps, or channels of any type.
  • Type constraints reduce duplication without sacrificing readability.

Avoid generics when:

  • A concrete type or any suffices.
  • The function body would need type assertions anyway.
  • It makes the code harder to read for marginal DRY benefit.
// GOOD: generic utility
func Map[T, U any](s []T, f func(T) U) []U {
    result := make([]U, len(s))
    for i, v := range s {
        result[i] = f(v)
    }
    return result
}

// GOOD: constrained type
type Number interface {
    ~int | ~int64 | ~float64
}

func Sum[T Number](nums []T) T {
    var total T
    for _, n := range nums {
        total += n
    }
    return total
}

When to use interfaces?

Define interfaces at the consumption site, not the implementation:

// GOOD: consumer defines what it needs
package storage

type Store interface {
    Get(key string) ([]byte, error)
}

// BAD: implementation forces interface on consumers
package postgres

type PostgresStore interface { ... }

Interface size: 1 method is perfect, 2-3 if cohesive, 4+ consider splitting. Larger interfaces are acceptable for SaaS/enterprise products; keep them small for libraries.

Accept interfaces, return concrete types.

How to handle errors?

  1. Can I handle this completely here? → Log and continue.
  2. Does caller need programmatic access? → %w wrapping.
  3. Should I hide implementation details? → %v wrapping.
  4. Is this a library? → Never log, always return.
// Wrap with context
if err != nil {
    return fmt.Errorf("connect to database: %w", err)
}

Error strings: lowercase, no punctuation, no "failed to" prefix. Handle each error exactly once — log OR return, never both.

Use errors.Join (Go 1.20+) to combine multiple independent errors:

var errs []error
for _, item := range items {
    if err := process(item); err != nil {
        errs = append(errs, err)
    }
}
if err := errors.Join(errs...); err != nil {
    return fmt.Errorf("processing batch: %w", err)
}

When to use concurrency?

Leave concurrency to the caller unless building a server/daemon, worker pool, or managing background operations.

Before launching a goroutine, know when it will stop:

ctx, cancel := context.WithTimeout(ctx, 30*time.Second)
defer cancel()

go func() {
    for {
        select {
        case <-ctx.Done():
            return
        case work := <-ch:
            process(work)
        }
    }
}()

Context as first parameter. Always.

Iterators (Go 1.23+)

Use iter.Seq and iter.Seq2 for lazy iteration:

// Iterator that yields values
func FilterPositive(nums []int) iter.Seq[int] {
    return func(yield func(int) bool) {
        for _, n := range nums {
            if n > 0 {
                if !yield(n) {
                    return
                }
            }
        }
    }
}

// Consuming an iterator
for v := range FilterPositive(data) {
    fmt.Println(v)
}

Use range-over-int (Go 1.22+): for i:= range n instead of for i:= 0; i < n; i++.

Structured logging with slog

Use log/slog for all logging. Pass the logger as a dependency, never as a package-level global:

type Server struct {
    logger *slog.Logger
}

func NewServer(logger *slog.Logger) *Server {
    return &Server{logger: logger}
}

func (s *Server) HandleRequest(ctx context.Context, req *Request) {
    s.logger.InfoContext(ctx, "handling request",
        slog.String("method", req.Method),
        slog.String("path", req.Path),
    )
}

Use slog.With to add common attributes. Use LogValuer for expensive values that should only be computed when the log level is enabled.

Testing

Table-driven tests with map[string]testCase for descriptive names:

func TestProcess(t *testing.T) {
    type testCase struct {
        input   string
        want    string
        wantErr bool
    }

    tests := map[string]testCase{
        "valid input": {
            input: "hello",
            want:  "HELLO",
        },
        "empty input returns error": {
            input:   "",
            wantErr: true,
        },
    }

    for name, tc := range tests {
        t.Run(name, func(t *testing.T) {
            got, err := Process(tc.input)
            if (err != nil) != tc.wantErr {
                t.Fatalf("Process() error = %v, wantErr %v", err, tc.wantErr)
            }
            if got != tc.want {
                t.Errorf("Process() = %q, want %q", got, tc.want)
            }
        })
    }
}

Test helpers call t.Helper() so failure line numbers point to the actual test.

Integration tests skip when environment is not set:

func TestIntegration(t *testing.T) {
    if os.Getenv("INTEGRATION_TESTS") == "" {
        t.Skip("skipping integration tests")
    }
}

Common Workflows

Creating a new HTTP service

Project structure:

myservice/
├── cmd/server/main.go
├── internal/
│   ├── handler/
│   ├── service/
│   └── storage/
├── db/
│   ├── migrations/
│   └── queries/
├── go.mod
├── Makefile
└── .golangci.yml

main.go pattern — flags, graceful shutdown:

func main() {
    addr := flag.String("addr", ":8080", "listen address")
    flag.Parse()

    srv := &http.Server{
        Addr:         *addr,
        Handler:      setupRoutes(),
        ReadTimeout:  30 * time.Second,
        WriteTimeout: 30 * time.Second,
    }

    go func() {
        sigint := make(chan os.Signal, 1)
        signal.Notify(sigint, os.Interrupt)
        <-sigint

        ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
        defer cancel()
        srv.Shutdown(ctx)
    }()

    log.Printf("listening on %s", *addr)
    if err := srv.ListenAndServe(); err != http.ErrServerClosed {
        log.Fatalf("server error: %v", err)
    }
}

Working with SQL databases using sqlc

sqlc generates typesafe Go code from SQL queries. Write SQL, get Go.

1. Install and configure:

# sqlc.yaml
version: "2"
sql:
  - schema: "db/migrations"
    queries: "db/queries"
    engine: "postgresql"
    gen:
      go:
        package: "db"
        out: "internal/db"
        emit_json_tags: true
        emit_interface: true

2. Write migrations (with goose):

-- db/migrations/001_create_users.sql
-- +goose Up
CREATE TABLE users (
    id    BIGSERIAL PRIMARY KEY,
    email TEXT NOT NULL UNIQUE,
    name  TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- +goose Down
DROP TABLE users;

3. Write queries with annotations:

-- db/queries/users.sql

-- name: GetUser :one
SELECT id, email, name, created_at
FROM users
WHERE id = $1;

-- name: ListUsers :many
SELECT id, email, name, created_at
FROM users
ORDER BY created_at DESC;

-- name: CreateUser :one
INSERT INTO users (email, name)
VALUES ($1, $2)
RETURNING id, email, name, created_at;

-- name: DeleteUser :exec
DELETE FROM users WHERE id = $1;

4. Generate and use:

sqlc generate
// internal/db/ now contains typesafe Go code
func (s *Service) GetUser(ctx context.Context, id int64) (db.User, error) {
    return s.queries.GetUser(ctx, id)
}

5. Testing with sqlc:

Enable emit_interface: true in sqlc.yaml to get a Querier interface for mocking in unit tests. Use a real database for integration tests.

Creating a CLI tool

mycli/
├── main.go
├── internal/command/
├── go.mod
└── .golangci.yml

Use flag.NewFlagSet for subcommands. Write errors to stderr, exit non-zero on failure.

Quick Reference

Naming: packages lowercase/singular, no Get prefix on getters, acronyms consistent case (URL not Url), constants in mixedCaps.

Structure: return early with guard clauses, success path left-aligned, imports grouped: stdlib → external → internal.

Critical pitfalls: loop variable capture in closures, nil interface vs nil value in interface, defer in loops (wrap in closure), map writes to nil map.

For the full reference on all patterns, see references/go-styleguide.md.

Linting Setup

Run the setup script to configure golangci-lint for a project:

scripts/setup_golangci_lint.sh /path/to/your/project

This copies the bundled .golangci.yml and optionally installs a pre-commit hook. Common commands:

golangci-lint run ./...         # run all linters
golangci-lint run --fix ./...   # auto-fix issues
golangci-lint run ./internal/...# lint specific paths

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

34.81%
按下载量换算37

Claude

28.53%
按下载量换算31

Cursor

18.41%
按下载量换算20

Gemini CLI

10.28%
按下载量换算11

安全审计

Gen Agent Trust Hub

可疑

Socket

通过

Snyk

可疑

权限和风险

敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills