Golang Samber Do

[
  {
    "id": 1,
    "name": "v2-import-not-v1",
    "description": "Tests whether the model uses samber/do/v2, never v1",
    "prompt": "I want to set up dependency injection in my Go project using samber/do. Show me how to install it and create a basic container.",
    "trap": "Without the skill, the model might import github.com/samber/do (v1) instead of github.com/samber/do/v2",
    "assertions": [
      {"id": "1.1", "text": "Uses go get github.com/samber/do/v2 (not github.com/samber/do without v2)"},
      {"id": "1.2", "text": "Import path is github.com/samber/do/v2 in the code"},
      {"id": "1.3", "text": "Uses do.New() to create the container"},
      {"id": "1.4", "text": "Does NOT reference v1 API or import paths anywhere"}
    ]
  },
  {
    "id": 2,
    "name": "lazy-vs-eager-vs-transient",
    "description": "Tests whether the model correctly chooses between lazy, eager, and transient service types",
    "prompt": "I have three services in my Go app: (1) a database connection that must be ready before serving requests, (2) a user repository that's only needed when user endpoints are called, and (3) a request logger that should be a fresh instance per request. Register them with samber/do.",
    "trap": "Without the skill, the model registers all three with do.Provide (lazy), missing do.Eager for the database and do.ProvideTransient for the logger",
    "assertions": [
      {"id": "2.1", "text": "Uses do.Provide with do.Eager wrapper (or equivalent) for the database connection that must be ready immediately"},
      {"id": "2.2", "text": "Uses do.Provide (lazy, the default) for the user repository that's only needed on demand"},
      {"id": "2.3", "text": "Uses do.ProvideTransient for the request logger that needs a fresh instance each time"},
      {"id": "2.4", "text": "Correctly distinguishes between the three service lifecycle types"},
      {"id": "2.5", "text": "Does NOT register all three services with the same registration function"}
    ]
  },
  {
    "id": 3,
    "name": "implicit-aliasing-invokeAs",
    "description": "Tests whether the model uses InvokeAs for implicit aliasing instead of explicit aliasing",
    "prompt": "I have a PostgreSQLDatabase struct that implements a Database interface. I want to register the concrete type but invoke it as the interface in my Go service. How do I set this up with samber/do?",
    "trap": "Without the skill, the model uses do.As or do.MustAs for explicit aliasing, which is only needed for legacy code. Implicit aliasing via InvokeAs is preferred.",
    "assertions": [
      {"id": "3.1", "text": "Registers the concrete type *PostgreSQLDatabase with do.Provide"},
      {"id": "3.2", "text": "Uses do.MustInvokeAs[Database] or do.InvokeAs[Database] to invoke as the interface"},
      {"id": "3.3", "text": "Prefers implicit aliasing (InvokeAs) over explicit aliasing (As/MustAs)"},
      {"id": "3.4", "text": "Does NOT require a separate alias registration step for this basic case"},
      {"id": "3.5", "text": "The provider function returns the concrete type, not the interface"}
    ]
  },
  {
    "id": 4,
    "name": "package-organization",
    "description": "Tests whether the model organizes service registrations using do.Package",
    "prompt": "My Go project has infrastructure services (database, cache), domain services (user service, order service), and transport services (HTTP handlers). How should I organize the DI registrations with samber/do?",
    "trap": "Without the skill, the model registers everything in main.go in a long list, missing do.Package for modular organization",
    "assertions": [
      {"id": "4.1", "text": "Uses do.Package to group related service registrations into separate packages/modules"},
      {"id": "4.2", "text": "Creates separate package variables (e.g., infrastructure.Package, service.Package, transport.Package)"},
      {"id": "4.3", "text": "Passes all packages to do.New() in main.go: do.New(infrastructure.Package, servi