[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CFNQW54N7Y5MD591AM38DN":3,"skill-same:01M6CFNQW54N7Y5MD591AM38DN":103},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":65,"commitSha":66,"skillDirectory":67,"forksCount":68,"repositoryHtmlUrl":69,"repositoryHomepageUrl":6,"ownerHtmlUrl":70,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":71,"install":72,"resources":84},"01M6CFNQW54N7Y5MD591AM38DN","golang-uber-dig",null,"Implements dependency injection in Golang using uber-go\u002Fdig — reflection-based container, Provide\u002FInvoke, dig.In\u002Fdig.Out parameter and result objects, named values, value groups, optional dependencies, scopes, and Decorate. Apply when using or adopting uber-go\u002Fdig, when the codebase imports `go.uber.org\u002Fdig`, or when wiring an application graph at startup. For higher-level lifecycle and modules, see `golang-uber-fx` skill.","rockcookies\u002Fskills","rockcookies","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F3498265?v=4","01M6CF9C16X3SDSKZX6ANH7HQM","Jacob He","01M6CF9C53JP821FCW6R9B00AJ",1,"MIT","https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsamber-golang\u002Fgolang-uber-dig\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"golang uber dig","golang","gopls","context7","reflection","modules","container","dependency","webfetch","read","projects","MCP","Bash","lifecycle","https","harness","code","lint","codex","github","2026-11-10 10:12:30",false,"---\nname: golang-uber-dig\ndescription: >-\n  Implements dependency injection in Golang using uber-go\u002Fdig — reflection-based\n  container, Provide\u002FInvoke, dig.In\u002Fdig.Out parameter and result objects, named\n  values, value groups, optional dependencies, scopes, and Decorate. Apply when\n  using or adopting uber-go\u002Fdig, when the codebase imports `go.uber.org\u002Fdig`, or\n  when wiring an application graph at startup. For higher-level lifecycle and\n  modules, see `golang-uber-fx` skill.\nuser-invocable: true\nlicense: MIT\ncompatibility: >-\n  Designed for Claude Code, Codex or similar harness, and for projects using\n  Golang.\nmetadata:\n  author: samber\n  version: 1.2.0\n  openclaw:\n    emoji: ⛏\n    homepage: https:\u002F\u002Fgithub.com\u002Fsamber\u002Fcc-skills-golang\n    requires:\n      bins:\n        - go\n    install: []\n    skill-library-version: 1.19.0\nallowed-tools: >-\n  Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent\n  WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs\n  Bash(godig:*) Bash(gopls:*) LSP mcp__gopls__*\npaths:\n  - '**\u002F*.go'\n---\n\n**Persona:** You are a Go architect wiring an application graph with dig. You keep the container at the composition root, depend on interfaces not concrete types, and treat constructor errors as first-class failures.\n\n# Using uber-go\u002Fdig for Dependency Injection in Go\n\nReflection-based DI toolkit, designed to power application frameworks (it is the engine behind `uber-go\u002Ffx`) and resolve object graphs during startup.\n\n**Official Resources:**\n\n- [pkg.go.dev\u002Fgo.uber.org\u002Fdig](https:\u002F\u002Fpkg.go.dev\u002Fgo.uber.org\u002Fdig)\n- [github.com\u002Fuber-go\u002Fdig](https:\u002F\u002Fgithub.com\u002Fuber-go\u002Fdig)\n\nThis skill is not exhaustive. Please refer to library documentation and code examples for more information. For Go package docs, symbols, versions, importers, and known vulnerabilities, → See `golang-pkg-go-dev` skill (`godig`) — prefer it over Context7 for Go package facts. To navigate this library's usage in your own code (definitions, call sites, diagnostics), → See `golang-gopls` skill (`gopls`). Context7 remains a fallback for docs not indexed on pkg.go.dev.\n\n```bash\ngo get go.uber.org\u002Fdig\n```\n\n## dig vs. fx\n\nfx is built on dig and shares the same container engine — the DI primitives (`Provide`, `Invoke`, `In`\u002F`Out` structs, named values, value groups) are identical. `fx.In`\u002F`fx.Out` are re-exports of `dig.In`\u002F`dig.Out`.\n\nWhat fx adds on top of dig:\n\n| Concern | dig | fx |\n| --- | --- | --- |\n| DI container | ✅ `dig.New()` | ✅ (embedded) |\n| Lifecycle hooks | ❌ | ✅ `fx.Lifecycle` OnStart\u002FOnStop |\n| Module system | ❌ | ✅ `fx.Module` with scoped decorators |\n| Signal-aware run loop | ❌ | ✅ `app.Run()` blocks on SIGINT\u002FSIGTERM |\n| Structured event logging | ❌ | ✅ `fx.WithLogger` \u002F `fxevent` |\n| Startup\u002Fshutdown timeout | ❌ | ✅ `fx.StartTimeout` \u002F `fx.StopTimeout` |\n\n**Choose dig** when you need the wiring graph only: CLI tools, libraries exposing a container to callers, test harnesses, or embedding DI into an existing app that manages its own lifecycle.\n\n**Choose fx** for long-running services (HTTP servers, workers, daemons) — lifecycle and signal handling are non-negotiable there. See `golang-uber-fx` skill.\n\n## Container\n\n```go\nimport \"go.uber.org\u002Fdig\"\n\nc := dig.New()\n```\n\nUseful options: `dig.DeferAcyclicVerification()` (faster startup), `dig.RecoverFromPanics()` (turn panics into `dig.PanicError`), `dig.DryRun(true)` (validate without invoking).\n\n## Provide and Invoke\n\n```go\n\u002F\u002F Register a constructor — lazy, only runs when its output is needed\nerr := c.Provide(func(cfg *Config) (*sql.DB, error) {\n    return sql.Open(\"postgres\", cfg.DSN)\n})\n\n\u002F\u002F Pull a service out of the container by asking for it as a function parameter\nerr = c.Invoke(func(db *sql.DB) error {\n    return db.Ping()\n})\n```\n\nConstructors are **lazy** and **memoized**: each output type is built once and shared (singleton per container). `Provide` errors at registration if the constructor is malformed; `Invoke` returns the constructor's error wrapped with the dependency path that triggered it.\n\nA dig constructor is any function. Inputs are dependencies, outputs are provided types. `error` (last return) signals construction failure. Follow \"accept interfaces, return structs\".\n\n## Parameter Objects with `dig.In`\n\nOnce a constructor has 4+ dependencies, embed `dig.In` to group them as struct fields and tag fields:\n\n```go\ntype HandlerParams struct {\n    dig.In\n\n    Logger *zap.Logger\n    DB     *sql.DB\n    Cache  *redis.Client `optional:\"true\"`           \u002F\u002F zero value if not provided\n    DBRO   *sql.DB       `name:\"readonly\"`           \u002F\u002F named dependency\n    Routes []http.Handler `group:\"routes\"`           \u002F\u002F value group\n}\n\nfunc NewHandler(p HandlerParams) *Handler { \u002F* ... *\u002F }\n```\n\nTags: `name:\"...\"`, `optional:\"true\"`, `group:\"...\"`.\n\n## Result Objects with `dig.Out`\n\nReturn several values from one constructor and attach `name`\u002F`group` tags to results:\n\n```go\ntype ConnResult struct {\n    dig.Out\n\n    ReadWrite *sql.DB `name:\"primary\"`\n    ReadOnly  *sql.DB `name:\"readonly\"`\n}\n\nfunc NewConnections(cfg *Config) (ConnResult, error) { \u002F* ... *\u002F }\n```\n\n## Named Values\n\nTwo providers of the same type collide. Disambiguate with `dig.Name`:\n\n```go\nc.Provide(NewPrimaryDB,  dig.Name(\"primary\"))\nc.Provide(NewReadOnlyDB, dig.Name(\"readonly\"))\n```\n\nConsume by adding `name:\"primary\"` \u002F `name:\"readonly\"` to a `dig.In` field.\n\n## Value Groups\n\nMany providers, one consumer slice — typical for HTTP handlers, health checks, migrations:\n\n```go\ntype RouteResult struct {\n    dig.Out\n    Handler http.Handler `group:\"routes\"`\n}\n\nfunc NewUserHandler(db *sql.DB) RouteResult { \u002F* ... *\u002F }\nfunc NewPostHandler(db *sql.DB) RouteResult { \u002F* ... *\u002F }\n\ntype ServerParams struct {\n    dig.In\n    Routes []http.Handler `group:\"routes\"`\n}\n```\n\n**Flatten** — append `,flatten` (e.g. `group:\"routes,flatten\"`) to unwrap a slice instead of nesting it. Group order is **not guaranteed**; if order matters, provide an explicit ordered slice from a single constructor.\n\n## Provide as Interface (`dig.As`)\n\nRegister a concrete constructor and expose it under one or more interfaces without a separate adapter:\n\n```go\nc.Provide(NewPostgresDB, dig.As(new(Database), new(io.Closer)))\n\u002F\u002F Consumers ask for Database or io.Closer; *PostgresDB stays hidden.\n```\n\n## Full Application Example\n\n```go\nfunc main() {\n    c := dig.New()\n\n    must(c.Provide(NewConfig))\n    must(c.Provide(NewLogger))\n    must(c.Provide(NewDatabase))\n    must(c.Provide(NewServer))\n\n    err := c.Invoke(func(srv *http.Server) error {\n        return srv.ListenAndServe()\n    })\n    if err != nil {\n        log.Fatal(err)\n    }\n}\n\nfunc must(err error) { if err != nil { panic(err) } }\n```\n\ndig has **no built-in lifecycle**. If you need OnStart\u002FOnStop hooks, signal handling, and graceful shutdown, use fx — see `golang-uber-fx` skill.\n\nFor Decorate, Scopes, optional deps, error helpers, and Visualize, see [advanced.md](.\u002Freferences\u002Fadvanced.md).\n\n## Best Practices\n\n1. Keep the container at the composition root — never pass `*dig.Container` as a parameter; treat it like a plumbing detail of `main()`. Service-locator patterns defeat the testability gains of DI.\n2. Depend on interfaces, not concrete types — lets you swap implementations in tests without touching production code, and lets you use `dig.As` to expose narrow interfaces from wide structs.\n3. Prefer parameter objects (`dig.In` structs) once a constructor has 4+ dependencies — call sites stay readable and adding a new dependency is a one-line change instead of a signature break.\n4. Group registration by module (one file per module that calls `c.Provide` for its types) — review and refactoring become a per-module concern, and you can extract a module into a fx.Module later without rewriting wiring.\n5. Validate the graph eagerly in tests — call `c.Invoke` against the composition root in CI to surface missing providers at boot time, not at first request. `DryRun(true)` skips constructor execution.\n6. Return errors from constructors instead of panicking — dig wraps them with the dependency path, which makes the failure point obvious.\n\n## Common Mistakes\n\n| Mistake | Fix |\n| --- | --- |\n| Passing the container into services | The container belongs to `main()`. Inject the typed dependencies a service needs; otherwise tests need to build a real container. |\n| Two providers for the same type without `Name` | dig errors at `Provide` time. Either name them, or merge into a single provider that returns a `dig.Out` result struct. |\n| Ignoring `Provide` errors | Wrap each `Provide` with a `must` helper. A silent registration error becomes a missing-type error far later. |\n| Using groups when ordering matters | Groups are unordered. If order matters (middleware chain, migration sequence), provide an explicit ordered slice with one constructor. |\n| Constructors with side effects on import | Keep `init()` empty — start work only inside the constructor, after the graph is built. |\n\n## Testing\n\ndig containers are cheap — build a fresh one per test, override providers with `Decorate`, and call `Invoke` to drive the system. For full patterns (per-test wiring, shared helpers, graph validation in CI, asserting wire-time errors, recovering from constructor panics), see [testing.md](.\u002Freferences\u002Ftesting.md).\n\n## Further Reading\n\n- [advanced.md](.\u002Freferences\u002Fadvanced.md) — Decorate, Scopes, optional deps, error helpers, Visualize, full Quick Reference\n- [recipes.md](.\u002Freferences\u002Frecipes.md) — end-to-end examples: HTTP server with route group, two databases, request scopes, decorators, dry-run validation\n- [testing.md](.\u002Freferences\u002Ftesting.md) — testing patterns and graph validation\n\n## Cross-References\n\n- → See `golang-uber-fx` skill for application lifecycle, modules, and signal-aware Run() built on top of dig\n- → See `golang-dependency-injection` skill for DI concepts and library comparison\n- → See `golang-samber-do` skill for a generics-based alternative without reflection\n- → See `golang-google-wire` skill for compile-time DI (no runtime container)\n- → See `golang-structs-interfaces` skill for interface design patterns\n- → See `golang-testing` skill for general testing patterns\n\nIf you encounter a bug or unexpected behavior in uber-go\u002Fdig, open an issue at \u003Chttps:\u002F\u002Fgithub.com\u002Fuber-go\u002Fdig\u002Fissues>.\n","**Persona:** You are a Go architect wiring an application graph with dig. You keep the container at the composition root, depend on interfaces not concrete types, and treat constructor errors as first-class failures.\n\n# Using uber-go\u002Fdig for Dependency Injection in Go\n\nReflection-based DI toolkit, designed to power application frameworks (it is the engine behind `uber-go\u002Ffx`) and resolve object graphs during startup.\n\n**Official Resources:**\n\n- [pkg.go.dev\u002Fgo.uber.org\u002Fdig](https:\u002F\u002Fpkg.go.dev\u002Fgo.uber.org\u002Fdig)\n- [github.com\u002Fuber-go\u002Fdig](https:\u002F\u002Fgithub.com\u002Fuber-go\u002Fdig)\n\nThis skill is not exhaustive. Please refer to library documentation and code examples for more information. For Go package docs, symbols, versions, importers, and known vulnerabilities, → See `golang-pkg-go-dev` skill (`godig`) — prefer it over Context7 for Go package facts. To navigate this library's usage in your own code (definitions, call sites, diagnostics), → See `golang-gopls` skill (`gopls`). Context7 remains a fallback for docs not indexed on pkg.go.dev.\n\n```bash\ngo get go.uber.org\u002Fdig\n```\n\n## dig vs. fx\n\nfx is built on dig and shares the same container engine — the DI primitives (`Provide`, `Invoke`, `In`\u002F`Out` structs, named values, value groups) are identical. `fx.In`\u002F`fx.Out` are re-exports of `dig.In`\u002F`dig.Out`.\n\nWhat fx adds on top of dig:\n\n| Concern | dig | fx |\n| --- | --- | --- |\n| DI container | ✅ `dig.New()` | ✅ (embedded) |\n| Lifecycle hooks | ❌ | ✅ `fx.Lifecycle` OnStart\u002FOnStop |\n| Module system | ❌ | ✅ `fx.Module` with scoped decorators |\n| Signal-aware run loop | ❌ | ✅ `app.Run()` blocks on SIGINT\u002FSIGTERM |\n| Structured event logging | ❌ | ✅ `fx.WithLogger` \u002F `fxevent` |\n| Startup\u002Fshutdown timeout | ❌ | ✅ `fx.StartTimeout` \u002F `fx.StopTimeout` |\n\n**Choose dig** when you need the wiring graph only: CLI tools, libraries exposing a container to callers, test harnesses, or embedding DI into an existing app that manages its own lifecycle.\n\n**Choose fx** for long-running services (HTTP servers, workers, daemons) — lifecycle and signal handling are non-negotiable there. See `golang-uber-fx` skill.\n\n## Container\n\n```go\nimport \"go.uber.org\u002Fdig\"\n\nc := dig.New()\n```\n\nUseful options: `dig.DeferAcyclicVerification()` (faster startup), `dig.RecoverFromPanics()` (turn panics into `dig.PanicError`), `dig.DryRun(true)` (validate without invoking).\n\n## Provide and Invoke\n\n```go\n\u002F\u002F Register a constructor — lazy, only runs when its output is needed\nerr := c.Provide(func(cfg *Config) (*sql.DB, error) {\n    return sql.Open(\"postgres\", cfg.DSN)\n})\n\n\u002F\u002F Pull a service out of the container by asking for it as a function parameter\nerr = c.Invoke(func(db *sql.DB) error {\n    return db.Ping()\n})\n```\n\nConstructors are **lazy** and **memoized**: each output type is built once and shared (singleton per container). `Provide` errors at registration if the constructor is malformed; `Invoke` returns the constructor's error wrapped with the dependency path that triggered it.\n\nA dig constructor is any function. Inputs are dependencies, outputs are provided types. `error` (last return) signals construction failure. Follow \"accept interfaces, return structs\".\n\n## Parameter Objects with `dig.In`\n\nOnce a constructor has 4+ dependencies, embed `dig.In` to group them as struct fields and tag fields:\n\n```go\ntype HandlerParams struct {\n    dig.In\n\n    Logger *zap.Logger\n    DB     *sql.DB\n    Cache  *redis.Client `optional:\"true\"`           \u002F\u002F zero value if not provided\n    DBRO   *sql.DB       `name:\"readonly\"`           \u002F\u002F named dependency\n    Routes []http.Handler `group:\"routes\"`           \u002F\u002F value group\n}\n\nfunc NewHandler(p HandlerParams) *Handler { \u002F* ... *\u002F }\n```\n\nTags: `name:\"...\"`, `optional:\"true\"`, `group:\"...\"`.\n\n## Result Objects with `dig.Out`\n\nReturn several values from one constructor and attach `name`\u002F`group` tags to results:\n\n```go\ntype ConnResult struct {\n    dig.Out\n\n    ReadWrite *sql.DB `name:\"primary\"`\n    ReadOnly  *sql.DB `name:\"readonly\"`\n}\n\nfunc NewConnections(cfg *Config) (ConnResult, error) { \u002F* ... *\u002F }\n```\n\n## Named Values\n\nTwo providers of the same type collide. Disambiguate with `dig.Name`:\n\n```go\nc.Provide(NewPrimaryDB,  dig.Name(\"primary\"))\nc.Provide(NewReadOnlyDB, dig.Name(\"readonly\"))\n```\n\nConsume by adding `name:\"primary\"` \u002F `name:\"readonly\"` to a `dig.In` field.\n\n## Value Groups\n\nMany providers, one consumer slice — typical for HTTP handlers, health checks, migrations:\n\n```go\ntype RouteResult struct {\n    dig.Out\n    Handler http.Handler `group:\"routes\"`\n}\n\nfunc NewUserHandler(db *sql.DB) RouteResult { \u002F* ... *\u002F }\nfunc NewPostHandler(db *sql.DB) RouteResult { \u002F* ... *\u002F }\n\ntype ServerParams struct {\n    dig.In\n    Routes []http.Handler `group:\"routes\"`\n}\n```\n\n**Flatten** — append `,flatten` (e.g. `group:\"routes,flatten\"`) to unwrap a slice instead of nesting it. Group order is **not guaranteed**; if order matters, provide an explicit ordered slice from a single constructor.\n\n## Provide as Interface (`dig.As`)\n\nRegister a concrete constructor and expose it under one or more interfaces without a separate adapter:\n\n```go\nc.Provide(NewPostgresDB, dig.As(new(Database), new(io.Closer)))\n\u002F\u002F Consumers ask for Database or io.Closer; *PostgresDB stays hidden.\n```\n\n## Full Application Example\n\n```go\nfunc main() {\n    c := dig.New()\n\n    must(c.Provide(NewConfig))\n    must(c.Provide(NewLogger))\n    must(c.Provide(NewDatabase))\n    must(c.Provide(NewServer))\n\n    err := c.Invoke(func(srv *http.Server) error {\n        return srv.ListenAndServe()\n    })\n    if err != nil {\n        log.Fatal(err)\n    }\n}\n\nfunc must(err error) { if err != nil { panic(err) } }\n```\n\ndig has **no built-in lifecycle**. If you need OnStart\u002FOnStop hooks, signal handling, and graceful shutdown, use fx — see `golang-uber-fx` skill.\n\nFor Decorate, Scopes, optional deps, error helpers, and Visualize, see [advanced.md](.\u002Freferences\u002Fadvanced.md).\n\n## Best Practices\n\n1. Keep the container at the composition root — never pass `*dig.Container` as a parameter; treat it like a plumbing detail of `main()`. Service-locator patterns defeat the testability gains of DI.\n2. Depend on interfaces, not concrete types — lets you swap implementations in tests without touching production code, and lets you use `dig.As` to expose narrow interfaces from wide structs.\n3. Prefer parameter objects (`dig.In` structs) once a constructor has 4+ dependencies — call sites stay readable and adding a new dependency is a one-line change instead of a signature break.\n4. Group registration by module (one file per module that calls `c.Provide` for its types) — review and refactoring become a per-module concern, and you can extract a module into a fx.Module later without rewriting wiring.\n5. Validate the graph eagerly in tests — call `c.Invoke` against the composition root in CI to surface missing providers at boot time, not at first request. `DryRun(true)` skips constructor execution.\n6. Return errors from constructors instead of panicking — dig wraps them with the dependency path, which makes the failure point obvious.\n\n## Common Mistakes\n\n| Mistake | Fix |\n| --- | --- |\n| Passing the container into services | The container belongs to `main()`. Inject the typed dependencies a service needs; otherwise tests need to build a real container. |\n| Two providers for the same type without `Name` | dig errors at `Provide` time. Either name them, or merge into a single provider that returns a `dig.Out` result struct. |\n| Ignoring `Provide` errors | Wrap each `Provide` with a `must` helper. A silent registration error becomes a missing-type error far later. |\n| Using groups when ordering matters | Groups are unordered. If order matters (middleware chain, migration sequence), provide an explicit ordered slice with one constructor. |\n| Constructors with side effects on import | Keep `init()` empty — start work only inside the constructor, after the graph is built. |\n\n## Testing\n\ndig containers are cheap — build a fresh one per test, override providers with `Decorate`, and call `Invoke` to drive the system. For full patterns (per-test wiring, shared helpers, graph validation in CI, asserting wire-time errors, recovering from constructor panics), see [testing.md](.\u002Freferences\u002Ftesting.md).\n\n## Further Reading\n\n- [advanced.md](.\u002Freferences\u002Fadvanced.md) — Decorate, Scopes, optional deps, error helpers, Visualize, full Quick Reference\n- [recipes.md](.\u002Freferences\u002Frecipes.md) — end-to-end examples: HTTP server with route group, two databases, request scopes, decorators, dry-run validation\n- [testing.md](.\u002Freferences\u002Ftesting.md) — testing patterns and graph validation\n\n## Cross-References\n\n- → See `golang-uber-fx` skill for application lifecycle, modules, and signal-aware Run() built on top of dig\n- → See `golang-dependency-injection` skill for DI concepts and library comparison\n- → See `golang-samber-do` skill for a generics-based alternative without reflection\n- → See `golang-google-wire` skill for compile-time DI (no runtime container)\n- → See `golang-structs-interfaces` skill for interface design patterns\n- → See `golang-testing` skill for general testing patterns\n\nIf you encounter a bug or unexpected behavior in uber-go\u002Fdig, open an issue at \u003Chttps:\u002F\u002Fgithub.com\u002Fuber-go\u002Fdig\u002Fissues>.\n",{"name":5,"paths":49,"license":15,"metadata":51,"description":7,"allowed-tools":62,"compatibility":63,"user-invocable":64},[50],"**\u002F*.go",{"author":52,"version":53,"openclaw":54},"samber","1.2.0",{"emoji":55,"install":56,"homepage":57,"requires":58,"skill-library-version":61},"⛏",[],"https:\u002F\u002Fgithub.com\u002Fsamber\u002Fcc-skills-golang",{"bins":59},[60],"go","1.19.0","Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs Bash(godig:*) Bash(gopls:*) LSP mcp__gopls__*","Designed for Claude Code, Codex or similar harness, and for projects using Golang.",true,"main","c349be0704bffe54a7191d1412faf564b08983ca","skills\u002Fsamber-golang\u002Fgolang-uber-dig",0,"https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills","https:\u002F\u002Fgithub.com\u002Frockcookies","2026-11-12 14:42:52",{"source":8,"skillName":5,"commands":73,"prompt":83,"zipAvailable":64},[74,77,80],{"tool":75,"command":76},"npx","npx skills add rockcookies\u002Fskills --skill golang-uber-dig",{"tool":78,"command":79},"bunx","bunx skills add rockcookies\u002Fskills --skill golang-uber-dig",{"tool":81,"command":82},"pnpm","pnpm dlx skills add rockcookies\u002Fskills --skill golang-uber-dig","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsamber-golang\u002Fgolang-uber-dig\u002FSKILL.md",[85,91,95,99],{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":90},"evals\u002Fevals.json","REFERENCE","参考文档",12359,"https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsamber-golang\u002Fgolang-uber-dig\u002Fevals\u002Fevals.json",{"path":92,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Fadvanced.md",4641,"https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsamber-golang\u002Fgolang-uber-dig\u002Freferences\u002Fadvanced.md",{"path":96,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Frecipes.md",6795,"https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsamber-golang\u002Fgolang-uber-dig\u002Freferences\u002Frecipes.md",{"path":100,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Ftesting.md",3616,"https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsamber-golang\u002Fgolang-uber-dig\u002Freferences\u002Ftesting.md",[104,128,144,167,178,192],{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":44},"01M6WMNKD3Y4H9FGM8Q901F507","hierarchical-agents-md","层级 AGENTS.md \u002F README.md：init、update、audit、reorganize、trim。 初始化 Agent 指令、代码改动后同步文档、检查文档漂移、重组仓库文档层级、精简规则与 Skills。 Not for 写业务代码或生成文档站点。","https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcustom\u002Fhierarchical-agents-md\u002FSKILL.md",[],[111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127],"hierarchical agents md","agents md","party","init","third-party","true","git","packages","change","maintenance","初始化","文档","audit","for","README","update","python",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":137,"publishedAt":44},"01M6CFS6BRTQPFZCDHQP97HYXR","vueuse-functions","Apply VueUse composables where appropriate to build concise, maintainable Vue.js \u002F Nuxt features.","https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fvueuse\u002Fvueuse-functions\u002FSKILL.md",[134],{"categoryNo":135,"categoryName":136,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[138,139,140,141,38,142,143,43],"functions","vueuse functions","js","vue","nuxt","build",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":154,"publishedAt":44},"01M6CFS34MDQXZPAWQFE5D7VGT","vue-testing-best-practices","Use for Vue.js testing. Covers Vitest, Vue Test Utils, component testing, mocking, testing patterns, and Playwright for E2E testing.","https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fvuejs-ai\u002Fvue-testing-best-practices\u002FSKILL.md",[150,153],{"categoryNo":151,"categoryName":152,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":135,"categoryName":136,"taxonomyType":21,"taxonomyTypeDesc":22},[155,141,156,157,158,159,160,161,162,163,43,164,165,166,140],"best practices","testing best practices","testing","vue testing best practices","e2e testing","playwright","test","testing patterns","component","vitest","e2e","use",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":174,"publishedAt":44},"01M6CFS0N19MSJNTVM9AEQ7Z73","vue-router-best-practices","Vue Router 4 patterns, navigation guards, route params, and route-component lifecycle interactions.","https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fvuejs-ai\u002Fvue-router-best-practices\u002FSKILL.md",[173],{"categoryNo":135,"categoryName":136,"taxonomyType":21,"taxonomyTypeDesc":22},[175,155,141,176,43,163,177,37],"vue router best practices","router","navigation",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":185,"publishedAt":44},"01M6CFRYN31RFQFTE41Z6DCGKE","vue-pinia-best-practices","Pinia stores, state management patterns, store setup, and reactivity with stores.","https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fvuejs-ai\u002Fvue-pinia-best-practices\u002FSKILL.md",[184],{"categoryNo":135,"categoryName":136,"taxonomyType":21,"taxonomyTypeDesc":22},[155,141,186,187,188,189,43,190,191],"vue pinia best practices","pinia","state","state management","management","setup",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":196,"categories":197,"keywords":207,"publishedAt":44},"01M6CFRW2DKXJHP05DYJ3P3Y2S","vue-options-api-best-practices","Vue 3 Options API style (data(), methods, this context). Each reference shows Options API solution only.","https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fvuejs-ai\u002Fvue-options-api-best-practices\u002FSKILL.md",[198,199,202],{"categoryNo":135,"categoryName":136,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":200,"categoryName":201,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":203,"categoryName":204,"taxonomyType":205,"taxonomyTypeDesc":206},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[141,155,208,209,210,211,212,43,213,214],"vue options api best practices","api","only","data","reference","methods","context"]