1  {
 2    config,
 3    ...
 4  }:
 5  {
 6    programs.opencode = {
 7      enable = true;
 8      web.enable = true;
 9      tui.theme = "gruvbox";
10      web.extraArgs = [ "--mdns" ];
11      enableMcpIntegration = true;
12  
13      settings = {
14        autoshare = false;
15        autoupdate = false;
16        server.mdns = true;
17        # model = "ollama/qwen3.5:35b-a3b-coding-nvfp4";
18        model = "openai/gpt5.4";
19        disabled_providers = [
20          "github"
21          "gemini"
22          # "openai"
23        ];
24  
25        provider.ollama = {
26          name = "Ollama (local)";
27          npm = "@ai-sdk/openai-compatible";
28          models."qwen3.5:35b-a3b-coding-nvfp4".name = "qwen3.5:35b-a3b-coding-nvfp4";
29          "options"."baseURL" =
30            "http://${config.services.ollama.host}:${builtins.toString config.services.ollama.port}/v1";
31        };
32  
33        permission = {
34          read = "allow";
35          bash = "allow";
36          edit = "allow";
37          grep = "allow";
38          glob = "allow";
39          list = "allow";
40          write = "allow";
41          skill = "allow";
42          webfetch = "allow";
43          question = "allow";
44          todowrite = "allow";
45        };
46      };
47  
48      rules = ''
49        General Project Rules
50        ## External File Loading
51  
52        CRITICAL: When you encounter a file reference (e.g., @rules/general.md), use your Read tool to load it on a need-to-know basis. They're relevant to the SPECIFIC task at hand.
53  
54        # Taste
55  
56        - I have a strong preference for modular, re-usable code.
57        - I'm a strong advocate for test-driven development, and prefer to develop against a test suite.
58        - When doing feature development, move slow, and correct. Do not rush. Start with small parts and get them working.
59  
60        ## Instructions
61  
62        ### General
63  
64        - Do NOT preemptively load all references - use lazy loading based on actual need.
65        - When loaded, treat content as mandatory instructions that override defaults.
66        - Follow references recursively when needed.
67  
68        ### Tooling
69  
70        - If @devenv.nix along with an @.envrc exists at the repository root, that means I'm using Devenv - https://devenv.sh, and direnv.
71          - Always do `direnv allow` before running commands as you may have been launched from outside the directory and may not have access.
72            to the environment variables, scripts, tasks, and processes in your shell context until that.
73          - If you suspect that a command for an app failure may be related to devenv shell not instantiating or direnv hooks not loading properly,
74            stop immediately and ask me for help.
75  
76        ### Taste
77  
78        - Languages: Look to always use existing features and standard libraries of the programming language to its full potential instead of making custom data structures and functions.
79        - Variables: NEVER use single letter or short names. `temperature_celcius` is preferred as opposed `temp`. Avoid repeating variable names again and again. Prefer to factor into structs, functions, and directories. Duplicated and repetitive naming causes extreme grep pollution.
80        - Functions: look to keep functions monadic, which means only take a single argument. If a diadic function (two arguments) significantly simplifies things, then prefer that. Always avoid going any higher than diadic (triadic, quadratic, etc.).
81        - Libraries: When encountering existing libraries, ALWAYS look to use existing abstractions from the library to keep the volume of our own code low.
82          - If you're not familiar with the library APIs let me know and I'll checkout the source of the library to my git root for you to scan and delete it after.
83  
84        ### Philosophy
85  
86        - Keep things simple. Your greatest priority is to remove code, not create more of it.
87        - Think outside the box to see if there's a no-code solution to the user experience problem at hand. Authoring software is our last resort, not primary. Always avoid throwing more code at the problem.
88        - Dig deep beneath the problem to eliminate it or sidestep it altogether rather than applying a solution. We have a limited amount of time and bandwidth, and need to pick our battles carefully.
89        - Always avoid writing custom code and shop around for existing standard, libraries, features, approaches etc. The more code we write the more code we have to maintain.
90        - Refactor early and refactor often. If you come across an area that could be improved, don't ignore it. Just patch it up as you pass by. Always leave code better than you found it. Ideally less lines and more readable for humans.
91      '';
92    };
93  }