142 lines
6.8 KiB
Nix
142 lines
6.8 KiB
Nix
{
|
||
pkgs,
|
||
lib,
|
||
unstable,
|
||
config,
|
||
...
|
||
}:
|
||
{
|
||
home.packages = with pkgs; [
|
||
opencode
|
||
];
|
||
|
||
programs.opencode = {
|
||
enable = true;
|
||
enableMcpIntegration = true;
|
||
|
||
|
||
settings = {
|
||
model = "anthropic/claude-sonnet-4-20250514";
|
||
small_model = "anthropic/claude-haiku-4-5";
|
||
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.
|
||
'';
|
||
|
||
};
|
||
|
||
|
||
}
|