Thanks for taking a look at zorp. It's early and moving fast, so please read this before sending a PR.
For anything beyond a small fix (typos, docs, obvious bugs), open an issue first to discuss the change. This avoids wasted work on PRs that don't fit the project's direction.
Read AGENTS.md for the tool-agnostic project instructions,
docs/superpowers/specs/ for the approved
designs, and docs/decisions/ for the product and
architecture decision log. Check there before proposing something that's
already been decided against.
Requires protoc (the Protocol Buffers compiler), needed to build the
lance-encoding dependency. Install it with your package manager, e.g.
brew install protobuf (macOS) or apt-get install protobuf-compiler
(Debian/Ubuntu).
git clone https://github.com/aviskaar/zorp.git
cd zorp
cargo build --workspace --exclude zorp-trackzorp-track bundles DuckDB and pulls in LanceDB/Arrow/DataFusion,
which take 20-30 minutes to compile cold. The command above skips it;
drop --exclude zorp-track only when you're touching zorp-track or
the research feature, and budget time for that first build.
cargo test --workspaceThe research feature (validate, investigate, co-write, deliver
capabilities) isn't exercised by the default test run. If you touch
zorp-agent research-feature code, also run:
cargo test -p zorp-agent --features researchBoth must pass before a PR is reviewed. Note that CI only runs
cargo test --workspace --exclude zorp-track (see
docs/DECISIONS.md, 2026-08-13): zorp-track and
the research feature depend on duckdb (bundled) and lancedb,
which are too slow to cold-compile on every CI run. Running both
commands above locally before opening a PR is on you.
- Prose in docs, commit messages, and comments should read plainly: no em dashes or en dashes as punctuation, short direct sentences.
- Follow existing code patterns in the crate you're touching.
src/,zorp-agent/,zorp-mcp/,zorp-eval/are inherited harness code;zorp-track/and the four research capabilities are zorp-specific. Keep new zorp-specific work clearly separated from inherited harness code. - No unnecessary abstractions, comments that restate the code, or speculative features. Keep changes scoped to what the issue asks for.
- Keep PRs focused on one change.
- Include or update tests for behavior changes.
- Update relevant docs (
README.md,docs/decisions/, the design spec the change belongs to) when a change affects them. - CI (build + test) must pass.
Open a GitHub issue with steps to reproduce, expected vs. actual behavior, and your environment (OS, Rust version).