jp-photo-manager

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.

Keeps `JPPhotoManagerWeb/CLAUDE.md`, the reference docs under `JPPhotoManagerWeb/docs/`, and deploy-manifest/observability parity (`docker-compose.yml` ↔ `k8s/*.yaml`; custom Micrometer metrics ↔ the Grafana dashboard) in sync with the actual code. TRIGGER after implementing a feature or OpenSpec change that adds or changes a REST endpoint, a Spring `@Value`/`application.yml` config property, a named Redis cache, a Kafka topic or consumer group, a Flyway migration that changes which datastore owns a table, a frontend route, a Docker Compose/Kubernetes environment variable, or a custom `photomanager_*` metric. Also TRIGGERS when explicitly asked to check, audit, or sync the web app's documentation against the code, or as a standalone full sweep. Do not wait to be asked after a feature lands with any of the above changes — none of this is re-derived automatically, so it drifts silently otherwise.

Orchestrates the full feature lifecycle end-to-end: selects the next feature, proposes SDD artifacts if missing, implements all change tasks, runs code, security, and (when schema files changed) database reviews (findings fixed before continuing), runs backend and frontend tests until they pass, builds updated Docker images and deploys them via Kubernetes (if a live cluster deployment exists) or Docker Compose (if Docker is running), syncs the web app's documentation (CLAUDE.md + docs/*.md) against what actually shipped, verifies the implementation actually satisfies the change's spec scenarios (not just that tasks are checked off) before archiving, then archives the SDD change and marks the feature as implemented. Use when you want a fully automated feature development cycle with minimal manual steps. TRIGGER when the user asks to develop a feature.

Adds a new feature to JPPhotoManagerWeb/docs/backlog/features-planned.md — drafts the row (Priority, Schema Change, Effort, Area, Brief description), assigns the next feature number, and confirms with the user before writing. TRIGGER when the user asks to plan a new feature, add a feature to the backlog, or file a feature idea/request.

Mark features as implemented in JPPhotoManagerWeb/docs/backlog/features-planned.md and move them to JPPhotoManagerWeb/docs/backlog/features-implemented.md. Use when one or more features have been fully implemented and need to be archived.

Recommends which feature to implement next based on JPPhotoManagerWeb/docs/backlog/features-planned.md priorities and dependencies, then asks for user confirmation. Returns the confirmed change name to the caller — does NOT invoke opsx:propose or opsx:apply. TRIGGER when the user asks which feature to implement next, what to work on next, or which feature to suggest — including phrases like "recommend the next feature", "suggest the next feature", "what feature should we do next", or any similar request for a next-step recommendation from the features list.

Reports feature tracking progress by counting rows in JPPhotoManagerWeb/docs/backlog/features-planned.md and JPPhotoManagerWeb/docs/backlog/features-implemented.md. Returns total, implemented, pending, and percent-complete counts, plus a priority-tier and artifacts-readiness breakdown of pending features. TRIGGER when the user asks for a feature status report, progress report, "features vs implemented features", how many features are done/pending, or similar summary requests about the feature backlog.

Code review skill for the JPPhotoManager project (Spring Boot 3.4 / Java 21 backend + Angular 19 frontend). TRIGGER after implementing any feature, fix, or refactor — including after completing an OpenSpec task or a set of tasks. Do not wait to be asked: review code proactively after writing it. Also triggers when explicitly asked to review a pull request, file, or change. Covers both sub-projects (backend and frontend) and all cross-cutting concerns: hexagonal architecture layering, naming, transactions, async, testing, and TypeScript/Java style rules. A full-codebase sweep of the whole web application produces one report per architecture layer instead of a single consolidated report — see "Full-Codebase Sweeps" below. Also TRIGGERS when asked to fix, address, resolve, or work through findings from an existing dated CODE_REVIEW_FINDINGS report — see "Fix Workflow" below.

Security review skill for the JPPhotoManager project (Spring Boot 3.4 / Java 21 backend + Angular 19 frontend). TRIGGER when code touches authentication, authorization, file I/O, user input handling, dependency changes, or data persistence — including when implementing OpenSpec tasks that affect any of these areas. Do not wait to be asked: run this review proactively after writing security-sensitive code. Covers dependency vulnerabilities, sensitive data handling, path traversal, injection, Spring Security misconfigurations, JWT/cookie security, and frontend storage anti-patterns. A full-codebase sweep of the whole web application produces one report per architecture layer instead of a single consolidated report — see "Full-Codebase Sweeps" below. Also TRIGGERS when asked to fix, address, resolve, or work through findings from an existing dated SECURITY_REVIEW_FINDINGS report — see "Fix Workflow" below.

Angular developer skill for writing Angular 19 applications following the JPPhotoManager frontend code style. TRIGGER whenever work touches JPPhotoManagerWeb/frontend — including when implementing OpenSpec tasks: creating or modifying components, services, models, pipes, or routes in an Angular project with a feature-based architecture of core → features ← shared. Invoke this skill proactively — do not wait to be asked.

Java developer skill for the JPPhotoManager Spring Boot 3.4 / Java 21 backend. TRIGGER whenever work touches JPPhotoManagerWeb/backend — including when implementing OpenSpec tasks: adding a new use case, controller, entity, repository, DTO, or enum; fixing a bug in any Java class; refactoring or extracting logic into a new class; wiring up transactions, async operations, or Spring beans. Enforces hexagonal (ports and adapters) architecture (infrastructure/web → application/usecase → domain ← infrastructure/persistence | infrastructure/service), the port-interface / adapter-implementation split for every service and repository, and all other coding standards. Invoke this skill proactively — do not wait to be asked.

JUnit 5 unit and integration test skill for the JPPhotoManager Spring Boot 3.4 / Java 21 backend. TRIGGER when creating, fixing, or updating test files for any backend class: services, repositories, controllers, facades, or entities — including when an OpenSpec task calls for backend tests. Always invoke alongside java-developer when a new backend class is created or substantially modified. Enforces the project's testing conventions: Mockito for mocking, AssertJ for assertions, sut naming, one concept per test, and the method_condition_result naming pattern. Invoke this skill proactively — do not wait to be asked.

Cypress Component Testing skill for writing unit/component tests for the JPPhotoManager Angular 19 frontend. TRIGGER when creating or modifying *.cy.ts test files for standalone components, services, or pipes — including when an OpenSpec task calls for frontend tests. Always invoke alongside angular-developer when a new Angular component or service is created. Enforces the project's strict TypeScript conventions and feature-based architecture. Invoke this skill proactively — do not wait to be asked.