Extending and Contributing to Plandex
1. Start with the smallest runtime surface​
Plandex is easiest to approach when you pick one layer:
| Goal | First place to look |
|---|---|
| Terminal behavior | app/ |
| Hosted or service behavior | server/ |
| Docs and onboarding | docs/ |
| Operational helpers | scripts/ |
2. Why app and server boundaries matter​
The repo structure suggests a deliberate split between interactive application behavior and longer-lived runtime concerns. Respecting that split will keep contributions clearer and easier to review.
3. Best first contributions​
- docs and setup fixes,
- targeted context-handling improvements,
- terminal UX polish,
- self-hosting clarity,
- test coverage around large-task behavior.
4. Think in reviewable diffs​
A good Plandex contribution should improve one of these things:
- task coherence,
- context handling,
- reviewability,
- operational clarity.
5. Before opening a PR​
Validate the workflow your patch affects on a real repo task and make sure the resulting diff is still understandable to a human reviewer.