Thank you for your interest in contributing! This framework is built by the community, for the community.
Run the framework and share interesting insights:
- Where: Create a PR to
examples/community/ - What to include:
- Anonymized exploration outputs (remove personal info)
- Your configuration (
evolution-config.yaml) - Summary of key insights
- Lessons learned
Example structure:
examples/community/your-name/
├── README.md (summary & lessons)
├── config.yaml (your configuration)
└── rounds/
├── round-05-interesting-insight.md
└── round-23-breakthrough-moment.md
Help make evolution sessions safer and more reliable:
- Better stop conditions
- HITL checkpoint patterns
- Error recovery strategies
- Resource monitoring
Create reusable exploration templates for common use cases:
- Research assistant patterns
- Product development workflows
- Learning companion scripts
- Creative exploration prompts
Enhance the framework with developer tools:
- Visual dashboard for monitoring
- Export to other formats (Obsidian, Notion, Roam)
- Analytics and insight extraction
- Integration with external tools
- Improve README clarity
- Add tutorials and guides
- Translate to other languages
- Document edge cases and solutions
node >= 18.0.0
npm >= 9.0.0
openclaw >= 2026.2.0# Clone repository
git clone https://github.com/your-org/openclaw-evolution-framework.git
cd openclaw-evolution-framework
# Install dependencies (if any)
npm install
# Copy example config
cp evolution-config.example.yaml evolution-config.yaml
# Run tests (coming soon)
npm testgit checkout -b feature/your-feature-name- Keep commits atomic and well-described
- Follow existing code style
- Add tests if applicable
- Update documentation
Before submitting:
# Test your config
openclaw cron add --file cron-evolution-job.json
openclaw cron run evolution-fast-loop
# Verify output
ls -la memory/evolution/- Clear title describing the change
- Description explaining why and what
- Link to related issues
- Screenshots/examples if applicable
- Automated checks (if configured)
- Community review (1-2 reviewers)
- Maintainer approval
- Merge (squash and merge)
- Use YAML for configs (not JSON for user-facing files)
- Include comments explaining each section
- Provide sensible defaults
- Use consistent indentation (2 spaces)
- Use ATX-style headers (
#not underlines) - Include code blocks with language hints
- Add examples for complex concepts
- Keep line length reasonable (~80-100 chars)
- Follow JavaScript Standard Style
- Use async/await over callbacks
- Add JSDoc comments for functions
- Handle errors gracefully
Please avoid:
-
Personal information in examples
- Remove names, locations, companies
- Anonymize user data
- Strip API keys and secrets
-
Copyrighted content
- Don't copy-paste from papers without permission
- Use your own words
- Link to sources instead
-
Dangerous configurations
- No infinite loops without stop conditions
- No excessive API usage
- No privacy-violating data collection
Contributors will be recognized in:
CONTRIBUTORS.mdfile- Release notes
- Project README
Be respectful, collaborative, and constructive:
- Be kind: Assume good intentions
- Be helpful: Share knowledge generously
- Be honest: Admit mistakes, learn together
- Be inclusive: Welcome all backgrounds
- General questions: Open a Discussion
- Bug reports: Open an Issue
- Feature requests: Open an Issue with
[Feature]prefix - Security concerns: Email maintainers privately
We especially welcome contributions in:
- Safety & reliability (HITL patterns, error handling)
- Templates & patterns (reusable exploration workflows)
- Visualization (dashboards, progress tracking)
- Documentation (tutorials, case studies)
- Testing (automated testing, validation)
Every contribution makes the framework better for everyone. Whether you fix a typo or build a major feature, your effort is appreciated.
Happy evolving! 🌳