|
| 1 | +# GitHub Copilot Code Review Instructions |
| 2 | + |
| 3 | +When performing a code review, respond in English. |
| 4 | + |
| 5 | +## Architecture & Patterns |
| 6 | + |
| 7 | +When performing a code review, ensure new public types are properly exported via `src/lib.rs` for UniFFI binding generation. |
| 8 | + |
| 9 | +When performing a code review, verify that modules follow the established structure: `mod.rs`, `types.rs`, `errors.rs`, `implementation.rs`, and optional `tests.rs`. |
| 10 | + |
| 11 | +When performing a code review, check that UniFFI-exported types follow existing patterns (derive macros, enum representations, error types). |
| 12 | + |
| 13 | +## Error Handling & Safety |
| 14 | + |
| 15 | +When performing a code review, flag any use of `unwrap()` or `expect()` in non-test code and suggest proper error propagation with `?` or `Result`. |
| 16 | + |
| 17 | +When performing a code review, ensure error types implement proper `Display` and `Error` traits and are exported for UniFFI. |
| 18 | + |
| 19 | +When performing a code review, flag any `unsafe` blocks and verify they are necessary and well-documented. |
| 20 | + |
| 21 | +## Code Quality & Readability |
| 22 | + |
| 23 | +When performing a code review, ensure `cargo clippy` warnings are addressed — the project treats clippy warnings as errors. |
| 24 | + |
| 25 | +When performing a code review, verify that `cargo fmt` formatting is applied consistently. |
| 26 | + |
| 27 | +When performing a code review, focus on readability and avoid deeply nested match arms, replacing with early returns or helper functions where possible. |
| 28 | + |
| 29 | +When performing a code review, ensure unused code is removed after refactoring. |
| 30 | + |
| 31 | +When performing a code review, verify that existing utilities and helper functions are reused rather than creating duplicates. |
| 32 | + |
| 33 | +## Dependencies & Platform |
| 34 | + |
| 35 | +When performing a code review, verify that platform-specific dependencies use correct `#[cfg(target_os)]` guards (especially Trezor: BLE-only on iOS, USB+BLE elsewhere). |
| 36 | + |
| 37 | +When performing a code review, check that new dependencies are justified and don't introduce unnecessary bloat to the FFI binary. |
| 38 | + |
| 39 | +## Testing |
| 40 | + |
| 41 | +When performing a code review, suggest tests for new functionality covering the most important cases. |
| 42 | + |
| 43 | +When performing a code review, verify that tests use the established patterns (test modules in `tests.rs`, `#[cfg(test)]` gating). |
| 44 | + |
| 45 | +## Bitcoin & Lightning Specific |
| 46 | + |
| 47 | +When performing a code review, verify that Bitcoin/Lightning operations use proper types from the `bitcoin` and `bdk` crates. |
| 48 | + |
| 49 | +When performing a code review, verify that proper Bitcoin and Lightning technical terms are used when naming code components. |
| 50 | + |
| 51 | +## Build & Version |
| 52 | + |
| 53 | +When performing a code review, check that version changes are synchronized across `Cargo.toml`, `Package.swift`, and `bindings/android/gradle.properties`. |
| 54 | + |
| 55 | +When performing a code review, verify that changes to public API types don't break existing UniFFI bindings without updating the binding generation. |
0 commit comments