| 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/try nesting 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
var or 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-else chains 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/also scope functions, destructuring, extension functions, buildList/buildString.
- Simplify lifecycle management: leverage
lifecycleScope, repeatOnLifecycle, or LifecycleObserver to 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/ vs keys/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, GetMethodID return 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.cpp as 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
addJavascriptInterface usage.
- 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() or ProcessBuilder.
- 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)
Task: $ARGUMENTS