Extending and Contributing to Goose
1. Start with the narrowest layer​
Goose is broad enough that you should choose one surface first:
| Goal | First place to look |
|---|---|
| Core runtime behavior | crates/ |
| Desktop experience | ui/ |
| Docs or onboarding | documentation/ |
| Reusable workflows | workflow_recipes/ |
| Packaging or distro work | custom distro and build docs |
2. Why the repo is organized this way​
The layout encourages contributors to keep concerns separated:
- Rust runtime changes stay in Rust crates,
- UI work stays in UI code,
- packaging and distro concerns stay in their own docs and scripts.
That reduces the chance of one feature request turning into a tangled cross-cutting patch.
3. Good first contributions​
The easiest productive first contributions are usually:
- provider-doc improvements,
- CLI or desktop onboarding fixes,
- recipe examples,
- targeted runtime bug fixes,
- MCP integration polish.
4. Bigger contribution areas​
Goose also exposes bigger strategic surfaces:
- custom distributions,
- API embedding,
- workflow recipes,
- provider ecosystem growth.
Those are good paths for teams who want to adopt Goose as a platform, not only as a personal assistant.
5. Before opening a PR​
Read CONTRIBUTING.md, understand the relevant crate or UI area first, and keep your first patch narrow enough that a maintainer can review it without needing the whole repo in their head.