[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M79ANP9SHF0X2FATET02DFYA":3,"skill-same:01M79ANP9SHF0X2FATET02DFYA":92},{"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":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":47,"ownerDescription":6,"updatedAt":48,"install":49,"resources":61},"01M79ANP9SHF0X2FATET02DFYA","golang-dependency-management",null,"Dependency management strategies for Golang projects — go.mod management, installing\u002Fupgrading packages, Minimal Version Selection, vulnerability scanning, outdated dependency tracking, binary size analysis, Dependabot\u002FRenovate setup, conflict resolution, and go.work workspaces. Use when adding, removing, or upgrading Go dependencies, auditing vulnerabilities, resolving version conflicts, or setting up automated dependency updates.","CCH-HQ\u002Fcchp-automation","CCH-HQ","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F253065381?v=4","01M79AG9QPRTJEVTCT1ZS7TM9J","CCH HQ","01M79AG9RNM4TAB3PJQH71X62P",2,"MIT","https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fgolang-dependency-management\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: golang-dependency-management\ndescription: \"Dependency management strategies for Golang projects — go.mod management, installing\u002Fupgrading packages, Minimal Version Selection, vulnerability scanning, outdated dependency tracking, binary size analysis, Dependabot\u002FRenovate setup, conflict resolution, and go.work workspaces. Use when adding, removing, or upgrading Go dependencies, auditing vulnerabilities, resolving version conflicts, or setting up automated dependency updates.\"\nuser-invocable: true\nlicense: MIT\ncompatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.\nmetadata:\n  author: samber\n  version: \"1.2.4\"\n  openclaw:\n    emoji: \"📦\"\n    homepage: https:\u002F\u002Fgithub.com\u002Fsamber\u002Fcc-skills-golang\n    requires:\n      bins:\n        - go\n        - govulncheck\n    install:\n      - kind: go\n        package: golang.org\u002Fx\u002Fvuln\u002Fcmd\u002Fgovulncheck@latest\n        bins: [govulncheck]\nallowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent Bash(govulncheck:*) AskUserQuestion\n---\n\n**Persona:** You are a Go dependency steward. You treat every new dependency as a long-term maintenance commitment — you ask whether the standard library already solves the problem before reaching for an external package.\n\n**Dependencies:**\n\n- govulncheck: `go install golang.org\u002Fx\u002Fvuln\u002Fcmd\u002Fgovulncheck@latest`\n\n# Go Dependency Management\n\n## AI Agent Rule: Ask Before Adding Dependencies\n\n**Before running `go get` to add any new dependency, AI agents MUST ask the user for confirmation.** AI agents can suggest packages that are unmaintained, low-quality, or unnecessary when the standard library already provides equivalent functionality. Using `go get -u` to upgrade an existing dependency is safe.\n\nBefore proposing a dependency, evaluate:\n\n- Does the standard library already cover the use case?\n- Is the license compatible?\n- Are there well-known alternatives?\n- What it does and why it's needed?\n\nThe `samber\u002Fcc-skills-golang@golang-popular-libraries` skill contains a curated list of vetted, production-ready libraries. Prefer recommending packages from that list. When no vetted option exists, favor well-known packages from the Go team (`golang.org\u002Fx\u002F...`) or established organizations over obscure alternatives.\n\n## Key Rules\n\n- `go.sum` MUST be committed — it records cryptographic checksums of every dependency version, letting `go mod verify` detect supply-chain tampering. Without it, a compromised proxy could silently substitute malicious code\n- `govulncheck .\u002F...` or `go tool govulncheck .\u002F...` before every release — catches known CVEs in your dependency tree before they reach production\n- Maintenance status, license compatibility, and stdlib alternatives are important considerations before adding a dependency — every dependency increases attack surface, maintenance burden, and binary size\n- `go mod tidy` before every commit that changes dependencies — removes unused modules and adds missing ones, keeping go.mod honest\n\n## go.mod & go.sum\n\n### Essential Commands\n\n| Command           | Purpose                                      |\n| ----------------- | -------------------------------------------- |\n| `go mod tidy`     | Add missing deps, remove unused ones         |\n| `go mod download` | Download modules to local cache              |\n| `go mod verify`   | Verify cached modules match go.sum checksums |\n| `go mod vendor`   | Copy deps into `vendor\u002F` directory           |\n| `go mod edit`     | Edit go.mod programmatically (scripts, CI)   |\n| `go mod graph`    | Print the module requirement graph           |\n| `go mod why`      | Explain why a module or package is needed    |\n\n### Vendoring\n\nUse `go mod vendor` when you need hermetic builds (no network access), reproducibility guarantees beyond checksums, or when deploying to environments without module proxy access. CI pipelines and Docker builds sometimes benefit from vendoring. Run `go mod vendor` after any dependency change and commit the `vendor\u002F` directory.\n\n## Installing & Upgrading Dependencies\n\n### Adding a Dependency\n\n```bash\ngo get github.com\u002Fgoogle\u002Fuuid          # Latest version\ngo get github.com\u002Fgoogle\u002Fuuid@v1.6.0   # Specific version\ngo get github.com\u002Fgoogle\u002Fuuid@latest   # Explicitly latest\ngo get github.com\u002Fgoogle\u002Fuuid@\u003Ccommit> # Specific commit (pseudo-version)\n```\n\nBefore pinning a version, inspect the module's available versions, importers, and known vulnerabilities on pkg.go.dev → See `samber\u002Fcc-skills-golang@golang-pkg-go-dev` skill.\n\n### Upgrading\n\n```bash\ngo get -u .\u002F...            # Upgrade ALL direct+indirect deps to latest minor\u002Fpatch\ngo get -u=patch .\u002F...      # Upgrade to latest patch only (safer)\ngo get github.com\u002Fpkg@v1.5 # Upgrade specific package\n```\n\n**Prefer `go get -u=patch`** for routine updates. Patch and minor updates are usually lower risk than major upgrades, but still require review. For dependency updates, run:\n\n```bash\ngo get -u=patch .\u002F...\ngo mod tidy\ngo test .\u002F...\ngo vet .\u002F...\ngovulncheck .\u002F...   # or: go tool govulncheck .\u002F...\n```\n\nRelease notes and changelogs for libraries affecting persistence, serialization, networking, authentication, authorization, cryptography, or public APIs may contain important information about breaking changes.\n\n### Removing a Dependency\n\n```bash\ngo get github.com\u002Fgoogle\u002Fuuid@none  # Mark for removal\ngo mod tidy                          # Clean up go.mod and go.sum\n```\n\n### Installing CLI Tools\n\nFor Go 1.24+ modules, pin executable tools in `go.mod` with `tool` directives. Do not create a new `tools.go` blank-import file unless the module must support Go \u003C1.24.\n\n```bash\n# Add tools to the current module.\ngo get -tool github.com\u002Fgolangci\u002Fgolangci-lint\u002Fv2\u002Fcmd\u002Fgolangci-lint@latest\ngo get -tool golang.org\u002Fx\u002Fvuln\u002Fcmd\u002Fgovulncheck@latest\ngo get -tool golang.org\u002Fx\u002Fperf\u002Fcmd\u002Fbenchstat@latest\n\n# Run pinned tools reproducibly.\ngo tool golangci-lint run .\u002F...\ngo tool govulncheck .\u002F...\ngo tool benchstat old.txt new.txt\n\n# Install all module-pinned tools into GOBIN\u002FPATH when needed.\ngo install tool\n\n# Update pinned tools deliberately, then review go.mod\u002Fgo.sum.\ngo get -u tool\ngo mod tidy\n```\n\n`go.mod` shape for a module targeting Go 1.26 or newer. This is an example target, not a cap; keep the project's actual `go` directive and do not change it just to add tools.\n\n```go.mod\nmodule example.com\u002Fproject\n\ngo 1.26\n\ntool (\n    github.com\u002Fgolangci\u002Fgolangci-lint\u002Fv2\u002Fcmd\u002Fgolangci-lint\n    golang.org\u002Fx\u002Fvuln\u002Fcmd\u002Fgovulncheck\n    golang.org\u002Fx\u002Fperf\u002Fcmd\u002Fbenchstat\n)\n```\n\nFor Go \u003C1.24 only, use the legacy `tools.go` blank-import workaround:\n\n```go\n\u002F\u002Fgo:build tools\n\npackage tools\n\nimport (\n    _ \"github.com\u002Fgolangci\u002Fgolangci-lint\u002Fv2\u002Fcmd\u002Fgolangci-lint\"\n    _ \"golang.org\u002Fx\u002Fvuln\u002Fcmd\u002Fgovulncheck\"\n)\n```\n\nRule: Go 1.24+ = `tool` directives. Go \u003C1.24 = `tools.go` fallback.\n\n### Go 1.26+ module target note\n\nWhen using a Go 1.26 or newer toolchain, `go mod init` may create a module with an older default `go` directive. If the project intentionally targets Go 1.26+ APIs, update the directive deliberately:\n\n```bash\ngo mod edit -go=1.26\ngo mod tidy\n```\n\nFor future Go versions, use the project's intended target version. Do not use APIs newer than the module's `go` directive until the project explicitly agrees to upgrade it.\n\n## Deep Dives\n\n- **[Versioning & MVS](.\u002Freferences\u002Fversioning.md)** — Semantic versioning rules (major.minor.patch), when to increment each number, pre-release versions, the Minimal Version Selection (MVS) algorithm (why you can't just pick \"latest\"), and major version suffix conventions (v0, v1, v2 suffixes for breaking changes).\n\n- **[Auditing Dependencies](.\u002Freferences\u002Fauditing.md)** — Vulnerability scanning with `govulncheck`, tracking outdated dependencies, analyzing which dependencies make the binary large (`goweight`), and distinguishing test-only vs binary dependencies to keep `go.mod` clean.\n\n- **[Dependency Conflicts & Resolution](.\u002Freferences\u002Fconflicts.md)** — Diagnosing version conflicts (what `go get` does when you request incompatible versions), resolution strategies (`replace` directives for local development, `exclude` for broken versions, `retract` for published versions that should be skipped), and workflows for conflicts across your dependency tree.\n\n- **[Go Workspaces](.\u002Freferences\u002Fworkspaces.md)** — `go.work` files for multi-module development (e.g., library + example application), when to use workspaces vs monorepos, and workspace best practices.\n\n- **[Automated Dependency Updates](.\u002Freferences\u002Fautomated-updates.md)** — Setting up Dependabot or Renovate for automatic dependency update PRs, auto-merge strategies (when to merge automatically vs require review), and handling security updates.\n\n- **[Visualizing the Dependency Graph](.\u002Freferences\u002Fvisualization.md)** — `go mod graph` to inspect the full dependency tree, `modgraphviz` to visualize it, and interactive tools to find which dependency chains cause bloat.\n\n## Cross-References\n\n- → See `samber\u002Fcc-skills-golang@golang-continuous-integration` skill for Dependabot\u002FRenovate CI setup\n- → See `samber\u002Fcc-skills-golang@golang-security` skill for vulnerability scanning with govulncheck\n- → See `samber\u002Fcc-skills-golang@golang-popular-libraries` skill for vetted library recommendations\n\n## Quick Reference\n\n```bash\n# Start a new module\ngo mod init github.com\u002Fuser\u002Fproject\n\n# Add a dependency\ngo get github.com\u002Fgoogle\u002Fuuid@v1.6.0\n\n# Upgrade all deps (patch only, safer)\ngo get -u=patch .\u002F...\n\n# Remove unused deps\ngo mod tidy\n\n# Check for vulnerabilities\ngovulncheck .\u002F...   # or: go tool govulncheck .\u002F...\n\n# Check for outdated deps\ngo list -u -m -json all | go-mod-outdated -update -direct\n\n# Analyze binary size by dependency\ngoweight\n\n# Understand why a dep exists\ngo mod why -m github.com\u002Fsome\u002Fmodule\n\n# Visualize dependency graph\ngo mod graph | modgraphviz | dot -Tpng -o deps.png\n\n# Verify checksums\ngo mod verify\n```\n","**Persona:** You are a Go dependency steward. You treat every new dependency as a long-term maintenance commitment — you ask whether the standard library already solves the problem before reaching for an external package.\n\n**Dependencies:**\n\n- govulncheck: `go install golang.org\u002Fx\u002Fvuln\u002Fcmd\u002Fgovulncheck@latest`\n\n# Go Dependency Management\n\n## AI Agent Rule: Ask Before Adding Dependencies\n\n**Before running `go get` to add any new dependency, AI agents MUST ask the user for confirmation.** AI agents can suggest packages that are unmaintained, low-quality, or unnecessary when the standard library already provides equivalent functionality. Using `go get -u` to upgrade an existing dependency is safe.\n\nBefore proposing a dependency, evaluate:\n\n- Does the standard library already cover the use case?\n- Is the license compatible?\n- Are there well-known alternatives?\n- What it does and why it's needed?\n\nThe `samber\u002Fcc-skills-golang@golang-popular-libraries` skill contains a curated list of vetted, production-ready libraries. Prefer recommending packages from that list. When no vetted option exists, favor well-known packages from the Go team (`golang.org\u002Fx\u002F...`) or established organizations over obscure alternatives.\n\n## Key Rules\n\n- `go.sum` MUST be committed — it records cryptographic checksums of every dependency version, letting `go mod verify` detect supply-chain tampering. Without it, a compromised proxy could silently substitute malicious code\n- `govulncheck .\u002F...` or `go tool govulncheck .\u002F...` before every release — catches known CVEs in your dependency tree before they reach production\n- Maintenance status, license compatibility, and stdlib alternatives are important considerations before adding a dependency — every dependency increases attack surface, maintenance burden, and binary size\n- `go mod tidy` before every commit that changes dependencies — removes unused modules and adds missing ones, keeping go.mod honest\n\n## go.mod & go.sum\n\n### Essential Commands\n\n| Command           | Purpose                                      |\n| ----------------- | -------------------------------------------- |\n| `go mod tidy`     | Add missing deps, remove unused ones         |\n| `go mod download` | Download modules to local cache              |\n| `go mod verify`   | Verify cached modules match go.sum checksums |\n| `go mod vendor`   | Copy deps into `vendor\u002F` directory           |\n| `go mod edit`     | Edit go.mod programmatically (scripts, CI)   |\n| `go mod graph`    | Print the module requirement graph           |\n| `go mod why`      | Explain why a module or package is needed    |\n\n### Vendoring\n\nUse `go mod vendor` when you need hermetic builds (no network access), reproducibility guarantees beyond checksums, or when deploying to environments without module proxy access. CI pipelines and Docker builds sometimes benefit from vendoring. Run `go mod vendor` after any dependency change and commit the `vendor\u002F` directory.\n\n## Installing & Upgrading Dependencies\n\n### Adding a Dependency\n\n```bash\ngo get github.com\u002Fgoogle\u002Fuuid          # Latest version\ngo get github.com\u002Fgoogle\u002Fuuid@v1.6.0   # Specific version\ngo get github.com\u002Fgoogle\u002Fuuid@latest   # Explicitly latest\ngo get github.com\u002Fgoogle\u002Fuuid@\u003Ccommit> # Specific commit (pseudo-version)\n```\n\nBefore pinning a version, inspect the module's available versions, importers, and known vulnerabilities on pkg.go.dev → See `samber\u002Fcc-skills-golang@golang-pkg-go-dev` skill.\n\n### Upgrading\n\n```bash\ngo get -u .\u002F...            # Upgrade ALL direct+indirect deps to latest minor\u002Fpatch\ngo get -u=patch .\u002F...      # Upgrade to latest patch only (safer)\ngo get github.com\u002Fpkg@v1.5 # Upgrade specific package\n```\n\n**Prefer `go get -u=patch`** for routine updates. Patch and minor updates are usually lower risk than major upgrades, but still require review. For dependency updates, run:\n\n```bash\ngo get -u=patch .\u002F...\ngo mod tidy\ngo test .\u002F...\ngo vet .\u002F...\ngovulncheck .\u002F...   # or: go tool govulncheck .\u002F...\n```\n\nRelease notes and changelogs for libraries affecting persistence, serialization, networking, authentication, authorization, cryptography, or public APIs may contain important information about breaking changes.\n\n### Removing a Dependency\n\n```bash\ngo get github.com\u002Fgoogle\u002Fuuid@none  # Mark for removal\ngo mod tidy                          # Clean up go.mod and go.sum\n```\n\n### Installing CLI Tools\n\nFor Go 1.24+ modules, pin executable tools in `go.mod` with `tool` directives. Do not create a new `tools.go` blank-import file unless the module must support Go \u003C1.24.\n\n```bash\n# Add tools to the current module.\ngo get -tool github.com\u002Fgolangci\u002Fgolangci-lint\u002Fv2\u002Fcmd\u002Fgolangci-lint@latest\ngo get -tool golang.org\u002Fx\u002Fvuln\u002Fcmd\u002Fgovulncheck@latest\ngo get -tool golang.org\u002Fx\u002Fperf\u002Fcmd\u002Fbenchstat@latest\n\n# Run pinned tools reproducibly.\ngo tool golangci-lint run .\u002F...\ngo tool govulncheck .\u002F...\ngo tool benchstat old.txt new.txt\n\n# Install all module-pinned tools into GOBIN\u002FPATH when needed.\ngo install tool\n\n# Update pinned tools deliberately, then review go.mod\u002Fgo.sum.\ngo get -u tool\ngo mod tidy\n```\n\n`go.mod` shape for a module targeting Go 1.26 or newer. This is an example target, not a cap; keep the project's actual `go` directive and do not change it just to add tools.\n\n```go.mod\nmodule example.com\u002Fproject\n\ngo 1.26\n\ntool (\n    github.com\u002Fgolangci\u002Fgolangci-lint\u002Fv2\u002Fcmd\u002Fgolangci-lint\n    golang.org\u002Fx\u002Fvuln\u002Fcmd\u002Fgovulncheck\n    golang.org\u002Fx\u002Fperf\u002Fcmd\u002Fbenchstat\n)\n```\n\nFor Go \u003C1.24 only, use the legacy `tools.go` blank-import workaround:\n\n```go\n\u002F\u002Fgo:build tools\n\npackage tools\n\nimport (\n    _ \"github.com\u002Fgolangci\u002Fgolangci-lint\u002Fv2\u002Fcmd\u002Fgolangci-lint\"\n    _ \"golang.org\u002Fx\u002Fvuln\u002Fcmd\u002Fgovulncheck\"\n)\n```\n\nRule: Go 1.24+ = `tool` directives. Go \u003C1.24 = `tools.go` fallback.\n\n### Go 1.26+ module target note\n\nWhen using a Go 1.26 or newer toolchain, `go mod init` may create a module with an older default `go` directive. If the project intentionally targets Go 1.26+ APIs, update the directive deliberately:\n\n```bash\ngo mod edit -go=1.26\ngo mod tidy\n```\n\nFor future Go versions, use the project's intended target version. Do not use APIs newer than the module's `go` directive until the project explicitly agrees to upgrade it.\n\n## Deep Dives\n\n- **[Versioning & MVS](.\u002Freferences\u002Fversioning.md)** — Semantic versioning rules (major.minor.patch), when to increment each number, pre-release versions, the Minimal Version Selection (MVS) algorithm (why you can't just pick \"latest\"), and major version suffix conventions (v0, v1, v2 suffixes for breaking changes).\n\n- **[Auditing Dependencies](.\u002Freferences\u002Fauditing.md)** — Vulnerability scanning with `govulncheck`, tracking outdated dependencies, analyzing which dependencies make the binary large (`goweight`), and distinguishing test-only vs binary dependencies to keep `go.mod` clean.\n\n- **[Dependency Conflicts & Resolution](.\u002Freferences\u002Fconflicts.md)** — Diagnosing version conflicts (what `go get` does when you request incompatible versions), resolution strategies (`replace` directives for local development, `exclude` for broken versions, `retract` for published versions that should be skipped), and workflows for conflicts across your dependency tree.\n\n- **[Go Workspaces](.\u002Freferences\u002Fworkspaces.md)** — `go.work` files for multi-module development (e.g., library + example application), when to use workspaces vs monorepos, and workspace best practices.\n\n- **[Automated Dependency Updates](.\u002Freferences\u002Fautomated-updates.md)** — Setting up Dependabot or Renovate for automatic dependency update PRs, auto-merge strategies (when to merge automatically vs require review), and handling security updates.\n\n- **[Visualizing the Dependency Graph](.\u002Freferences\u002Fvisualization.md)** — `go mod graph` to inspect the full dependency tree, `modgraphviz` to visualize it, and interactive tools to find which dependency chains cause bloat.\n\n## Cross-References\n\n- → See `samber\u002Fcc-skills-golang@golang-continuous-integration` skill for Dependabot\u002FRenovate CI setup\n- → See `samber\u002Fcc-skills-golang@golang-security` skill for vulnerability scanning with govulncheck\n- → See `samber\u002Fcc-skills-golang@golang-popular-libraries` skill for vetted library recommendations\n\n## Quick Reference\n\n```bash\n# Start a new module\ngo mod init github.com\u002Fuser\u002Fproject\n\n# Add a dependency\ngo get github.com\u002Fgoogle\u002Fuuid@v1.6.0\n\n# Upgrade all deps (patch only, safer)\ngo get -u=patch .\u002F...\n\n# Remove unused deps\ngo mod tidy\n\n# Check for vulnerabilities\ngovulncheck .\u002F...   # or: go tool govulncheck .\u002F...\n\n# Check for outdated deps\ngo list -u -m -json all | go-mod-outdated -update -direct\n\n# Analyze binary size by dependency\ngoweight\n\n# Understand why a dep exists\ngo mod why -m github.com\u002Fsome\u002Fmodule\n\n# Visualize dependency graph\ngo mod graph | modgraphviz | dot -Tpng -o deps.png\n\n# Verify checksums\ngo mod verify\n```\n",{"name":5,"license":15,"metadata":24,"description":7,"allowed-tools":38,"compatibility":39,"user-invocable":40},{"author":25,"version":26,"openclaw":27},"samber","1.2.4",{"emoji":28,"install":29,"homepage":35,"requires":36},"📦",[30],{"bins":31,"kind":33,"package":34},[32],"govulncheck","go","golang.org\u002Fx\u002Fvuln\u002Fcmd\u002Fgovulncheck@latest","https:\u002F\u002Fgithub.com\u002Fsamber\u002Fcc-skills-golang",{"bins":37},[33,32],"Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent Bash(govulncheck:*) AskUserQuestion","Designed for Claude Code or similar AI coding agents, and for projects using Golang.",true,"main","a93764baed707eda5a68d91e19e5719368e6335e","skills-backup\u002Fskills\u002Fgolang-dependency-management",0,"https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation","https:\u002F\u002Fgithub.com\u002FCCH-HQ","https:\u002F\u002Fclaude-code-hub.app\u002F","2026-11-09 20:50:54",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":40},[51,54,57],{"tool":52,"command":53},"npx","npx skills add CCH-HQ\u002Fcchp-automation --skill golang-dependency-management",{"tool":55,"command":56},"bunx","bunx skills add CCH-HQ\u002Fcchp-automation --skill golang-dependency-management",{"tool":58,"command":59},"pnpm","pnpm dlx skills add CCH-HQ\u002Fcchp-automation --skill golang-dependency-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fgolang-dependency-management\u002FSKILL.md",[62,68,72,76,80,84,88],{"path":63,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":66,"sourceHtmlUrl":67},"evals\u002Fevals.json","REFERENCE","参考文档",11487,"https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fgolang-dependency-management\u002Fevals\u002Fevals.json",{"path":69,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":70,"sourceHtmlUrl":71},"references\u002Fauditing.md",3511,"https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fgolang-dependency-management\u002Freferences\u002Fauditing.md",{"path":73,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Fautomated-updates.md",1876,"https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fgolang-dependency-management\u002Freferences\u002Fautomated-updates.md",{"path":77,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fconflicts.md",2101,"https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fgolang-dependency-management\u002Freferences\u002Fconflicts.md",{"path":81,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fversioning.md",2747,"https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fgolang-dependency-management\u002Freferences\u002Fversioning.md",{"path":85,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Fvisualization.md",1440,"https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fgolang-dependency-management\u002Freferences\u002Fvisualization.md",{"path":89,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Fworkspaces.md",1227,"https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fgolang-dependency-management\u002Freferences\u002Fworkspaces.md",[93,100,107,114,121,128],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":19},"01M79B44RKSB6Z0GENGYFCCZYA","writing-skills","Use when creating new skills, editing existing skills, or verifying skills work before deployment","https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[],[],{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":19},"01M79B410BHDSNHZ7MKAYXWJHS","writing-plans","Use when you have a spec or requirements for a multi-step task, before touching code","https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fwriting-plans\u002FSKILL.md",[],[],{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":19},"01M79B3XK29MCD5HGD50YGYXQZ","wizard","Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.","https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fwizard\u002FSKILL.md",[],[],{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":19},"01M79B3TFQEXXM2KK5V44H64DV","wayfinder","Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.","https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fwayfinder\u002FSKILL.md",[],[],{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":19},"01M79B3Q3WTMJDM6NNGG1X4NYK","verification-before-completion","Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always","https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[],[],{"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":134,"publishedAt":19},"01M79B3GW8YCKT7W489HKWFMNC","vercel-react-best-practices","React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React\u002FNext.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.","https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fvercel-react-best-practices\u002FSKILL.md",[],[]]