Your Name
86 lines
4.2 KiB
Nix
86 lines
4.2 KiB
Nix
{
|
|
pkgs,
|
|
lib,
|
|
unstable,
|
|
config,
|
|
...
|
|
}:
|
|
{
|
|
programs.opencode = {
|
|
package = pkgs.opencode;
|
|
enable = true;
|
|
enableMcpIntegration = true;
|
|
|
|
settings = {
|
|
#model = "github-copilot/gpt-5.2";
|
|
model = "zai-coding-plan/glm-5.1";
|
|
small_model = "zai-coding-plan/glm-5.1";
|
|
autoshare = false;
|
|
autoupdate = false;
|
|
};
|
|
|
|
commands = {
|
|
commit = ''
|
|
# Commit Command
|
|
|
|
Create a git commit with proper message formatting following conventional commits.
|
|
Keep it simple and only have one simple commit line. If you need to know what was changed, look at the staged files, and the diffs of the relevant ones.
|
|
Usage: /commit [message]
|
|
'';
|
|
};
|
|
|
|
context = ''
|
|
### **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.
|
|
|
|
# General Rules
|
|
Keep things understandable for a software engineer. You dont need to over explain, and rather keep things a bit simpler. and tify.
|
|
Dont overly format your text as well. When writing plain text, markdown or similat, keep the writing in a human style with minimal formating, and good but simple explanations.
|
|
Be brief, you dont need to overly explain concepts or content that dont really need more explanation.
|
|
Tell the user where it takes wrong if the user does. You are allowed to think critically, and find problems in existing solutions, but start by asking, to get more clarification.
|
|
Dont do all the work for the user, rather let the user know where some help from them are needed. Some things are better done manually, and should not be done by you the assistant.
|
|
'';
|
|
|
|
};
|
|
|
|
}
|