Golang Structs Interfaces

[
  {
    "id": 1,
    "name": "interface-at-consumer-not-implementor",
    "description": "Tests whether the model defines interfaces where they are consumed, not where they are implemented",
    "prompt": "I'm writing a Go notification service that can send emails. I have an email package with a Client struct that has a Send method. I also have a notification package that needs to use this email client. Where should I define the interface?",
    "trap": "Without the skill, the model often puts the interface in the email package (the implementor). The skill says interfaces MUST be defined where consumed, not where implemented.",
    "assertions": [
      {"id": "1.1", "text": "Interface is defined in the notification package (the consumer), NOT in the email package"},
      {"id": "1.2", "text": "Interface has only the methods the notification package needs (not the full email.Client API)"},
      {"id": "1.3", "text": "Email package exports a concrete Client struct, not an interface"},
      {"id": "1.4", "text": "Explains WHY: keeps the consumer in control of the contract, avoids importing a package just for its interface"},
      {"id": "1.5", "text": "Notification service depends on its own interface, not on email package types"}
    ]
  },
  {
    "id": 2,
    "name": "return-structs-not-interfaces",
    "description": "Tests whether the model returns concrete types from constructors, not interfaces",
    "prompt": "I'm designing a Go package with a UserService that depends on a UserStore interface. Should my NewUserService constructor return *UserService or UserServiceInterface? Show me the constructor signature.",
    "trap": "Without the skill, the model may suggest returning an interface for 'flexibility' or 'abstraction'. The skill says functions SHOULD return concrete types -- NEVER return interfaces from constructors.",
    "assertions": [
      {"id": "2.1", "text": "Constructor returns *UserService (concrete type), NOT an interface"},
      {"id": "2.2", "text": "Constructor accepts UserStore as an interface parameter (accept interfaces)"},
      {"id": "2.3", "text": "Explains WHY: callers get full access to the concrete type's fields/methods; consumers can assign to interface if needed"},
      {"id": "2.4", "text": "Explicitly states that returning interfaces from constructors is bad practice"},
      {"id": "2.5", "text": "The accept-interfaces-return-structs principle is stated or demonstrated"}
    ]
  },
  {
    "id": 3,
    "name": "premature-interface-trap",
    "description": "Tests whether the model avoids creating interfaces prematurely when there is only one implementation",
    "prompt": "I'm writing a Go application with a UserRepository that talks to PostgreSQL. It's the only database we'll ever use. Should I create a UserRepository interface and a concrete postgresUserRepository struct, or just use a concrete struct directly?",
    "trap": "Without the skill, the model almost always suggests creating an interface 'for testability' even with a single implementation. The skill says NEVER create interfaces prematurely -- wait for 2+ implementations or a testability requirement.",
    "assertions": [
      {"id": "3.1", "text": "Recommends starting with a concrete struct (not an interface) when there is only one implementation"},
      {"id": "3.2", "text": "Mentions the principle: don't design with interfaces, discover them"},
      {"id": "3.3", "text": "Suggests extracting an interface LATER when a second consumer or test mock demands it"},
      {"id": "3.4", "text": "Acknowledges that testability IS a valid reason to add an interface, but it should be a deliberate choice"},
      {"id": "3.5", "text": "Does NOT reflexively recommend creating an interface just because it is a repository"}
    ]
  },
  {
    "id": 4,
    "name": "zero-value-useful-design",
    "description": "Tests whether the model designs structs with useful zero values using lazy initialization",
    "prompt": "I have a Go Reg