arjunrajlaboratory

Use when reviewing code changes on a feature branch before merging, or when the user asks for a code review, PR review, or branch diff analysis. Compares against a base branch (default: master). Checks both frontend and backend: looped DB/API calls (the #1 review issue), API vs model layer separation (models must not raise RestException), raw PyMongo usage, missing exc=True on model loads, broad exception handling, access control and permission escalation, code factorization, redundant validation, naming clarity, API calls in Vue components instead of GirderAPI.ts, unnecessary temporary variables, and TypeScript type safety. Use this skill even for small PRs — single-file backend changes often have layer violations or missing batch queries.

Use when writing or modifying Python code in the Girder backend plugin (devops/girder/plugins/AnnotationPlugin/), creating REST API endpoints, writing database queries with MongoDB, implementing access control and sharing, running backend tests with tox/pytest, or debugging Docker compose services. Covers: API vs model layer separation (API raises RestException, models raise ValueError — never mix these), API endpoint patterns (@autoDescribeRoute, modelParam), access control (AccessType, setUserAccess, setPublic, permission escalation risks), database queries (Model.find not collection.find, batch $in queries not loops), model loading (exc=True not manual null checks), error handling (catch specific exceptions, never except Exception), public endpoint input validation (inline isinstance guards → RestException 400, MAX_* clamps, bson InvalidId → 400), loading plugin changes into the running container (rebuild, not restart), and backend test patterns. Use this skill even for small backend changes.

Use when authenticating with the local Girder backend, using the nimbusimage Python API for scripting, making curl requests to REST API endpoints, querying MongoDB directly via docker exec, checking Docker container logs, or debugging backend issues at runtime. Covers: nimbusimage Python package (high-level and low-level API), authentication (token retrieval, API keys), endpoint name mapping (upenn_annotation not annotation), curl templates for all plugin endpoints, direct MongoDB shell access, container management, and step-by-step test scenarios for verifying backend changes.

Use when writing or modifying Vue 3 components, Vuex store modules, TypeScript interfaces, or Vuetify 4 UI in the src/ directory. Covers: <script setup> composition API, vuex-module-decorators (@Module, @Action, @Mutation), Vuetify 4 theming (CSS Cascade Layers, light/dark mode), select slot patterns (no .raw wrapper), dialog patterns, API client usage (GirderAPI.ts, AnnotationsAPI.ts), logging utilities (logWarning/logError instead of console.*), button conventions (5-role taxonomy — primary/secondary/tertiary/destructive/icon-only — with required variant and size), button loading states, @girder/components compatibility, and style guidelines.

Use when the user pastes code-review findings (Codex comments, /branch-review output, PR review comments) and asks to fix or address them, or points at a review/findings doc in codebaseDocumentation/ to work through. Trigger phrases: 'here are some codex comments', 'fix these findings', 'address the review', 'go over those and fix as needed'.

Use when verifying NimbusImage changes in a live browser tab (localhost:5173) — clicking UI, driving drawing tools, reading store state from the console, measuring render performance, or reproducing a reported UI bug. Use BEFORE claiming any user-facing change works: tsc/lint/vitest green does not mean the UI works.

Use when working with GeoJS in AnnotationViewer.vue or ImageViewer.vue — adding/removing/reusing annotation features, the draw path, coordinate handling, drawing-tool interaction events, or writing/debugging AnnotationViewer.test.ts. Symptoms this skill explains: annotations invisible though layer.annotations() has them, features drifting off-image or mirrored after re-add, dots in bands above/below the image, live drag positions not updating, annotations vanishing after z-scrubbing.

Use when the user asks for a handoff prompt, a continuation prompt, or a prompt to continue work in a fresh context window — often phrased as 'give me a handoff prompt', 'I'll clear context', 'so I can continue in a new session'. Also use when wrapping up a session on a multi-session feature branch and the user asks what's next.

Runtime NimbusImage/Girder API reference for worker code. Use for image loading, annotation CRUD, property values, channel merging, coordinate conversions, local API tests, or infrastructure errors such as HTTP 500. Use nimbus-worker-scaffold to create a new worker and nimbus-worker-hardening to diagnose or sweep failures in existing workers.

Harden existing NimbusImage workers by diagnosing production crashes, generalizing the failure, sweeping sibling workers, and adding shared regression coverage. Use for stack traces or requests such as harden, make robust, fix and apply to all workers, or audit siblings; especially IndexRange, channelCheckboxes, geometry, batch-coordinate, tags, and dependency failures. Use nimbus-worker-scaffold for new workers and nimbus-interface for API reference.

Scaffold a new NimbusImage Docker worker end to end, including entrypoint, Dockerfiles and GPU labels, tests, Compose registration, WORKERNAME.md, and REGISTRY.md. Use when adding, creating, or porting a new annotation, property, image-processing, ML, or test worker. Use nimbus-worker-hardening for existing-worker fixes and nimbus-interface for runtime API details.

Runtime NimbusImage/Girder API reference for worker code. Use for image loading, annotation CRUD, property values, channel merging, coordinate conversions, local API tests, or infrastructure errors such as HTTP 500. Use nimbus-worker-scaffold to create a new worker and nimbus-worker-hardening to diagnose or sweep failures in existing workers.

Harden existing NimbusImage workers by diagnosing production crashes, generalizing the failure, sweeping sibling workers, and adding shared regression coverage. Use for stack traces or requests such as harden, make robust, fix and apply to all workers, or audit siblings; especially IndexRange, channelCheckboxes, geometry, batch-coordinate, tags, and dependency failures. Use nimbus-worker-scaffold for new workers and nimbus-interface for API reference.

Scaffold a new NimbusImage Docker worker end to end, including entrypoint, Dockerfiles and GPU labels, tests, Compose registration, WORKERNAME.md, and REGISTRY.md. Use when adding, creating, or porting a new annotation, property, image-processing, ML, or test worker. Use nimbus-worker-hardening for existing-worker fixes and nimbus-interface for runtime API details.

Capture documentation screenshots of the NimbusImage app using the chrome-devtools MCP — it renders the WebGL viewer, is authenticated to the local dev server, and writes retina PNGs you crop and commit to .gitbook/assets. Use when taking, refreshing, or updating screenshots of the NimbusImage interface for the GitBook docs.

Playwright-MCP recipes for NimbusImage screenshots, plus tool-agnostic helpers for highlighting elements (red outlines/arrows), cropping, and saving to .gitbook/assets. Prefer the nimbus-screenshots skill (chrome-devtools MCP) for the WebGL viewer; reach here for the highlighting/crop snippets.

Populate the New features page (new-features.md) with user-facing changes from recently merged PRs in the NimbusImage app and ImageAnalysisProject repos. Use when updating the changelog or the "New features" page.

Update NimbusImage GitBook documentation based on any input source (GitHub PR URL, text description, code, markdown docs). Analyzes the input to understand what needs documenting, finds the right location in the existing docs, writes content matching repo conventions, and creates a branch + PR. Use when the user wants to add or update documentation for a new feature, tool, workflow, or concept in the NimbusImage docs.