[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7CWCGNWVKH6YXD54Q2ZW7S0":3,"skill-same:01M7CWCGNWVKH6YXD54Q2ZW7S0":58},{"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":37,"commitSha":38,"skillDirectory":39,"forksCount":40,"repositoryHtmlUrl":41,"repositoryHomepageUrl":6,"ownerHtmlUrl":42,"ownerBlogUrl":6,"ownerDescription":43,"updatedAt":44,"install":45,"resources":57},"01M7CWCGNWVKH6YXD54Q2ZW7S0","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.","om-scogo\u002Fskillsh-scraper","om-scogo","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160466840?v=4","01M79AWB6DFVCQ7RK70CS34B96","Om Achrekar","01M79AWB6ZM9SKR8KDH1WSSM22",0,"MIT","https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fsamber-cc-skills-golang\u002Fgolang-concurrency\u002Fskills\u002Fgolang-concurrency\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: golang-concurrency\ndescription: \"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.\"\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.1.5\"\n  openclaw:\n    emoji: \"⚡\"\n    homepage: https:\u002F\u002Fgithub.com\u002Fsamber\u002Fcc-skills-golang\n    requires:\n      bins:\n        - go\n    install: []\nallowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent AskUserQuestion\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:** Use `ultracode` for auditing concurrent code across a large codebase — orchestrate the five sub-agents described in the \"Parallelizing Concurrency Audits\" section and consolidate their findings into one report.\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 `samber\u002Fcc-skills-golang@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 (Agent tool):\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 `samber\u002Fcc-skills-golang@golang-performance` skill for false sharing, cache-line padding, `sync.Pool` hot-path patterns\n- -> See `samber\u002Fcc-skills-golang@golang-context` skill for cancellation propagation and timeout patterns\n- -> See `samber\u002Fcc-skills-golang@golang-safety` skill for concurrent map access and race condition prevention\n- -> See `samber\u002Fcc-skills-golang@golang-troubleshooting` skill for debugging goroutine leaks and deadlocks\n- -> See `samber\u002Fcc-skills-golang@golang-design-patterns` skill for graceful shutdown patterns\n- -> See `samber\u002Fcc-skills-golang@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:** Use `ultracode` for auditing concurrent code across a large codebase — orchestrate the five sub-agents described in the \"Parallelizing Concurrency Audits\" section and consolidate their findings into one report.\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 `samber\u002Fcc-skills-golang@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 (Agent tool):\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 `samber\u002Fcc-skills-golang@golang-performance` skill for false sharing, cache-line padding, `sync.Pool` hot-path patterns\n- -> See `samber\u002Fcc-skills-golang@golang-context` skill for cancellation propagation and timeout patterns\n- -> See `samber\u002Fcc-skills-golang@golang-safety` skill for concurrent map access and race condition prevention\n- -> See `samber\u002Fcc-skills-golang@golang-troubleshooting` skill for debugging goroutine leaks and deadlocks\n- -> See `samber\u002Fcc-skills-golang@golang-design-patterns` skill for graceful shutdown patterns\n- -> See `samber\u002Fcc-skills-golang@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,"license":15,"metadata":24,"description":7,"allowed-tools":34,"compatibility":35,"user-invocable":36},{"author":25,"version":26,"openclaw":27},"samber","1.1.5",{"emoji":28,"install":29,"homepage":30,"requires":31},"⚡",[],"https:\u002F\u002Fgithub.com\u002Fsamber\u002Fcc-skills-golang",{"bins":32},[33],"go","Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent AskUserQuestion","Designed for Claude Code or similar AI coding agents, and for projects using Golang.",true,"main","8859218955d9504cd18b59e7892100718039d3b4","data\u002Fskills\u002Fsamber-cc-skills-golang\u002Fgolang-concurrency\u002Fskills\u002Fgolang-concurrency",1,"https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper","https:\u002F\u002Fgithub.com\u002Fom-scogo","SDE-1 @ Scogo ","2026-07-18 12:22:46",{"source":8,"skillName":5,"commands":46,"prompt":56,"zipAvailable":36},[47,50,53],{"tool":48,"command":49},"npx","npx skills add om-scogo\u002Fskillsh-scraper --skill golang-concurrency",{"tool":51,"command":52},"bunx","bunx skills add om-scogo\u002Fskillsh-scraper --skill golang-concurrency",{"tool":54,"command":55},"pnpm","pnpm dlx skills add om-scogo\u002Fskillsh-scraper --skill golang-concurrency","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fsamber-cc-skills-golang\u002Fgolang-concurrency\u002Fskills\u002Fgolang-concurrency\u002FSKILL.md",[],[59,66,71,78,83,90],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":65,"publishedAt":19},"01M7D6MC9FAAEV4CMNYX8W7JTG","arxiv-search","Search arXiv physics, math, and computer science preprints using natural language queries. Powered by Valyu semantic search.","https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fyorkeccak-scientific-skills\u002Farxiv-search\u002Fskills\u002Farxiv-search\u002FSKILL.md",[],[],{"skillNo":67,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":70,"publishedAt":19},"01M7D6M85CKKN87TA98VCQV4H7","https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fyorkeccak-scientific-skills\u002Farxiv-search\u002FSkill.md",[],[],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":19},"01M7D4ZTCS4DR3CE4JY06X84T2","working-with-legacy-code","Safely change and test untested codebases using Feathers' \"Working Effectively with Legacy Code\". Use when the user mentions \"legacy code\", \"no tests\", \"untested codebase\", \"how do I test this\", \"seams\", \"characterization tests\", \"golden master\", \"sprout method\", \"afraid to change this code\", \"monster method\", \"dependency breaking\", or \"inherited a messy codebase\". Also trigger when changing code without tests safely, getting a class under test when constructors, statics, or singletons block it, adding features to tangled modules, or planning incremental test coverage for an old codebase. Covers the legacy-code change algorithm, seams, characterization tests, sprout\u002Fwrap, and dependency-breaking techniques. For refactoring code that already has tests, see refactoring-patterns. For day-to-day code quality, see clean-code.","https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fwondelai-skills\u002Fworking-with-legacy-code\u002Fworking-with-legacy-code\u002FSKILL.md",[],[],{"skillNo":79,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":19},"01M7D4ZHZKJD2RSNGAF63V14P4","https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fwondelai-skills\u002Fworking-with-legacy-code\u002FSkill.md",[],[],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":19},"01M7D4ZB4CJBFW5JE67CPH2QRV","web-typography","Select, pair, and implement typefaces for web projects. Use when the user mentions \"font pairing\", \"which typeface\", \"line height\", \"responsive typography\", \"web font loading\", \"type hierarchy\", \"variable fonts\", \"FOUT\u002FFOIT\", \"typographic scale\", or \"the text is hard to read\". Also trigger when choosing between system fonts and web fonts, optimizing font-loading performance, or designing readable long-form content. Covers readability evaluation, CSS implementation, and performance optimization. For overall UI design systems, see refactoring-ui. For dramatic typographic experiences, see top-design.","https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fwondelai-skills\u002Fweb-typography\u002Fweb-typography\u002FSKILL.md",[],[],{"skillNo":91,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":19},"01M7D4Z4MVYVY3NMJ18BNV6WNA","https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fwondelai-skills\u002Fweb-typography\u002FSkill.md",[],[]]