Thank you for considering contributing to the MacUse Agent project!
Please maintain a friendly and inclusive communication approach. Be respectful of all contributors and users.
- Use issue templates to report bugs or request features
- Search existing issues to avoid duplicates
- Provide clear, detailed descriptions of the problem or feature request
- Include environment information (OS version, Go version, etc.)
- Fork this repository
- Create your feature branch (
git checkout -b feature/amazing-feature) - Commit your changes (
git commit -m 'Add some AmazingFeature') - Push to the branch (
git push origin feature/amazing-feature) - Open a Pull Request
- Write a clear PR title and description
- Reference related issues using
#issue-number - Include screenshots or examples for UI changes
- Update documentation as needed
- Go 1.24+
- macOS (for RPA feature testing)
- Optional: LM Studio for local LLM testing
# Clone repository
git clone https://github.com/bzfq21/Go-ComputerUseAgent.git
cd Go-ComputeUseAgent
# Install dependencies
make deps
# Run tests
make test
# Build locally
make build
# Run with default config
./build/agent -help- Run
make fmtto format code - Run
make vetto check code - Run
make lintfor code quality checks
internal/core/llm/- LLM client implementationsinternal/core/rpa/- RPA tools and automationinternal/core/workflow/- Workflow engineinternal/config/- Configuration managementinternal/models/- Data models
- Run
make testto execute all tests - Run
make test-coverageto view test coverage - Run
make test-racefor race detection - Run
make benchfor benchmark tests
To add a new RPA tool:
- Create a new file in
internal/core/rpa/tools/in the appropriate category (mouse, keyboard, screen, system) - Implement the
interfaces.Toolinterface - Register the tool in
rpa.goin theregisterAllTools()function - Write tests for the new tool
- Update documentation
Example:
// internal/core/rpa/tools/mytool/mytool.go
package mytool
import (
"github.com/bzfq21/Go-ComputerUseAgent/internal/core/rpa/interfaces"
)
type MyTool struct {
// tool fields
}
func NewMyTool() interfaces.Tool {
return &MyTool{}
}
func (t *MyTool) GetDefinition() (interfaces.ToolDefinition, error) {
return interfaces.ToolDefinition{
Name: "my_tool",
Category: interfaces.CategoryCustom,
Description: "Description of my tool",
Parameters: map[string]interfaces.Parameter{
"param1": {
Type: "string",
Required: true,
Description: "Parameter description",
},
},
}, nil
}
func (t *MyTool) Execute(ctx context.Context, params map[string]any) (*interfaces.ActionResult, error) {
// implementation
return &interfaces.ActionResult{
Success: true,
Data: result,
}, nil
}To add a new LLM provider:
- Create a new file in
internal/core/llm/implementing theLLMClientinterface - Add the provider to the client factory in
factory.go - Update configuration in
config.goto support the new provider - Write tests for the new client
- Update documentation
Follow conventional commits format:
<type>(<scope>): <subject>
<body>
<footer>
Types:
feat: New featurefix: Bug fixdocs: Documentation changesstyle: Code style changes (formatting, etc.)refactor: Code refactoringtest: Adding or updating testschore: Maintenance tasks
Examples:
feat(llm): add support for new LLM providerfix(rpa): resolve crash when taking screenshotdocs(readme): update installation instructions
- Ensure all tests pass (
make test) - Ensure code is formatted (
make fmt) - Ensure vet passes (
make vet) - Run lint (
make lint) - Update documentation if needed
- Request review from maintainers
- Ensure PR description is clear and includes:
- Summary of changes
- Motivation for the change
- Related issues
- Testing performed
- Pass all CI checks
- Get approval from at least one maintainer
- Address review comments
- Merge into main branch
- Delete feature branch after merging
Releases are managed by maintainers following semantic versioning:
- Update version in
config.godefault config - Update CHANGELOG.md (if exists)
- Create git tag
- Build release binaries
- Create GitHub release
- Write clear, descriptive variable and function names
- Add comments for complex logic
- Handle errors appropriately
- Write tests for new functionality
- Keep functions focused and small
- Follow Go best practices and idioms
- Use interfaces for decoupling
For security vulnerabilities, please do not create a public issue. Instead:
- Email the maintainers privately
- Include detailed description of the vulnerability
- Provide steps to reproduce
- Wait for maintainers to respond and fix the issue
- Check existing issues and discussions
- Read source code comments
- Ask questions in GitHub Discussions (if enabled)
- Contact maintainers for guidance
Thank you for your contributions!