Contributing
Keep changes focused and validated, document provider/platform assumptions explicitly, and never commit secrets or machine-specific paths.
Before opening a PR
- Work on a feature branch; keep changes focused on one thing.
- Run the required checks: typecheck, tests, and a production build — plus a real smoke script for anything involving agent execution, IPC, persisted AIgency state, packaging, or destructive actions.
- Write a clear PR description, especially for anything touching provider-specific behavior — a claim like "Codex supports X" should be traceable to something you actually verified, not an assumption carried over from Claude Code or Antigravity.
What not to do
Warning
Never commit secrets, API keys, or machine-specific absolute paths. If you're documenting a provider behavior, verify it against that provider's own current CLI/SDK rather than assuming parity across agents — the three integrations are genuinely different (see Agent adapter architecture).
Platform assumptions
Because the free and Pro repositories differ in what they package (see Packaging), be explicit in a PR description about which repository a change applies to if it touches build/release configuration.