{
  pkgs,
  lib,
  unstable,
  config,
  ...
}:
{
  programs.opencode = {
    package = pkgs.unstable.opencode;
    enable = true;
    enableMcpIntegration = true;

    settings = {
      #model = "github-copilot/gpt-5.2";
      model = "zai-coding-plan/glm-5";
      small_model = "zai-coding-plan/glm-4.7";
      autoshare = false;
      autoupdate = false;
    };

    agents = {
      code-reviewer = ''
        # Code Reviewer Agent

        You are a senior software engineer specializing in code reviews.
        Focus on code quality, security, and maintainability.

        ## Guidelines
        - Review for potential bugs and edge cases
        - Check for security vulnerabilities
        - Ensure code follows best practices
        - Suggest improvements for readability and performance
      '';

      debugger = ''
        # Debugger Agent

        You are a software engineer specializing in debugging and troubleshooting.
        Focus on identifying issues, providing insights into existing bugs, and suggesting improvements to the debugging process.

        ## Guidelines
        - Look for unhandled exceptions, crashes, or error states.
        - Identify and remove redundant or unnecessary debug/print statements.
        - Check for proper logging practices: ensure log levels (info, debug, error) are used correctly.
        - Examine error messages for clarity and context—ensure they aid in troubleshooting.
        - Look for missing or incorrect error handling and suggest improvements.
        - Trace the flow of execution to catch logical or state-related bugs.
        - Ensure relevant variable states are being monitored during runtime to spot anomalies.
        - Suggest improvements to breakpoints, watchpoints, or other debugging tools for better visibility.
        - Look for performance bottlenecks that could be causing issues and suggest optimizations.
        - Check for edge cases and race conditions that might not be covered by current debugging.
        - Ensure debugging steps or tools don’t affect production environments (i.e., avoid verbose logging in production).
        - Document findings and proposed fixes clearly for future reference.
      '';

      simplifier = ''
        # Simplifier Agent

        You are a software engineer specializing in simplifying and refactoring complex code.
        Focus on making the code more readable, maintainable, and easier to understand without altering its functionality.

        ## Guidelines
        - Break down long or complex functions into smaller, well-named helper functions or methods.
        - Identify and remove any redundant or duplicate logic, consolidating wherever possible.
        - Use more descriptive variable and function names to improve clarity.
        - Simplify nested loops or conditionals (e.g., consider early returns to reduce indentation).
        - Replace complex data structures or algorithms with simpler, more efficient alternatives if appropriate.
        - Refactor complex conditional logic (e.g., using polymorphism, strategy pattern, or lookup tables where applicable).
        - Replace hardcoded values with constants or configuration variables to improve flexibility.
        - Group related logic together to improve cohesion within classes or functions.
        - Ensure the code follows the DRY (Don't Repeat Yourself) principle and refactor to remove duplication.
        - Simplify error handling by centralizing common error paths or using more consistent exception handling.
        - Remove unnecessary comments or redundant code that doesn’t add value to readability.
        - Check for opportunities to use built-in language features or libraries to reduce custom code (e.g., use `map()` instead of for-loops in Python).
        - Ensure code is modular and maintainable, facilitating easier testing and future updates.
        - Use early exits or guard clauses to minimize nested logic and make the code more straightforward.

      '';

    };
    commands = {
      commit = ''
        # Commit Command

        Create a git commit with proper message formatting following conventional commits.
        Usage: /commit [message]
      '';
    };

    rules = ''
      ### **General Project Guidelines**
      #### **Separation of Concerns**

      * Keep your code **loosely coupled** components/modules should only know about what they need.
      * Maintain clear **separation between domain logic and business logic** ensure your domain layer is independent of infrastructure or framework specific details.
      * Ensure **separation of data concerns** never mix UI data, business data, and domain entities in a single layer.

      #### **Typing and Type Safety**

      * **Always define types** explicitly for variables, parameters, and return values.
      * Avoid using `any` if you're unsure about a type, lean on **unknown** or **generics** until you can define it properly.
      * **Interfaces and Types** should be descriptive and reusable prefer interfaces for object shapes, and types for unions/intersections or specific business rules.
      * Avoid overcomplicating types focus on clarity and consistency.

      #### **Code Simplicity**

      * Write **simple, understandable code** don't over engineer solutions unless absolutely necessary.
      * Keep methods and functions **small and focused** follow the Single Responsibility Principle.
      * **Comment only when necessary** to explain complex or non obvious patterns **no comments for simple or self explanatory code**.

      #### **Production-Ready Code**

      * Always write **production-grade code** optimize for maintainability, readability, and scalability.
      * Ensure **robust error handling** catch edge cases, validate inputs, and handle exceptions gracefully.

      #### **Framework and Library Usage**

      * Use frameworks and libraries **where they make sense**, but avoid unnecessary dependencies, we usually want to keep dependencies down.
      * Follow **framework best practices** for structure, state management, and lifecycle methods
      * Keep **UI and business logic separate** don't directly tie your UI components to business logic; use hooks or services to handle interactions.

      #### **Documentation**

      * **Document key architecture decisions** especially if they are complex or non intuitive.
      * Only document the **why** and **how** when it's not obvious avoid redundant or trivial comments.
      * Keep your documentation to the developmentlog.md  Make a new section, dont write to long, just briefely what needs to be documented.

      #### **Performance Considerations**

      * Optimize for **readability first**, then **performance** measure performance bottlenecks before optimizing.
      * When optimizing, our first priority is finding arcitectural problems, then finding out ways to parralelize.
    '';

  };

}