Contributions are welcome. This document explains the workflow.
Open an issue. Use a clear title and include enough context to reproduce the problem or understand the request.
- Fork the repo
- Create a branch from
development(see naming below) - Make your changes
- Open a PR targeting
development
main is protected. All changes go through development first.
Branches follow this pattern:
<type>/<issue-number>-<short-description>
| Type | When to use | Example |
|---|---|---|
feat |
New functionality | feat/5-add-topic-files |
fix |
Bug fix | fix/3-precompact-hook-merge |
refactor |
Code restructure, no behavior change | refactor/8-simplify-init |
docs |
Documentation only | docs/2-usage-examples |
chore |
Maintenance, deps, CI | chore/10-update-dependencies |
If there's no issue yet, create one first so there's a number to reference.
This project uses Conventional Commits (lowercase):
<type>(<scope>): <description>
Examples:
fix(init): prevent overwrite of existing memory files
feat(protocol): add topic file distillation rules
docs: add installation examples
refactor(install): split bash and npx paths
Rules:
- Lowercase everything
- Imperative, present tense ("add" not "added")
- No period at the end
- Reference the issue in the body or footer:
Closes #7
PR titles follow the same convention, referencing the issue number as scope:
fix(#3): prevent precompact hook merge failure
feat(#5): add topic file support
docs(#2): expand usage examples
- Run
cargo fmt && cargo clippy && cargo testbefore submitting — no warnings or test failures - Keep changes focused — one issue per PR