Mill is solo-maintained. Contributions are welcome, but the process is kept deliberately light — there's no separate contributor doc to maintain in parallel with reality.
- Read
CLAUDE.mdfirst. It's the actual working process for this repo (Research → Plan → Implement, coding conventions in.claude/rules/), not an AI-only artifact — it applies whether you're a human or an agent making the change. - Open an issue before a large PR. Small fixes (typos, an obvious bug with an obvious fix) can go straight to a PR. Anything that adds a capability, changes a schema, or touches more than a couple of files should start as an issue so the approach can be agreed before the work is done — the maintainers keep a living spec of what Mill is and why, and a PR that conflicts with it needs to resolve that first.
- Run the local checks before opening a PR.
task setup:hooksinstalls Lefthook's pre-commit hooks, which mirror what CI runs (lint, vet, build, the file-length and root-layout checks). A PR that fails CI'sci-gaterequired check won't merge. - Tests are part of the change, not a follow-up. See
.claude/rules/testing.mdfor what layer a given bug or feature's proof belongs at.
See the README for the clone-and-run steps.
Use the bug report issue template. It's short by design: what happened,
what you expected, your macOS version, and the build-identity badge
value shown in Mill's own UI (DEV · live / INSTALLED · <commit> /
SERVER · <commit>) — that one field tells us exactly which build you
were running.
Don't open a public issue — see SECURITY.md.