## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - As the project grows, more contributors want to build features — which is great > - Without a public roadmap or clear contribution guidance, contributors spend time on PRs that overlap with planned core work > - This creates frustration on both sides when those PRs can't be merged > - This PR publishes a roadmap, updates the contribution guide with a clear path for feature proposals, and reinforces the workflow in the PR template > - The benefit is that contributors know exactly how to propose features and where to focus for the highest-impact contributions ## What Changed - Added `ROADMAP.md` with expanded descriptions of all shipped and planned milestones, plus guidance on coordinating feature contributions - Added "Feature Contributions" section to `CONTRIBUTING.md` explaining how to propose features (check roadmap → discuss in #dev → consider the plugin system) - Updated `.github/PULL_REQUEST_TEMPLATE.md` with a callout linking to the roadmap and a new checklist item to check for overlap with planned work, while preserving the newer required `Model Used` section from `master` - Added `Memory / Knowledge` to the README roadmap preview and linked the preview to the full `ROADMAP.md` ## Verification - Open `ROADMAP.md` on GitHub and confirm it renders correctly with all milestone sections - Read the new "Feature Contributions" section in `CONTRIBUTING.md` and verify all links resolve - Open a new PR and confirm the template shows the roadmap callout and the new checklist item - Verify README links to `ROADMAP.md` and the roadmap preview includes "Memory / Knowledge" ## Risks - Docs-only change — no runtime or behavioral impact - Contribution policy changes were written to be constructive and to offer clear alternative paths (plugins, coordination via #dev, reference implementations as feedback) ## Model Used - OpenAI Codex local agent (GPT-5-based coding model; exact runtime model ID is not exposed in this environment) - Tool use enabled for shell, git, GitHub CLI, and patch application - Used to rebase the branch, resolve merge conflicts, update the PR metadata, and verify the repo state ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [ ] I have run tests locally and they pass - [ ] I have added or updated tests where applicable (N/A — docs only) - [ ] If this change affects the UI, I have included before/after screenshots (N/A — no UI changes) - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>
5.5 KiB
Contributing Guide
Thanks for wanting to contribute!
We really appreciate both small fixes and thoughtful larger changes.
Two Paths to Get Your Pull Request Accepted
Path 1: Small, Focused Changes (Fastest way to get merged)
- Pick one clear thing to fix/improve
- Touch the smallest possible number of files
- Make sure the change is very targeted and easy to review
- All tests pass and CI is green
- Greptile score is 5/5 with all comments addressed
- Use the PR template
These almost always get merged quickly when they're clean.
Path 2: Bigger or Impactful Changes
- First talk about it in Discord → #dev channel
→ Describe what you're trying to solve
→ Share rough ideas / approach - Once there's rough agreement, build it
- In your PR include:
- Before / After screenshots (or short video if UI/behavior change)
- Clear description of what & why
- Proof it works (manual testing notes)
- All tests passing and CI green
- Greptile score 5/5 with all comments addressed
- PR template fully filled out
PRs that follow this path are much more likely to be accepted, even when they're large.
PR Requirements (all PRs)
Use the PR Template
Every pull request must follow the PR template at .github/PULL_REQUEST_TEMPLATE.md. If you create a PR via the GitHub API or other tooling that bypasses the template, copy its contents into your PR description manually. The template includes required sections: Thinking Path, What Changed, Verification, Risks, Model Used, and a Checklist.
Model Used (Required)
Every PR must include a Model Used section specifying which AI model produced or assisted with the change. Include the provider, exact model ID/version, context window size, and any relevant capability details (e.g., reasoning mode, tool use). If no AI was used, write "None — human-authored". This applies to all contributors — human and AI alike.
Tests Must Pass
All tests must pass before a PR can be merged. Run them locally first and verify CI is green after pushing.
Greptile Review
We use Greptile for automated code review. Your PR must achieve a 5/5 Greptile score with all Greptile comments addressed before it can be merged. If Greptile leaves comments, fix or respond to each one and request a re-review.
Feature Contributions
We actively manage the core Paperclip feature roadmap.
Uncoordinated feature PRs against the core product may be closed, even when the implementation is thoughtful and high quality. That is about roadmap ownership, product coherence, and long-term maintenance commitment, not a judgment about the effort.
If you want to contribute a feature:
- Check ROADMAP.md first
- Start the discussion in Discord ->
#devbefore writing code - If the idea fits as an extension, prefer building it with the plugin system
- If you want to show a possible direction, reference implementations are welcome as feedback, but they generally will not be merged directly into core
Bugs, docs improvements, and small targeted improvements are still the easiest path to getting merged, and we really do appreciate them.
General Rules (both paths)
- Write clear commit messages
- Keep PR title + description meaningful
- One PR = one logical change (unless it's a small related group)
- Run tests locally first
- Be kind in discussions 😄
Writing a Good PR message
Your PR description must follow the PR template. All sections are required. The "thinking path" at the top explains from the top of the project down to what you fixed. E.g.:
Thinking Path Example 1:
- Paperclip orchestrates ai-agents for zero-human companies
- There are many types of adapters for each LLM model provider
- But LLM's have a context limit and not all agents can automatically compact their context
- So we need to have an adapter-specific configuration for which adapters can and cannot automatically compact their context
- This pull request adds per-adapter configuration of compaction, either auto or paperclip managed
- That way we can get optimal performance from any adapter/provider in Paperclip
Thinking Path Example 2:
- Paperclip orchestrates ai-agents for zero-human companies
- But humans want to watch the agents and oversee their work
- Human users also operate in teams and so they need their own logins, profiles, views etc.
- So we have a multi-user system for humans
- But humans want to be able to update their own profile picture and avatar
- But the avatar upload form wasn't saving the avatar to the file storage system
- So this PR fixes the avatar upload form to use the file storage service
- The benefit is we don't have a one-off file storage for just one aspect of the system, which would cause confusion and extra configuration
Then have the rest of your normal PR message after the Thinking Path.
This should include details about what you did, why you did it, why it matters & the benefits, how we can verify it works, and any risks.
Please include screenshots if possible if you have a visible change. (use something like the agent-browser skill or similar to take screenshots). Ideally, you include before and after screenshots.
Questions? Just ask in #dev — we're happy to help.
Happy hacking!