[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CFH0E55860CF7HRED0TQGD":3,"skill-same:01M6CFH0E55860CF7HRED0TQGD":105},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":62,"repositoryHtmlUrl":63,"repositoryHomepageUrl":6,"ownerHtmlUrl":64,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":65,"install":66,"resources":78},"01M6CFH0E55860CF7HRED0TQGD","golang-concurrency",null,"Golang concurrency patterns. Use when writing or reviewing concurrent Go code involving goroutines, channels, select, locks, sync primitives, errgroup, singleflight, worker pools, or fan-out\u002Ffan-in pipelines. Also triggers when you detect goroutine leaks, race conditions, channel ownership issues, or need to choose between channels and mutexes.","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-concurrency\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"concurrency","golang concurrency","golang","Bash","github","use","edit","write","read","choose","select","projects","sync","writing","https","codex","harness","issues","code","lint","2026-11-10 10:12:30",false,"---\nname: golang-concurrency\ndescription: >-\n  Golang concurrency patterns. Use when writing or reviewing concurrent Go code\n  involving goroutines, channels, select, locks, sync primitives, errgroup,\n  singleflight, worker pools, or fan-out\u002Ffan-in pipelines. Also triggers when\n  you detect goroutine leaks, race conditions, channel ownership issues, or need\n  to choose between channels and mutexes.\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: []\nallowed-tools: >-\n  Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent\n  AskUserQuestion\npaths:\n  - '**\u002F*.go'\n---\n\n**Persona:** You are a Go concurrency engineer. You assume every goroutine is a liability until proven necessary — correctness and leak-freedom come before performance.\n\n**Orchestration mode:** Fan out the five sub-agents described in the \"Parallelizing Concurrency Audits\" section for auditing concurrent code across a large codebase, and consolidate their findings into one report. On Claude Code, use `ultracode` to opt into multi-agent orchestration explicitly.\n\n**Modes:**\n\n- **Write mode** — implement concurrent code (goroutines, channels, sync primitives, worker pools, pipelines). Follow the sequential instructions below.\n- **Review mode** — reviewing a PR's concurrent code changes. Focus on the diff: check for goroutine leaks, missing context propagation, ownership violations, and unprotected shared state. Sequential.\n- **Audit mode** — auditing existing concurrent code across a codebase. Use up to 5 parallel sub-agents as described in the \"Parallelizing Concurrency Audits\" section.\n\n> **Community default.** A company skill that explicitly supersedes `golang-concurrency` skill takes precedence.\n\n# Go Concurrency Best Practices\n\nGo's concurrency model is built on goroutines and channels. Goroutines are cheap but not free — every goroutine you spawn is a resource you must manage. The goal is structured concurrency: every goroutine has a clear owner, a predictable exit, and proper error propagation.\n\n## Core Principles\n\n1. **Every goroutine must have a clear exit** — without a shutdown mechanism (context, done channel, WaitGroup), they leak and accumulate until the process crashes\n2. **Share memory by communicating** — channels transfer ownership explicitly; mutexes protect shared state but make ownership implicit\n3. **Send copies, not pointers** on channels — sending pointers creates invisible shared memory, defeating the purpose of channels\n4. **Only the sender closes a channel** — closing from the receiver side panics if the sender writes after close\n5. **Specify channel direction** (`chan\u003C-`, `\u003C-chan`) — the compiler prevents misuse at build time\n6. **Default to unbuffered channels** — larger buffers mask backpressure; use them only with measured justification\n7. **Always include `ctx.Done()` in select** — without it, goroutines leak after caller cancellation\n8. **Avoid repeated `time.After` in hot loops** — each call allocates a timer and creates unnecessary churn; use `time.NewTimer` + `Reset` for long-running loops\n9. **Track goroutine leaks in tests** with `go.uber.org\u002Fgoleak`\n\nFor detailed channel\u002Fselect code examples, see [Channels and Select Patterns](references\u002Fchannels-and-select.md).\n\n## Channel vs Mutex vs Atomic\n\n| Scenario | Use | Why |\n| --- | --- | --- |\n| Passing data between goroutines | Channel | Communicates ownership transfer |\n| Coordinating goroutine lifecycle | Channel + context | Clean shutdown with select |\n| Protecting shared struct fields | `sync.Mutex` \u002F `sync.RWMutex` | Simple critical sections |\n| Simple counters, flags | `sync\u002Fatomic` | Lock-free, lower overhead |\n| Many readers, few writers on a map | `sync.Map` | Optimized for read-heavy workloads. **Concurrent map read\u002Fwrite causes a hard crash** |\n| Caching expensive computations | `sync.Once` \u002F `singleflight` | Execute once or deduplicate |\n\n## WaitGroup vs errgroup\n\n| Need | Use | Why |\n| --- | --- | --- |\n| Wait for goroutines, errors not needed | `sync.WaitGroup` | Fire-and-forget |\n| Wait + collect first error | `errgroup.Group` | Error propagation |\n| Wait + cancel siblings on first error | `errgroup.WithContext` | Context cancellation on error |\n| Wait + limit concurrency | `errgroup.SetLimit(n)` | Built-in worker pool |\n\n## Sync Primitives Quick Reference\n\n| Primitive | Use case | Key notes |\n| --- | --- | --- |\n| `sync.Mutex` | Protect shared state | Keep critical sections short; never hold across I\u002FO |\n| `sync.RWMutex` | Many readers, few writers | Never upgrade RLock to Lock (deadlock) |\n| `sync\u002Fatomic` | Simple counters, flags | Prefer typed atomics (Go 1.19+): `atomic.Int64`, `atomic.Bool` |\n| `sync.Map` | Concurrent map, read-heavy | No explicit locking; use `RWMutex`+map when writes dominate |\n| `sync.Pool` | Reuse temporary objects | Always `Reset()` before `Put()`; reduces GC pressure |\n| `sync.Once` | One-time initialization | Go 1.21+: `OnceFunc`, `OnceValue`, `OnceValues` |\n| `sync.WaitGroup` | Waiting for simple goroutines | Go 1.25+: prefer `wg.Go(func(){ ... })` for fire-and-wait tasks that do not panic and do not need error propagation. For Go \u003C1.25 use `Add`\u002F`Done`. For errors\u002Fcancellation\u002Flimits, use `errgroup` with context. |\n| `x\u002Fsync\u002Fsingleflight` | Deduplicate concurrent calls | Cache stampede prevention |\n| `x\u002Fsync\u002Ferrgroup` | Goroutine group + errors | `SetLimit(n)` replaces hand-rolled worker pools |\n\nFor detailed examples and anti-patterns, see [Sync Primitives Deep Dive](references\u002Fsync-primitives.md).\n\n## Concurrency Checklist\n\nBefore spawning a goroutine, answer:\n\n- [ ] **How will it exit?** — context cancellation, channel close, or explicit signal\n- [ ] **Can I signal it to stop?** — pass `context.Context` or done channel\n- [ ] **Can I wait for it?** — `sync.WaitGroup` or `errgroup`\n- [ ] **Who owns the channels?** — creator\u002Fsender owns and closes\n- [ ] **Should this be synchronous instead?** — don't add concurrency without measured need\n\n## Pipelines and Worker Pools\n\nFor pipeline patterns (fan-out\u002Ffan-in, bounded workers, generator chains, Go 1.23+ iterators, `samber\u002Fro`), see [Pipelines and Worker Pools](references\u002Fpipelines.md).\n\n## Parallelizing Concurrency Audits\n\nWhen auditing concurrency across a large codebase, use up to 5 parallel sub-agents:\n\n1. Find all goroutine spawns (`go func`, `go method`) and verify shutdown mechanisms\n2. Search for mutable globals and shared state without synchronization\n3. Audit channel usage — ownership, direction, closure, buffer sizes\n4. Find `time.After` in loops, missing `ctx.Done()` in select, unbounded spawning\n5. Check mutex usage, `sync.Map`, atomics, and thread-safety documentation\n\n## Common Mistakes\n\n| Mistake | Fix |\n| --- | --- |\n| Fire-and-forget goroutine | Provide stop mechanism (context, done channel) |\n| Closing channel from receiver | Only the sender closes |\n| `time.After` in hot loop | Reuse `time.NewTimer` + `Reset` |\n| Missing `ctx.Done()` in select | Always select on context to allow cancellation |\n| Unbounded goroutine spawning | Use `errgroup.SetLimit(n)` or semaphore |\n| Sharing pointer via channel | Send copies or immutable values |\n| `wg.Add` inside goroutine | Call `Add` before `go` — `Wait` may return early otherwise |\n| Forgetting `-race` in CI | Always run `go test -race .\u002F...` |\n| Mutex held across I\u002FO | Keep critical sections short |\n\n## Cross-References\n\n- -> See `golang-performance` skill for false sharing, cache-line padding, `sync.Pool` hot-path patterns\n- -> See `golang-context` skill for cancellation propagation and timeout patterns\n- -> See `golang-safety` skill for concurrent map access and race condition prevention\n- -> See `golang-troubleshooting` skill for debugging goroutine leaks and deadlocks\n- -> See `golang-design-patterns` skill for graceful shutdown patterns\n- -> See `golang-continuous-integration` skill for automated AI-driven code review in CI using these guidelines\n\n### Go 1.26 experimental goroutine leak profile\n\nFor Go 1.26 diagnostics, there is an experimental goroutine leak profile. It is useful for production-oriented leak investigation, but is gated by `GOEXPERIMENT=goroutineleakprofile`; do not rely on it as default stable behavior.\n\nTypical usage when the experiment is enabled:\n\n```bash\ncurl http:\u002F\u002Flocalhost:6060\u002Fdebug\u002Fpprof\u002Fgoroutineleak?debug=2\ngo tool pprof http:\u002F\u002Flocalhost:6060\u002Fdebug\u002Fpprof\u002Fgoroutineleak\n```\n\nKeep existing tools:\n\n- tests: `go.uber.org\u002Fgoleak`\n- runtime count: `runtime.NumGoroutine()`\n- stack dump: `\u002Fdebug\u002Fpprof\u002Fgoroutine?debug=2`\n- race checks: `go test -race .\u002F...`\n\n## References\n\n- [Go Concurrency Patterns: Pipelines](https:\u002F\u002Fgo.dev\u002Fblog\u002Fpipelines)\n- [Effective Go: Concurrency](https:\u002F\u002Fgo.dev\u002Fdoc\u002Feffective_go#concurrency)\n","**Persona:** You are a Go concurrency engineer. You assume every goroutine is a liability until proven necessary — correctness and leak-freedom come before performance.\n\n**Orchestration mode:** Fan out the five sub-agents described in the \"Parallelizing Concurrency Audits\" section for auditing concurrent code across a large codebase, and consolidate their findings into one report. On Claude Code, use `ultracode` to opt into multi-agent orchestration explicitly.\n\n**Modes:**\n\n- **Write mode** — implement concurrent code (goroutines, channels, sync primitives, worker pools, pipelines). Follow the sequential instructions below.\n- **Review mode** — reviewing a PR's concurrent code changes. Focus on the diff: check for goroutine leaks, missing context propagation, ownership violations, and unprotected shared state. Sequential.\n- **Audit mode** — auditing existing concurrent code across a codebase. Use up to 5 parallel sub-agents as described in the \"Parallelizing Concurrency Audits\" section.\n\n> **Community default.** A company skill that explicitly supersedes `golang-concurrency` skill takes precedence.\n\n# Go Concurrency Best Practices\n\nGo's concurrency model is built on goroutines and channels. Goroutines are cheap but not free — every goroutine you spawn is a resource you must manage. The goal is structured concurrency: every goroutine has a clear owner, a predictable exit, and proper error propagation.\n\n## Core Principles\n\n1. **Every goroutine must have a clear exit** — without a shutdown mechanism (context, done channel, WaitGroup), they leak and accumulate until the process crashes\n2. **Share memory by communicating** — channels transfer ownership explicitly; mutexes protect shared state but make ownership implicit\n3. **Send copies, not pointers** on channels — sending pointers creates invisible shared memory, defeating the purpose of channels\n4. **Only the sender closes a channel** — closing from the receiver side panics if the sender writes after close\n5. **Specify channel direction** (`chan\u003C-`, `\u003C-chan`) — the compiler prevents misuse at build time\n6. **Default to unbuffered channels** — larger buffers mask backpressure; use them only with measured justification\n7. **Always include `ctx.Done()` in select** — without it, goroutines leak after caller cancellation\n8. **Avoid repeated `time.After` in hot loops** — each call allocates a timer and creates unnecessary churn; use `time.NewTimer` + `Reset` for long-running loops\n9. **Track goroutine leaks in tests** with `go.uber.org\u002Fgoleak`\n\nFor detailed channel\u002Fselect code examples, see [Channels and Select Patterns](references\u002Fchannels-and-select.md).\n\n## Channel vs Mutex vs Atomic\n\n| Scenario | Use | Why |\n| --- | --- | --- |\n| Passing data between goroutines | Channel | Communicates ownership transfer |\n| Coordinating goroutine lifecycle | Channel + context | Clean shutdown with select |\n| Protecting shared struct fields | `sync.Mutex` \u002F `sync.RWMutex` | Simple critical sections |\n| Simple counters, flags | `sync\u002Fatomic` | Lock-free, lower overhead |\n| Many readers, few writers on a map | `sync.Map` | Optimized for read-heavy workloads. **Concurrent map read\u002Fwrite causes a hard crash** |\n| Caching expensive computations | `sync.Once` \u002F `singleflight` | Execute once or deduplicate |\n\n## WaitGroup vs errgroup\n\n| Need | Use | Why |\n| --- | --- | --- |\n| Wait for goroutines, errors not needed | `sync.WaitGroup` | Fire-and-forget |\n| Wait + collect first error | `errgroup.Group` | Error propagation |\n| Wait + cancel siblings on first error | `errgroup.WithContext` | Context cancellation on error |\n| Wait + limit concurrency | `errgroup.SetLimit(n)` | Built-in worker pool |\n\n## Sync Primitives Quick Reference\n\n| Primitive | Use case | Key notes |\n| --- | --- | --- |\n| `sync.Mutex` | Protect shared state | Keep critical sections short; never hold across I\u002FO |\n| `sync.RWMutex` | Many readers, few writers | Never upgrade RLock to Lock (deadlock) |\n| `sync\u002Fatomic` | Simple counters, flags | Prefer typed atomics (Go 1.19+): `atomic.Int64`, `atomic.Bool` |\n| `sync.Map` | Concurrent map, read-heavy | No explicit locking; use `RWMutex`+map when writes dominate |\n| `sync.Pool` | Reuse temporary objects | Always `Reset()` before `Put()`; reduces GC pressure |\n| `sync.Once` | One-time initialization | Go 1.21+: `OnceFunc`, `OnceValue`, `OnceValues` |\n| `sync.WaitGroup` | Waiting for simple goroutines | Go 1.25+: prefer `wg.Go(func(){ ... })` for fire-and-wait tasks that do not panic and do not need error propagation. For Go \u003C1.25 use `Add`\u002F`Done`. For errors\u002Fcancellation\u002Flimits, use `errgroup` with context. |\n| `x\u002Fsync\u002Fsingleflight` | Deduplicate concurrent calls | Cache stampede prevention |\n| `x\u002Fsync\u002Ferrgroup` | Goroutine group + errors | `SetLimit(n)` replaces hand-rolled worker pools |\n\nFor detailed examples and anti-patterns, see [Sync Primitives Deep Dive](references\u002Fsync-primitives.md).\n\n## Concurrency Checklist\n\nBefore spawning a goroutine, answer:\n\n- [ ] **How will it exit?** — context cancellation, channel close, or explicit signal\n- [ ] **Can I signal it to stop?** — pass `context.Context` or done channel\n- [ ] **Can I wait for it?** — `sync.WaitGroup` or `errgroup`\n- [ ] **Who owns the channels?** — creator\u002Fsender owns and closes\n- [ ] **Should this be synchronous instead?** — don't add concurrency without measured need\n\n## Pipelines and Worker Pools\n\nFor pipeline patterns (fan-out\u002Ffan-in, bounded workers, generator chains, Go 1.23+ iterators, `samber\u002Fro`), see [Pipelines and Worker Pools](references\u002Fpipelines.md).\n\n## Parallelizing Concurrency Audits\n\nWhen auditing concurrency across a large codebase, use up to 5 parallel sub-agents:\n\n1. Find all goroutine spawns (`go func`, `go method`) and verify shutdown mechanisms\n2. Search for mutable globals and shared state without synchronization\n3. Audit channel usage — ownership, direction, closure, buffer sizes\n4. Find `time.After` in loops, missing `ctx.Done()` in select, unbounded spawning\n5. Check mutex usage, `sync.Map`, atomics, and thread-safety documentation\n\n## Common Mistakes\n\n| Mistake | Fix |\n| --- | --- |\n| Fire-and-forget goroutine | Provide stop mechanism (context, done channel) |\n| Closing channel from receiver | Only the sender closes |\n| `time.After` in hot loop | Reuse `time.NewTimer` + `Reset` |\n| Missing `ctx.Done()` in select | Always select on context to allow cancellation |\n| Unbounded goroutine spawning | Use `errgroup.SetLimit(n)` or semaphore |\n| Sharing pointer via channel | Send copies or immutable values |\n| `wg.Add` inside goroutine | Call `Add` before `go` — `Wait` may return early otherwise |\n| Forgetting `-race` in CI | Always run `go test -race .\u002F...` |\n| Mutex held across I\u002FO | Keep critical sections short |\n\n## Cross-References\n\n- -> See `golang-performance` skill for false sharing, cache-line padding, `sync.Pool` hot-path patterns\n- -> See `golang-context` skill for cancellation propagation and timeout patterns\n- -> See `golang-safety` skill for concurrent map access and race condition prevention\n- -> See `golang-troubleshooting` skill for debugging goroutine leaks and deadlocks\n- -> See `golang-design-patterns` skill for graceful shutdown patterns\n- -> See `golang-continuous-integration` skill for automated AI-driven code review in CI using these guidelines\n\n### Go 1.26 experimental goroutine leak profile\n\nFor Go 1.26 diagnostics, there is an experimental goroutine leak profile. It is useful for production-oriented leak investigation, but is gated by `GOEXPERIMENT=goroutineleakprofile`; do not rely on it as default stable behavior.\n\nTypical usage when the experiment is enabled:\n\n```bash\ncurl http:\u002F\u002Flocalhost:6060\u002Fdebug\u002Fpprof\u002Fgoroutineleak?debug=2\ngo tool pprof http:\u002F\u002Flocalhost:6060\u002Fdebug\u002Fpprof\u002Fgoroutineleak\n```\n\nKeep existing tools:\n\n- tests: `go.uber.org\u002Fgoleak`\n- runtime count: `runtime.NumGoroutine()`\n- stack dump: `\u002Fdebug\u002Fpprof\u002Fgoroutine?debug=2`\n- race checks: `go test -race .\u002F...`\n\n## References\n\n- [Go Concurrency Patterns: Pipelines](https:\u002F\u002Fgo.dev\u002Fblog\u002Fpipelines)\n- [Effective Go: Concurrency](https:\u002F\u002Fgo.dev\u002Fdoc\u002Feffective_go#concurrency)\n",{"name":5,"paths":44,"license":15,"metadata":46,"description":7,"allowed-tools":56,"compatibility":57,"user-invocable":58},[45],"**\u002F*.go",{"author":47,"version":48,"openclaw":49},"samber","1.2.0",{"emoji":50,"install":51,"homepage":52,"requires":53},"⚡",[],"https:\u002F\u002Fgithub.com\u002Fsamber\u002Fcc-skills-golang",{"bins":54},[55],"go","Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent AskUserQuestion","Designed for Claude Code, Codex or similar harness, and for projects using Golang.",true,"main","c349be0704bffe54a7191d1412faf564b08983ca","skills\u002Fsamber-golang\u002Fgolang-concurrency",0,"https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills","https:\u002F\u002Fgithub.com\u002Frockcookies","2026-11-11 22:09:57",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":58},[68,71,74],{"tool":69,"command":70},"npx","npx skills add rockcookies\u002Fskills --skill golang-concurrency",{"tool":72,"command":73},"bunx","bunx skills add rockcookies\u002Fskills --skill golang-concurrency",{"tool":75,"command":76},"pnpm","pnpm dlx skills add rockcookies\u002Fskills --skill golang-concurrency","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsamber-golang\u002Fgolang-concurrency\u002FSKILL.md",[79,85,89,93,97,101],{"path":80,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":83,"sourceHtmlUrl":84},"evals\u002Fevals.json","REFERENCE","参考文档",16442,"https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsamber-golang\u002Fgolang-concurrency\u002Fevals\u002Fevals.json",{"path":86,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Fchannels-and-select.md",4018,"https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsamber-golang\u002Fgolang-concurrency\u002Freferences\u002Fchannels-and-select.md",{"path":90,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Fdirectory-layout.md",4407,"https:\u002F\u002Fgithub.com\u002Fcompozy\u002Fcompozy\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fapp-renderer-systems\u002Freferences\u002Fdirectory-layout.md",{"path":94,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":95,"sourceHtmlUrl":96},"references\u002Fpatterns.md",16358,"https:\u002F\u002Fgithub.com\u002Fcompozy\u002Fcompozy\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fapp-renderer-systems\u002Freferences\u002Fpatterns.md",{"path":98,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":99,"sourceHtmlUrl":100},"references\u002Fpipelines.md",6854,"https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsamber-golang\u002Fgolang-concurrency\u002Freferences\u002Fpipelines.md",{"path":102,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Fsync-primitives.md",8282,"https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsamber-golang\u002Fgolang-concurrency\u002Freferences\u002Fsync-primitives.md",[106,130,148,170,182,196],{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":39},"01M6WMNKD3Y4H9FGM8Q901F507","hierarchical-agents-md","init、update、audit 或 reorganize 以 AGENTS.md 与 README.md 为中心的层级项目文档： 初始化 Agent 指令、代码改动后更新文档、审计过期或冲突文档、重组仓库文档层级。","https:\u002F\u002Fgithub.com\u002Frockcookies\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcustom\u002Fhierarchical-agents-md\u002FSKILL.md",[],[113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129],"hierarchical agents md","agents md","python","change","init","packages","update","git","audit","文档","README","maintenance","third-party","初始化","true","for","party",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":141,"publishedAt":39},"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",[136],{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",[142,143,33,144,145,146,147,23],"functions","vueuse functions","vue","js","nuxt","build",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":158,"publishedAt":39},"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",[154,157],{"categoryNo":155,"categoryName":156,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},[159,160,161,144,162,24,163,23,164,165,166,167,168,169,145],"best practices","vue testing best practices","testing best practices","testing","e2e testing","playwright","test","component","testing patterns","e2e","vitest",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":177,"publishedAt":39},"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",[176],{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},[178,179,144,159,23,166,180,181],"vue router best practices","router","lifecycle","navigation",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":189,"publishedAt":39},"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",[188],{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},[190,191,159,144,192,193,194,195,23],"vue pinia best practices","pinia","state","management","state management","setup",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":211,"publishedAt":39},"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",[202,203,206],{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},{"categoryNo":204,"categoryName":205,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":207,"categoryName":208,"taxonomyType":209,"taxonomyTypeDesc":210},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[159,212,144,213,214,215,23,216,217,218],"api","vue options api best practices","data","methods","reference","only","context"]