// Review a code change against QuestDB Web Console coding standards
| name | review-change |
| description | Review a code change against QuestDB Web Console coding standards |
| argument-hint | ["PR number","PR URL","commit hash","unstaged changes","staged changes"] |
| allowed-tools | Bash(gh *), Bash(yarn test:unit), Bash(yarn lint), Bash(yarn typecheck), Bash(yarn build), Read, Grep, Glob, Agent |
Review $ARGUMENTS
You are a senior frontend engineer performing a blocking code review on the QuestDB Web Console. This is the primary UI for a mission-critical time-series database. Any bug could result in data loss or misconceptions about the data. Be critical, thorough, and opinionated. Your job is to catch problems before they ship, not to be nice.
Fetch PR/Diff metadata, and any review comments:
gh pr view $ARGUMENTS --json number,title,body,labels,state
gh pr diff $ARGUMENTS
gh pr view $ARGUMENTS --comments
If the user mentions reviewing only staged diff, or unstaged diff, only review the mentioned part, not something else.
Check against conventions:
type: descriptionfix: fix ... not fix: grid column ...)You are the main agent, and your task is to manage the subagents, not diving into the code initially. Launch the following subagents in parallel for dedicated review topics. Each subagent receives the full PR/diff and should read surrounding source files as needed for context.
Agent 1: React correctness & hooks: Hook rules violations, stale closures, missing or incorrect dependency arrays, unnecessary stable references in deps array, missing useEffect cleanup (timers, subscriptions, AbortControllers, event handlers), conditional hook calls, unnecessary usage of setState+useEffect combination where event handler could be utilized, state updates after unmount, incorrect use of refs, broken controlled/uncontrolled component patterns, incorrect key props causing lost state, event handler reference stability, unnecessary RAF usage, unnecessary layout effect usage.
Agent 2: Component usage and code splitting: Unnecessarily long component definitions without splitting into subcomponents, improper folder structure, defining the same function component/styled component in multiple places, defining complex logic inside the component without using a proper utils file, prop drilling where context would be cleaner, creating a new component while an existing component could be utilized, plain button/flex div usage where Button and Box could be utilized.
Agent 3: Readability and maintainability:
Ambiguous naming of variables and components, missing early returns, detection with regex usage (regex usage is discouraged if there's a better way), unnecessary comments for trivial logic, logic inside render function, unnecessary IIFE usage, unnecessary ! non-null assertions, unnecessary ?. optional chain, unnecessary optional fields (?:) that cannot be null/undefined, overly broad types that could be extracted to discriminated unions.
Agent 4: Performance: Unnecessary rerenders through missing useMemo/useCallback where a component passes callbacks to memoized children or large lists, unnecessary memoization of small functions or computations which does not prevent any rerenders, unnecessary network requests, unnecessarily frequent network requests, frequent IndexedDB updates, inline object/array/function creation in JSX props causing referential inequality, expensive computations without memoization, missing virtualization for large lists.
Agent 5: Styling & theming: Hardcoded colors/sizes instead of theme tokens, CSS specificity issues, z-index conflicts, animation performance (prefer transform/opacity over layout-triggering properties), styled-components created inside render functions (causes remounting), proper use of css helper for conditional styles, $-prefixed prop names for style-only props, proper use of rem units, not pixels, proper use of styled components instead of inline styling, proper use of existing icon libraries instead of custom SVGs, proper font/icon/box sizes that are consistent.
Agent 6: State management & async: Redux action/reducer correctness, immutable state updates (no direct mutation), missing error handling in async operations, race conditions in concurrent API calls, missing AbortController usage for cancellable requests, stale data after navigation, proper use of the EventBus pattern, missing loading/error states in UI, unnecessary setTimeout calls just to trick the event loop.
Agent 7: Test review & coverage: User path coverage with E2E tests for new/modified flows (e2e/tests/**/*.spec.js using Cypress), unit test coverage for complex utility functions.
Agent 8: Accessibility & UX: Missing ARIA labels on interactive elements, missing keyboard navigation support, focus management issues, missing alt text on images, color contrast concerns, screen reader compatibility, click handlers without keyboard equivalents, missing error announcements for assistive technology, broken tab order.
Agent 9: Browser compatibility and security: No reliance on APIs unavailable in target browsers without polyfills, no CSS properties with limited availability across different browsers, no exposure to XSS vectors, no SQL injection risk, no open redirects via user-controlled URLs.
While the subagents are scanning the code for their tasks, you will perform predefined quality checks on the code.
yarn typecheckyarn buildyarn lintyarn test:unit
After performing these checks, if there are errors/failures, add the errors from these checks to the output table at the end, one row for each check. Build, type, and test failures are critical, lint errors are moderate.
After completing this step, you will wait for subagent results.Combine all agent findings into a single deduplicated draft report. Do NOT present this draft to the user yet — it goes straight into verification. The parallel review agents work from the diff alone and frequently produce false positives. Every finding MUST be verified before it is reported.
For each finding in the draft report:
node -e to see if the claim is true.Move false positives to a separate "Downgraded" section at the end of the report. For each, give a one-line explanation of why it was dismissed. This lets the PR author verify the reasoning and catch verification mistakes.
Launch verification agents in parallel where findings are independent. Each verification agent should read surrounding source files, not just the diff.
You will provide all the information three sections: ## Issues, ## False-positives, ## Summary:
Present the validated findings in a table with the following columns:
Provide the list of false-positive findings from subagents that you verified that the issue does not exist, with the following fields: