Database review skill for the JPPhotoManager web backend (PostgreSQL via Flyway + Spring Data JPA). TRIGGER when adding or reviewing a Flyway migration, a JPA entity, a repository `@Query`, or a database view/function — including when implementing OpenSpec tasks that touch the schema. Do not wait to be asked: review new/changed migrations proactively. Checks normalization, index coverage, whether repository queries actually use the indexes that exist, views/functions, column naming standards, data types, and cross-datastore consistency for tables mirrored into Redis/MongoDB. Also TRIGGERS when asked to audit the entire migration history for schema drift or missing indexes. Also TRIGGERS when asked to fix, address, resolve, or work through findings from an existing dated DATABASE_REVIEW_FINDINGS report — see "Fix Workflow" below.
Routine dependency-upgrade workflow for the JPPhotoManager web application (Maven backend + npm frontend). TRIGGER when asked to upgrade dependencies, bump package versions, check for outdated packages, or do routine dependency maintenance. This is distinct from `security-reviewer` §1, which reactively flags dependencies with a known CVE while reviewing code — this skill proactively drives the update-and-regression-test cycle itself, on a cadence, whether or not anything is currently flagged as vulnerable.
End-to-end testing skill for the JPPhotoManager web application (Spring Boot 3.4 / Java 21 backend + Angular 19 frontend). TRIGGER when asked to run or verify E2E behaviour after completing a feature — especially for UI-facing changes to the dashboard, gallery, or any user flow. Covers: starting prerequisites, API response verification, SSE progress-stream verification, visual screenshot capture via Puppeteer, interactive navigation checks, and an optional multi-replica Kafka/Redis consistency check for changes touching consumer-group or cache-invalidation logic.
Encapsulates the Gitflow branching workflow for this repo (develop as integration branch, main as production branch). TRIGGER when the user asks to start/create a new feature, release, or hotfix branch, when asking to merge/finish a feature, release, or hotfix, when asking to tag a release or hotfix after it has been merged, or when asking to clean up/delete already-merged branches. Phrases like "start a new feature", "create a release branch", "start a hotfix", "merge the feature", "finish the feature", "merge the release", "finish the hotfix", "tag the release", "clean up the branches", "delete merged branches" all trigger this skill. Also drafts CHANGELOG.md release notes right after tagging a release/hotfix.
Production incident triage and rollback playbook for the JPPhotoManager web application (Kubernetes/Docker Compose deploy, Postgres/Mongo/Redis/ Kafka backing services). TRIGGER when asked to diagnose a production issue, a failed or bad deploy, a stuck catalog/sync/convert/upload job, a crash-looping pod, or whether to roll back a recent release/hotfix. Also TRIGGERS when asked to investigate why a feature that worked in E2E testing is broken after deployment. Do not perform any rollback or data-affecting action without explicit user confirmation — this skill triages and recommends; it does not execute destructive recovery steps unsupervised.
Kafka event/messaging conventions for the JPPhotoManager Spring Boot backend. TRIGGER whenever work adds or changes a `@KafkaListener`, a `kafkaTemplate.send(...)` call, a new event/progress-message DTO in `application/dto/`, or touches `infrastructure/kafka/**` or `UploadProcessorKafkaConfig` — including when implementing OpenSpec tasks that need async processing or cross-instance notification. Do not wait to be asked: apply these conventions proactively whenever new Kafka-backed code is written. Encodes topic naming, the consumer-group decision (shared vs. per-instance), retry/failure handling, and message-key/ordering rules.
Redis caching conventions for the JPPhotoManager Spring Boot backend. TRIGGER whenever work adds or changes a `@Cacheable`/`@CacheEvict` usage, touches `AppConfig.cacheManager()` or any other Redis-backed bean, adds a new named Spring cache, or adds a new non-`@Cacheable` Redis usage (thumbnail L2 cache, refresh-token store, rate limiting) — including when implementing OpenSpec tasks that add caching. Do not wait to be asked: apply these conventions proactively whenever new Redis-backed code is written. Encodes the project's serializer-per-cache rule (a shared polymorphic serializer already broke the `tags` cache once), the fail-open error-handling convention, key-prefix/eviction pattern, and where cache-invalidation triggers must be wired up.
Verifies that a fully-implemented OpenSpec change actually satisfies the acceptance criteria in its own `specs/**/spec.md` files — not just that `tasks.md` is checked off. TRIGGER when asked to check spec compliance, verify a change is ready to archive, or audit whether a change's implementation matches its spec. Also a natural step to run before invoking `openspec-archive-change`, though it does not invoke that skill itself and is not invoked by it. This is a standalone, read-only companion skill — it never edits anything under `openspec/`, and it is not part of the `openspec-*` skill family (propose/explore/apply/archive) and never modifies those skills or their workflow.