|
| 1 | +# Contributing to CShip |
| 2 | + |
| 3 | +Thank you for contributing! This guide explains how to get your changes ready to pass CI. |
| 4 | + |
| 5 | +## Prerequisites |
| 6 | + |
| 7 | +- [Rust toolchain](https://rustup.rs) (stable) |
| 8 | + |
| 9 | +## Running checks before submitting a PR |
| 10 | + |
| 11 | +CI enforces four checks. Run them locally before pushing: |
| 12 | + |
| 13 | +```sh |
| 14 | +# 1. Format — CI runs `cargo fmt --check`; fix formatting first |
| 15 | +cargo fmt |
| 16 | + |
| 17 | +# 2. Lint — all Clippy warnings are treated as errors |
| 18 | +cargo clippy -- -D warnings |
| 19 | + |
| 20 | +# 3. Tests |
| 21 | +cargo test |
| 22 | + |
| 23 | +# 4. Release build |
| 24 | +cargo build --release |
| 25 | +``` |
| 26 | + |
| 27 | +If any of these fail locally, they will fail in CI. Fix them before opening a PR. |
| 28 | + |
| 29 | +## Adding a new module |
| 30 | + |
| 31 | +### BMAD (Recommended) |
| 32 | + |
| 33 | +This project is built with [BMAD](https://github.com/bmad-code-org/BMAD-METHOD). |
| 34 | + |
| 35 | +1. Install BMAD in this repo. `npx bmad-method install` |
| 36 | +2. Run `/bmad-quick-dev` with a GitHub issue URL or a description of your change — it guides you from intent through spec, implementation, and review. |
| 37 | + |
| 38 | +### Manual (Not recommended) |
| 39 | + |
| 40 | +See the non-negotiable code patterns in `CLAUDE.md`. |
| 41 | + |
| 42 | +- Create `src/modules/{name}.rs` and update `src/modules/mod.rs`. If the module needs config fields, also add a struct to `src/config.rs`. |
| 43 | +- Module signature: `pub fn render(ctx: &Context, cfg: &CshipConfig) -> Option<String>` |
| 44 | +- All config structs go in `src/config.rs` with `#[derive(Debug, Deserialize, Default)]` and `pub Option<T>` fields. |
| 45 | +- Absent data → explicit `match` + `tracing::warn!` + `None`. Disabled flag → silent `None`. (Exception: `context_bar` renders an empty bar with `tracing::debug!` when context data is absent — this is intentional UX.) |
| 46 | + |
| 47 | +## Updating documentation |
| 48 | + |
| 49 | +Most documentation lives in `docs/`; `CONTRIBUTING.md` at the repo root mirrors `docs/contributing.md` (see the last bullet). Update the relevant files alongside your code change: |
| 50 | + |
| 51 | +- **New module or config field** — add the config option to `docs/configuration.md`. If the module has non-obvious UX, add a `docs/faq.md` entry too. |
| 52 | +- **Removed module or config field** — delete or mark deprecated the corresponding entry in `docs/configuration.md`. |
| 53 | +- **Behaviour change** — update any affected section in `docs/configuration.md` or `docs/faq.md`. |
| 54 | +- **New showcase or example** — add the `cship.toml` config block to `docs/showcase.md` and place any screenshot or GIF in `docs/examples/`. |
| 55 | +- **This guide** — `CONTRIBUTING.md` (repo root) and `docs/contributing.md` are kept in sync manually; if you edit either for any reason, update the other to match. |
| 56 | + |
| 57 | +## Opening a PR |
| 58 | + |
| 59 | +1. Make sure all four checks above pass. |
| 60 | +2. Describe what your change does and why in the PR description. |
| 61 | +3. Reference any related issues with `Closes #<issue-number>`. |
0 commit comments