Extending and Contributing to NanoClaw
1. Start with the skill model first​
NanoClaw's contribution guidance is refreshingly explicit:
do not add broad new features to trunk if they belong as skills
That means your first design decision is whether the change belongs in:
| Goal | First place to look |
|---|---|
| host runtime | core src/ host files |
| provider or channel module | skill-installed branch or module |
| per-agent behavior | group-level workspace or container layer |
| docs and migration | docs and migration scripts |
2. Why this matters​
The project wants trunk to remain:
- small,
- understandable,
- and safe to fork.
If you ignore that goal, you will probably fight the repo's philosophy.
3. Best first contributions​
- docs and architecture clarification,
- migration and install polish,
- skill examples,
- targeted host-runtime fixes,
- isolation-model improvements.
4. Think in maintainable forks​
A good NanoClaw contribution should help users keep their fork lean and comprehensible, not make the main branch harder to audit.
5. Before opening a PR​
Ask whether the capability belongs in trunk, a skill branch, or the user's own fork. In NanoClaw, that choice is part of the architecture.