name: code-review-and-security-audit description: Review code for quality, correctness, and security vulnerabilities. Use when the user asks to review code, audit for security issues, or check for bugs and anti-patterns. argument-hint: file path, component name, or scope of review
Code Review and Security Audit
You are performing code review and security auditing for Guileless Bopomofo.
Scope
This skill covers two complementary concerns:
- Code Review — correctness, readability, maintainability, and adherence to project conventions.
- Security Audit — identifying vulnerabilities, unsafe patterns, and potential attack surfaces.
Review Checklist
Code Quality
- Null safety: proper use of Kotlin null-safe operators; avoid
!!unless justified. - Thread safety: correct use of coroutines, synchronized access to shared state.
- Resource management: no leaked cursors, streams, or native resources.
- Error handling: appropriate use of try/catch; no silently swallowed exceptions.
- Consistency: follows existing patterns in the codebase (EventBus for events, ViewBinding for views, etc.).
- No dead code, unused imports, or redundant logic.
Code Smells
- Long methods: methods doing too many things; should be broken into smaller, focused functions.
- Large classes: classes with too many responsibilities; consider splitting by concern.
- Duplicated code: repeated logic that should be extracted into a shared function.
- Deep nesting: excessive
if/when/trynesting that harms readability; consider early returns or extraction. - Magic numbers/strings: unexplained literal values that should be named constants.
- Feature envy: a method that uses another class's data more than its own.
- Inappropriate intimacy: classes that depend too heavily on each other's internals.
- Primitive obsession: overuse of primitives where a domain type (enum, data class) would be clearer.
- Long parameter lists: functions with many parameters; consider grouping into a data class or builder.
- Mutable shared state: prefer immutable data and local state; flag unnecessary
varor global mutable collections.
Code Refactoring Suggestions
- Extract method: identify blocks of code within a method that perform a distinct task and can be extracted.
- Extract class/interface: when a class handles multiple responsibilities, suggest splitting into focused classes or introducing an interface.
- Replace conditional with polymorphism: complex
when/if-elsechains that switch on type can often be replaced with polymorphic dispatch. - Introduce sealed class/enum: when a set of related constants or states is represented loosely (strings, ints), suggest modeling with a sealed class or enum.
- Use Kotlin idioms: replace Java-style patterns with idiomatic Kotlin — e.g.,
let/apply/alsoscope functions, destructuring, extension functions,buildList/buildString. - Simplify lifecycle management: leverage
lifecycleScope,repeatOnLifecycle, orLifecycleObserverto reduce manual lifecycle bookkeeping. - Reduce coupling: identify tight coupling between components and suggest dependency injection, event-driven patterns (EventBus is already used), or interface abstractions.
- Consolidate duplicate logic: when similar logic appears in virtual and physical key handlers (
keys/virtual/vskeys/physical/), suggest a shared base or utility. - Improve testability: flag code that is hard to unit test (e.g., direct static calls, hidden dependencies) and suggest restructuring for easier testing.
JNI / Native Security
This project bridges Kotlin and native C/C++ via JNI. Pay special attention to:
- Buffer overflows: check that JNI string and array operations use correct lengths.
- Null pointer dereference: validate JNI references before use (e.g.,
FindClass,GetMethodIDreturn values). - JNI reference leaks: ensure local references are released when no longer needed, especially in loops.
- Input validation: verify that data crossing the JNI boundary is validated on both sides.
- Memory management: check for proper allocation/deallocation of native memory.
- Review
app/src/main/cpp/libchewing_android_jni.cppas the primary JNI surface.
Android-Specific Security
- Input method security: as an IME, this app handles all user keystrokes. Ensure no logging or leaking of user input.
- SharedPreferences: verify no sensitive data is stored in plain text.
- Intent handling: check for intent injection or unvalidated intent extras.
- WebView (if applicable): check for JavaScript injection, insecure
addJavascriptInterfaceusage. - Export controls: verify that components (activities, services, receivers) are not inadvertently exported.
- ProGuard/R8: ensure obfuscation rules don't strip security-critical code.
General Security
- No hardcoded secrets, API keys, or credentials.
- No command injection via
Runtime.exec()orProcessBuilder. - No path traversal vulnerabilities in file operations.
- No insecure random number generation for security-sensitive operations.
- Dependencies: check for known vulnerabilities in third-party libraries.
Output Format
Report findings using this structure:
Critical / High
Issues that must be fixed — security vulnerabilities, crashes, data loss risks.
Medium
Issues that should be fixed — logic bugs, thread safety concerns, code smell.
Low / Informational
Suggestions for improvement — style, readability, minor optimizations.
For each finding, include:
- File and line number (e.g.,
Chewing.kt:42) - Description of the issue
- Impact — what could go wrong
- Recommendation — how to fix it, with code if appropriate
How to Run
When invoked without arguments, review recently changed files:
git diff --name-only HEAD~5
When invoked with a specific scope (file, directory, or component name), focus the review on that area.
For a full audit, systematically review:
- JNI layer (
app/src/main/cpp/) - Service layer (
GuilelessBopomofoService.kt) - Data handling (
Chewing.kt,ChewingBridge.kt) - UI layer (key handlers,
KeyboardPanel.kt) - Configuration (
AndroidManifest.xml, ProGuard rules) - Dependencies (
gradle/libs.versions.toml)