Extending and Contributing to IronClaw
1. Start with the narrowest owned layer​
For IronClaw, good first contributions begin in one clear place:
| Goal | First place to look |
|---|---|
| CLI behavior | Reborn CLI implementation |
| provider and model flow | model-routing code and docs |
| config behavior | config and profile handling |
| policy or storage behavior | policy and storage surfaces |
| docs | operator and setup documentation |
2. Why narrow changes matter​
Because IronClaw is security-conscious, even small changes can affect:
- secret handling,
- profile safety,
- state seeding,
- production assumptions.
That makes tightly scoped patches especially important.
3. Best first contributions​
- docs and setup clarification,
- config ergonomics,
- clearer diagnostics,
- provider-routing fixes,
- test coverage around policy-sensitive paths.
4. Think like an operator​
A strong IronClaw contribution should improve at least one of these:
- clarity,
- auditability,
- safe defaults,
- operational confidence.
5. Before opening a PR​
Validate both the user-visible behavior and the operator impact of your change. In a project like IronClaw, that second part matters just as much.