language-review-checklists-skill

Knowledge extracted from language-reviewer-subagent (kept in sync with the agent's Language Detection & Scope table). Apply only the sections matching the detected language(s); for multi-language changesets apply each and report per-language.

Python Review Checklist

1. PEP 8 & Style
   • Line length <= 88 (black default) or 79 (PEP 8 strict)?
   • Naming: snake_case for functions/variables, PascalCase for classes, UPPER_SNAKE for constants
   • Imports: stdlib → third-party → local, no wildcard imports
   • Docstrings present for public functions/classes (PEP 257)?
2. Type Hints
   • Function signatures have type annotations?
   • Return types specified?
   • Optional[T] used instead of T | None for Python <3.10?
   • typing.Protocol for structural typing over ABC where appropriate?
   • Pydantic models for API boundaries?
3. Pythonic Patterns
   • List/dict/set comprehensions over loops where appropriate?
   • Context managers (with) for resources?
   • Generator expressions for large data (yield)?
   • dataclasses or attrs instead of manual __init__?
   • pathlib.Path instead of os.path?
   • f-strings instead of .format() or %?
4. Error Handling
   • Specific exceptions, not bare except: or except Exception:
   • Custom exception hierarchy for the project?
   • try/except/else/finally used correctly?
   • No silent catches (empty except blocks)?
5. Security
   • No eval(), exec(), or __import__() with user input?
   • SQL parameterization (not string formatting)?
   • No hardcoded secrets or credentials?
   • Input validation at API boundaries?
   • pickle.loads() avoided for untrusted data?
6. Async & Concurrency
   • asyncio patterns correct (no blocking calls in async functions)?
   • async with for async resources?
   • Proper task cancellation and cleanup?
   • Thread safety for shared state?
7. Testing
   • pytest conventions followed?
   • Fixtures used appropriately (not over-mocked)?
   • Parametrized tests for edge cases?
   • Test isolation (no shared mutable state)?

Python Framework-Specific Checks

Backend Patterns: use civiltekk-python-backend-skill (scaffold + patterns routes) for SQLAlchemy detached-instance bugs, Pydantic-on-JSONB pitfalls, async SSE durability, enum strategy resolution, two-phase dataclass initialization, and global _service singletons (prefer FastAPI Depends() with app.state lifecycle).

TypeScript/JavaScript Review Checklist

1. Type Safety
   • No any types (use unknown if truly unknown)?
   • Proper generic constraints?
   • Discriminated unions for state modeling?
   • readonly for immutable data?
   • Proper null/undefined handling (optional chaining, nullish coalescing)?
   • Type guards and narrowing correct?
2. Modern ES Patterns
   • const over let, let over var?
   • Arrow functions for callbacks?
   • Destructuring where appropriate?
   • Template literals instead of string concatenation?
   • async/await over raw promises?
   • ES modules (import/export) over CommonJS?
3. React / Next.js (if applicable)
   • Component naming: PascalCase?
   • Hooks rules followed (no conditional hooks)?
   • Proper useMemo/useCallback (not overused, not missing)?
   • Server vs Client Components correctly separated?
   • Key props on lists (stable, unique)?
   • No prop drilling beyond 2 levels (use context or state management)?
4. Error Handling
   • Proper error boundaries in React?
   • try/catch around async operations?
   • Error types specific (not generic Error)?
   • Proper error propagation in async chains?
5. Security
   • No eval(), Function(), or innerHTML with user input?
   • XSS prevention (proper escaping/sanitization)?
   • No hardcoded API keys or secrets?
   • CORS configured correctly?
   • Input validation with Zod/schemas at API boundaries?
6. Performance
   • Bundle size awareness (no unnecessary imports)?
   • Lazy loading where applicable?
   • Proper memoization strategy?
   • No unnecessary re-renders in React?
   • Efficient data fetching patterns (SWR, React Query)?
7. Testing
   • Jest/Vitest conventions followed?
   • Testing Library patterns (user-centric queries)?
   • Mock usage appropriate (not over-mocked)?
   • Async test patterns correct?

TypeScript/JavaScript Framework-Specific Checks

React Anti-Pattern: civiltekk-react-quality-skill routes hooks-antipatterns (hooks) + render-antipatterns (render). TypeScript DRY: same skill, route ts-dry.

Go Review Checklist

1. Go Idioms
   • Proper package naming (lowercase, single word, no underscores)?
   • gofmt compliant formatting?
   • Exported names have doc comments?
   • Receiver names consistent within a type (not mixing s and self)?
   • Error messages lowercase, no trailing punctuation?
   • go vet clean?
2. Error Handling
   • Explicit error checking (no _ = someFunc())?
   • Errors wrapped with context (fmt.Errorf("doing X: %w", err))?
   • Custom error types for sentinel errors (errors.Is/errors.As)?
   • No panic in library code (only in main/tests)?
3. Concurrency
   • Goroutines properly managed (no leaked goroutines)?
   • Channels vs mutexes chosen correctly?
   • sync.WaitGroup used for goroutine coordination?
   • context.Context passed as first parameter?
   • No shared mutable state without synchronization?
   • select with proper default/cancel handling?
4. Interfaces
   • Small, focused interfaces (1-2 methods)?
   • Interfaces defined by consumer, not producer?
   • Implicit satisfaction (no var _ Interface = (*Type)(nil))?
   • io.Reader/io.Writer patterns followed?
5. Data Structures
   • Slices pre-allocated when size known (make([]T, 0, n))?
   • Maps with proper concurrency protection if shared?
   • Structs organized by field size (alignment)?
   • Proper use of value vs pointer receivers?
6. Testing
   • Table-driven tests with t.Run subtests?
   • Test files in same package (_test suffix)?
   • Benchmark tests (BenchmarkXxx) for hot paths?
   • t.Parallel() where safe?
   • Test helpers use t.Helper()?
7. Performance
   • No unnecessary allocations in hot paths?
   • strings.Builder for string concatenation?
   • sync.Pool for reusable allocations?
   • Proper use of copy() for slice operations?
   • Buffered I/O where appropriate?

Go Framework-Specific Checks

Rust Review Checklist

1. Ownership & Borrowing
   • Borrow checker satisfied without excessive cloning?
   • Lifetimes annotated where needed, elided where possible?
   • No unnecessary Arc<Mutex<T>> when Rc<RefCell<T>> suffices (single-threaded)?
   • Proper use of Cow<str> for borrowed/owned string flexibility?
   • Rc/Arc cycles avoided (no Rc<RefCell> circular references)?
2. Error Handling
   • Result<T, E> used instead of panics for recoverable errors?
   • thiserror/anyhow used appropriately (thiserror for libraries, anyhow for apps)?
   • Error types implement std::error::Error?
   • ? operator used instead of match on Result?
   • No unwrap() or expect() in library code (only in tests/main)?
3. Unsafe Safety
   • unsafe blocks minimized and clearly documented with safety invariants?
   • Raw pointer dereferences justified?
   • No undefined behavior (aliasing violations, uninitialized memory)?
   • unsafe blocks reviewed with extra scrutiny?
4. Idiomatic Patterns
   • Builder pattern for complex construction?
   • From/Into traits for conversions?
   • Iterator trait implemented for custom iterators?
   • newtype pattern for domain primitives?
   • Deref/DerefMut not abused (only for smart pointers)?
   • Proper trait object (dyn) vs generics trade-off?
5. Concurrency
   • Send/Sync bounds respected?
   • Proper channel usage (mpsc, crossbeam)?
   • tokio/async-std patterns correct (no blocking in async)?
   • parking_lot vs std::sync chosen appropriately?
   • Lock ordering consistent to prevent deadlocks?
6. Performance
   • Zero-cost abstractions used (generics, enums, traits)?
   • No unnecessary heap allocations (String vs &str, Vec vs slice)?
   • #[inline] only where benchmarks justify?
   • Proper use of Cow to avoid allocations?
   • Stack allocation preferred where possible?
7. Testing
   • #[test] unit tests present?
   • #[tokio::test] for async tests?
   • Property-based testing (proptest) for complex logic?
   • Integration tests in tests/ directory?
   • Doc tests for public API examples?

Rust Framework-Specific Checks

Java Review Checklist

1. Java Idioms
   • Effective Java compliance (Bloch's items respected)?
   • Naming: camelCase for methods/variables, PascalCase for classes/interfaces, UPPER_SNAKE for constants?
   • Package names lowercase, no underscores, reverse-DNS style?
   • final used for effectively-final locals, parameters, and fields where appropriate?
   • equals/hashCode/toString overridden together (or none)?
   • Checkstyle/SpotBugs clean?
2. Exceptions
   • Checked vs unchecked chosen correctly (checked for recoverable, unchecked for programmer errors)?
   • No swallowed exceptions (empty catch blocks)?
   • Custom exception hierarchy follows RuntimeException base for most modern code?
   • Exceptions chained (new X("msg", cause)) rather than losing the cause?
   • try-with-resources used for all AutoCloseable?
   • No catch (Exception e) or catch (Throwable t) over-broad catches?
3. Generics & Types
   • No raw types (List instead of List<String>)?
   • Generic bounds used correctly (<T extends Comparable<T>>)?
   • PECS principle applied (<? extends T> for producers, <? super T> for consumers)?
   • Diamond operator <> used for instantiation?
   • Generic methods favored over Object + casts?
4. Concurrency
   • java.util.concurrent primitives preferred over synchronized/wait/notify?
   • Proper synchronization of shared mutable state (no data races)?
   • volatile used only for visibility flags, not atomicity?
   • Atomic* classes for atomic counters/references?
   • CompletableFuture composed correctly (no blocking joins in async chains)?
   • ExecutorService shut down properly (try-with-resources or shutdown() in finally)?
   • No shared mutable state across threads without synchronization?
5. Null Handling
   • Optional<T> used as return type for methods that may not return a value (never as field/parameter)?
   • Objects.requireNonNull on constructor/method parameters?
   • Null-annotations (@NonNull, @Nullable) consistent (JSR-305, JSpecify, or Spring)?
   • No Optional.get() without isPresent() check?
   • Stream pipelines null-safe (no null in streams)?
6. Modern Java (11+/17+/21)
   • record for transparent data carriers (vs manual POJO with getters/equals/hashCode)?
   • sealed classes/interfaces used to restrict subtypes?
   • Pattern matching for instanceof (if (o instanceof Foo f))?
   • Switch expressions with arrow syntax and exhaustiveness (esp. with sealed types)?
   • Text blocks ("""...""") for multi-line strings?
   • var used only where type is obvious from initializer (not for "shorter code")?
7. Streams & Collections
   • Stream chains single-purpose and side-effect-free?
   • .collect(Collectors.toList()) produces mutable copy (or .toUnmodifiableList() for immutable)?
   • EnumSet/EnumMap chosen for enum-keyed collections?
   • List.of()/Map.of() for immutable literals (not Collections.unmodifiableList)?
   • No mutation of collection elements inside forEach?
   • No .stream() used purely for iteration (use enhanced for loop)?
8. Resource Management
   • try-with-resources for all Closeable/AutoCloseable (streams, connections, files)?
   • No finalizer methods (finalize()) — deprecated for removal (JEP 421, Java 18+) but NOT yet removed; verify current status before asserting removal.
   • Cleaner used only as last resort for native resources?
   • I/O streams properly chained and closed in correct order?
   • Connection pools (HikariCP) used for database access (not raw DriverManager)?
9. Testing
   • JUnit 5 conventions followed (@Test, @BeforeEach/@AfterEach, @ParameterizedTest)?
   • Mockito patterns clean (no over-mocking; prefer interface mocks over concrete)?
   • AssertJ fluent assertions used (assertThat(x).isEqualTo(y)) over JUnit assertEquals?
   • Test isolation (no shared mutable state across tests)?
   • Test names follow a convention (methodName_state_expected or should_X_when_Y)?
   • No production code reaching into test internals via reflection?
10. Security
    • Input validation at API boundaries (Bean Validation @Valid, manual checks)?
    • SQL via PreparedStatement/JPA named queries — never string concatenation?
    • No Runtime.exec() or ProcessBuilder with user-controlled input?
    • No hardcoded secrets, API keys, or passwords (use env vars / secret managers)?
    • XML parsing hardened against XXE (XMLConstants.FEATURE_SECURE_PROCESSING)?
    • Deserialization of untrusted input avoided (no ObjectInputStream on untrusted data)?

Java Framework-Specific Checks

Java Linting: language-linting-skill for Checkstyle/SpotBugs/PMD command guidance and rule references.

Consumer-Coverage Grep Patterns (no CodeGraph)

Fallback enumeration patterns for the direct-consumer gate, per language:

Python

• Imports: grep -rn 'from\s\+<module>\s\+import\|import\s\+<module>' --include="*.py"
• Symbol usage: grep -rn '\b<SymbolName>\b' --include="*.py"
• Subclass overrides: grep -rn 'class\s\+\w+\s*(.*<BaseClassName>' --include="*.py"
• Decorator usage: grep -rn '@<decorator>' --include="*.py"

TypeScript/JavaScript

• Imports: grep -rn 'import\s\+.*from\s\+[''"]\./.*<module>' --include="*.ts" --include="*.tsx"
• Type references: grep -rn ':\s*<TypeName>' --include="*.ts" --include="*.tsx"
• Component usage: grep -rn '<ComponentName' --include="*.tsx" --include="*.jsx"
• Hook usage: grep -rn '<hookName>\(' --include="*.ts" --include="*.tsx"

Go

• Imported packages: grep -rn '"<pkg/path>"' --include="*.go"
• Symbol usage: grep -rn '\b<SymbolName>\b' --include="*.go"
• Interface implementations: grep -rn 'func\s.*(.*).*<InterfaceName>' --include="*.go"

Rust

• Use statements: grep -rn 'use\s\+crate::<path>::<Symbol>' --include="*.rs"
• Symbol usage: grep -rn '\b<SymbolName>\b' --include="*.rs"
• Trait implementations: grep -rn 'impl\s\+<TraitName>\s\+for' --include="*.rs"
• Macro invocations: grep -rn '<macro_name>!' --include="*.rs"

Java

• Imports: grep -rn 'import\s\+.*\.<ClassName>;' --include="*.java"
• Method calls: grep -rn '\.<methodName>(' --include="*.java"
• Implementations: grep -rn 'implements\s\+.*<InterfaceName>' --include="*.java"
• Subclasses: grep -rn 'extends\s\+<BaseClassName>' --include="*.java"