Issue 2026-06-16
v0.8.61
CodeWhale
any model, open models first
Contribute · 参与

Contribute

No CLA. No sponsor lockouts. One maintainer. Small, focused PRs land fastest — please bring real test coverage and prose that tells the reviewer what you were thinking.

  1. ①
    选择切入点

    Find a thread to pull

    Browse open issues. The good first issue label means the path is clear. The help wanted label means the path is open but contested. Anything else, ask first.

    Open issues →
  2. ②
    复刻并分支

    Fork and branch

    git clone your fork, then git checkout -b feat/short-name or fix/short-name. We use conventional commits — feat:, fix:, docs:, refactor:, test:, chore:.

    Repo on GitHub →
  3. ③
    本地检查

    Match the local checks

    CI runs cargo fmt --all -- --check, cargo clippy --workspace --all-targets --all-features --locked -- -D warnings, and cargo test --workspace --all-features --locked. Run them before you push.

    Contributing guide →
  4. ④
    提交合并

    Open the PR

    PR description should explain WHY, not WHAT (the diff covers what). Link the issue. The maintainer reviews everything personally — response times vary.

    PR template →
Small-patch prompt · 小补丁提示词

Use CodeWhale on CodeWhale

A good contribution prompt does not reward motion. It asks for one mergeable fact: one real friction point, one small patch, the smallest relevant checks, and the risk a reviewer needs to know.

Contributor guide →
You are running inside CodeWhale.

Improve CodeWhale itself by finding exactly one small, reviewable friction point in the harness, docs, tests, or contributor workflow.

Prefer bug fixes, regression tests, clearer docs, sharper error messages, or one narrow contributor-experience improvement. Do not change product direction, provider policy, telemetry, sponsorship, branding, auth, sandbox, release/publishing, or global prompts unless the maintainer explicitly asked for that exact scope.

Working rules:
1. Inspect the repo and current open issues before editing.
2. Choose one issue, TODO, failing test, docs ambiguity, confusing error, or repeated papercut.
3. State the exact target and why it is small enough to review.
4. Reproduce the problem when possible.
5. Make the minimum patch.
6. Run the smallest relevant checks first.
7. Stop after one patch.

Output: issue summary, files changed, checks run, risks or follow-up, and a suggested PR title.

House rules 规约

Short version: build the thing, don't polish the meta. The fullCode of Conductis the long version.

  • YesBug reports with reproductions, refactors that explain the trade-off, docs PRs that fix a real ambiguity.
  • YesTests that demonstrate the bug — even better than fixes.
  • YesHard questions in Discussions. Even better if you bring data.
  • NoDrive-by AI-generated patches with no understanding of the diff.
  • NoAdding hosted SaaS dependencies, telemetry, or referral links to the codebase or docs.
  • NoRenaming things across the repo to match your preferences.
The dev loop · 开发循环

From clone to merged

The full sequence, copy-pasteable. Stable Rust only — never reach for nightly features.

# fork on github, then:
git clone git@github.com:YOU/CodeWhale
cd CodeWhale
git checkout -b feat/your-thing

# build and run locally
cargo build
cargo run --bin codewhale

# checks (matches CI exactly)
cargo fmt --all -- --check
cargo clippy --workspace --all-targets --all-features --locked -- -D warnings
cargo test --workspace --all-features --locked

# parity gates
cargo test -p codewhale-tui-core --test snapshot --locked
cargo test -p codewhale-protocol --test parity_protocol --locked
cargo test -p codewhale-state --test parity_state --locked

# commit + push + PR
git commit -m "feat: short subject in conventional-commit form"
git push -u origin feat/your-thing
gh pr create --fill