Golang Samber Lo

{
  "skill_name": "golang-samber-lo",
  "evals": [
    {
      "id": 1,
      "name": "lop-for-io-trap",
      "prompt": "I have a Go service that needs to fetch data from 50 different REST APIs concurrently and collect results. I'm using samber/lo already. Should I use lop.Map to parallelize the HTTP calls? Write the implementation.",
      "expected_output": "Should recommend errgroup (or similar) for I/O-bound concurrency instead of lop. lop is for CPU-bound parallelism. Should explain why lop is wrong here (no context cancellation, no error handling, goroutine-per-element overhead for I/O).",
      "assertions": [
        {"text": "Recommends errgroup or similar I/O concurrency pattern instead of (or in addition to) lop for HTTP calls", "type": "semantic"},
        {"text": "Explains that lop is designed for CPU-bound parallelism, not I/O-bound work", "type": "semantic"},
        {"text": "Mentions lack of context cancellation as a limitation of lop for I/O", "type": "semantic"},
        {"text": "Does NOT simply use lop.Map as the primary solution for HTTP fan-out", "type": "semantic"},
        {"text": "Shows working Go code for the concurrent HTTP fetch pattern", "type": "semantic"}
      ]
    },
    {
      "id": 2,
      "name": "premature-lom-optimization",
      "prompt": "My Go API is a bit slow. I'm using lo.Filter and lo.Map in several places. I want to switch everything to lom.Filter and lom.Map for better performance. Can you help me refactor?",
      "expected_output": "Should advise profiling first before switching to lom. Should warn about immutability loss. Should NOT blindly refactor everything to lom.",
      "assertions": [
        {"text": "Recommends profiling (pprof, alloc_objects) before switching to lom", "type": "semantic"},
        {"text": "Warns that lom mutates the input slice (breaks immutability)", "type": "semantic"},
        {"text": "Does NOT blindly refactor all lo calls to lom without questioning the premise", "type": "semantic"},
        {"text": "Explains that the performance issue may not be caused by lo allocations", "type": "semantic"},
        {"text": "Mentions that lom is only appropriate for hot paths confirmed by profiling", "type": "semantic"},
        {"text": "Warns about concurrency safety implications of switching to mutable operations", "type": "semantic"}
      ]
    },
    {
      "id": 3,
      "name": "stdlib-vs-lo-preference",
      "prompt": "I'm writing a Go function that needs to check if a string slice contains a value, sort an int slice, and get all keys from a map. I already have samber/lo as a dependency. Should I use lo.Contains, and lo.Keys for these?",
      "expected_output": "Should recommend stdlib slices.Contains and slices.Sort over lo equivalents when using Go 1.21+. For map keys, should gate maps.Keys to Go 1.23+ and use slices.Collect(maps.Keys(m)) when a slice is needed. Should explain that stdlib is preferred for operations it covers.",
      "assertions": [
        {"text": "Recommends slices.Contains from stdlib over lo.Contains", "type": "semantic"},
        {"text": "Recommends slices.Sort or slices.SortFunc from stdlib", "type": "semantic"},
        {"text": "Recommends slices.Collect(maps.Keys(m)) from stdlib over lo.Keys when the module targets Go 1.23+", "type": "semantic"},
        {"text": "Mentions Go 1.21+ for slices helpers and Go 1.23+ for maps.Keys", "type": "semantic"},
        {"text": "Explains the rationale: prefer stdlib when it covers the operation to avoid unnecessary dependency usage", "type": "semantic"},
        {"text": "Acknowledges that lo is still useful for operations stdlib doesn't provide (Map, Filter, Reduce, GroupBy)", "type": "semantic"}
      ]
    },
    {
      "id": 4,
      "name": "loi-go-version-constraint",
      "prompt": "I'm building a data pipeline in Go 1.20 that chains multiple transformations on a large dataset (1M records). I want to use lo/it for lazy evaluation to avoid intermediate allocations