apache

Sweep open pull requests on the configured `<upstream>` repo, classify each one against the project's quality criteria, propose a disposition, and — on the maintainer's confirmation — carry out the action via `gh`. Disposition options per PR: draft / comment / close / rebase / CI-rerun / workflow-approve / ping-stale-reviewer / request author confirmation of readiness / mark `ready for maintainer review` / promote bot-authored draft. Does **not** perform code review — that lives in `pr-management-code-review`.

Adopt and maintain the apache-magpie framework in a project repo via the snapshot-based adoption mechanism. The only framework skill committed in an adopter's repo; every other skill is a symlink the adopt sub-action wires up. Sub-actions: `/magpie-setup` - first-time adoption (default; main-checkout only) `/magpie-setup upgrade` - refresh the gitignored snapshot per the committed lock (main-checkout only) `/magpie-setup worktree-init` - symlink a worktree's snapshot to the main's `/magpie-setup verify` - health check + drift detection `/magpie-setup skill-sources` - fetch/pin/symlink skills from trusted external sources listed in the adopter trust list (main-checkout only) `/magpie-setup override <skill>` - open or scaffold an agentic override in `.apache-magpie-overrides/` `/magpie-setup unadopt` - reverse the adoption (snapshot, locks, symlinks, hook, doc sections); preserves `.apache-magpie-overrides/` by default (main-checkout only)

Generate a CVE 5.x JSON document from an <tracker> tracking issue, ready to paste into the Vulnogram `#source` tab of the ASF CVE tool at https://cveprocess.apache.org/cve5/<CVE-ID>#source. The conversion is deterministic: same issue in, same JSON bytes out. Handles multiple credits (one per line) and multiple references (URLs extracted from the issue's "Public advisory URL" and "PR with the fix" fields; the "Security mailing list thread" field is treated as internal-only and never exported).

Emit the backend-shaped promotion command set for a release that has passed its vote. Reads the planning issue (must carry `vote-passed`), constructs the staging → release move for the configured distribution backend, checks PMC membership of the Release Manager, and proposes the `promoted` label. Never runs the promotion command itself and never publishes the release.

Emit the paste-ready command sequence to tag an RC, build artefacts, sign each artefact, generate checksums, and stage them to the adopter's distribution backend. Covers Steps 4–5 of the release-management lifecycle. Never runs any command locally — all sequences are emitted for the Release Manager to execute on their own machine with their own key and ASF credentials.

Draft the `[VOTE]` email body and planning-issue comment for an RC of `<upstream>`. Reads RC metadata from the planning issue and `<project-config>/release-management-config.md`; produces a ready-to-copy `[VOTE]` subject + body and a proposed planning-issue comment. Never sends mail and never posts without explicit RM confirmation.

After the approval window closes, fetch the approval signal for an RC of `<upstream>`, classify each reply as +1 / 0 / -1 and binding or non-binding against the configured roster, produce the tally summary, and draft the `[RESULT] [VOTE]` email. Never sends mail and never applies a label without explicit RM confirmation.

Walk a maintainer through deep, sequential code review of open pull requests on the configured `<upstream>` repo. Defaults to the **"my reviews"** queue (the union of five maintainer signals — see the Inputs table); selectors can narrow to a single PR, an area label, or a collaborator subset. Drafts an `approve` / `request-changes` / `comment` review per PR and posts on the maintainer's confirmation.

End-to-end guide on developing new Apache Beam I/O connectors correctly, including core IO transforms, SchemaTransforms, URN proto definitions, Managed API integration, cross-language expansion service, and testing.

Guides development and usage of I/O connectors in Apache Beam. Use when working with I/O connectors, creating new connectors, or debugging data source/sink issues.

Guides YAML SDK development in Apache Beam, including environment setup, testing, and key concepts. Use when working with Beam YAML code in sdks/python/apache_beam/yaml/.

Guide on how to add and propagate new metadata fields in Apache Beam's WindowedValue, extending protos, windmill persistence, and runner interfaces to avoid metadata loss.

Guides understanding and working with Apache Beam runners (Direct, Dataflow, Flink, Spark, etc.). Use when configuring pipelines for different execution environments or debugging runner-specific issues.

Rewrite Apache Beam DoFn methods (@ProcessElement, @OnTimer, @OnWindowExpiration) to remove legacy ProcessContext or OnTimerContext usage. Use this skill when you encounter DoFn methods that use context.element(), context.output(), etc., and need to modernize them using parameter injection (@Element, @Timestamp, @Pane, OutputReceiver, MultiOutputReceiver).

Guides Python SDK development in Apache Beam, including environment setup, testing, building, and running pipelines. Use when working with Python code in sdks/python/.

Guides understanding and using the Gradle build system in Apache Beam. Use when building projects, understanding dependencies, or troubleshooting build issues.

Run a Pinot JMH benchmark twice — once on a baseline commit, once with the current changes — and report both sets of results side by side. Uses a git worktree so the user's working tree is never disturbed.

Pull recent GitHub Actions failures for a Pinot test class and analyze whether they share a root cause. Uses the gh CLI. Surfaces stack traces, failure patterns, and a candidate hypothesis — does not auto-fix.

Run Pinot's mandatory pre-commit checks (spotless, license, checkstyle) and compiler warning checks on only the modules affected by the current diff. Auto-fixes what it can, reports what it can't.

Launch a local Pinot quickstart cluster (batch, hybrid, streaming, upsert, etc.) with the right script, building the binary distribution first if needed.

Review Apache Pinot diffs for architectural concerns — module boundaries, SPI vs. impl separation, circular deps, misplaced logic (broker code in server, server code in controller), abstraction choice (interface vs. abstract class), plugin layering, and layering violations between pinot-spi / pinot-common / pinot-core / pinot-segment-spi / pinot-segment-local. Trigger keywords — new interface, abstract class, package move, module, SPI, broker-server boundary, plugin, shaded.

Review Apache Pinot diffs for concurrency, state management, visibility, atomic state transitions, lock changes, Helix IdealState updates, upsert metadata safety, consumer/stream ingestion races, and shared-observer correctness. Trigger keywords — synchronized, volatile, AtomicReference, ConcurrentHashMap, ReentrantLock, StampedLock, Helix, IdealState, ZkClient, version-checked write, upsert metadata, consumer coordinator, stream partition.

Review Apache Pinot diffs for configuration and backward-compatibility risks. Covers config key renames, SPI signature changes, schema/enum additions, feature-flag defaults, multi-level config override validation, rolling-upgrade safety, REST/JSON/Protobuf field evolution, and segment/DataTable format versioning. Trigger keywords — config key, config rename, SPI, feature flag, enum, schema type, DataTable version, segment version, Protobuf, Thrift, REST endpoint, @Deprecated, mixed-version, rolling upgrade, ZooKeeper schema.

Review Apache Pinot diffs for correctness issues — null handling, type dispatch, numeric precision (INT/LONG/BIG_DECIMAL), exhaustive switch coverage for DataType / IndexType, resource leaks in close/destroy paths, off-by-one errors in row iteration, and silent wrong-result risks. Trigger keywords — null, Nullable, Optional, getStoredType, DataType switch, IndexType switch, close, destroy, realtime persist, precision, BigDecimal, isNullable, null vector.

Mine bug patterns from any git repository. Discovers bug-fix commits via git log heuristics, analyzes each in parallel with subagents, writes individual analysis files, and synthesizes a generalized PATTERNS.md with repo-specific details stripped. Invoke explicitly with /bug-archaeology.

Comprehensive guide for writing Apache Cassandra in-JVM distributed tests (dtests). Use when creating tests that simulate multi-node Cassandra clusters within a single JVM for faster integration testing. Covers cluster creation (single-node, multi-node, multi-datacenter), configuration (all cassandra.yaml parameters, features, network topology), instance lifecycle (startup/shutdown/restart), query execution, message filtering for failure scenarios, running code on instances, ClusterUtils utilities, and debugging classloader-related issues (serialization failures, same-class-different-classloader problems).

Deep file-focused code review for correctness bugs. Unlike shallow-review which runs 6 specialists in parallel across the entire patch, deep-review focuses on user-specified files with full pattern catalogs (500+ patterns), codebase investigation, and source-level context gathering. Use when: the user specifies particular files for focused review, a shallow review flagged areas that need deeper investigation, reviewing critical-path code changes, examining complex serialization/lifecycle/state-machine changes. The user instructs which files to focus on (typically a subset of files in the patch).

Use git heatmap analysis to identify high-churn files and lines as candidates for thorough review or bug hunting. Works for PR reviews, security audits, bug hunts, or any code analysis task.

Multi-pass deep code review for large patches (1000+ LOC) that maximizes real bug detection. Orchestrates targeted-review, shallow-review, and deep-review in parallel across all HIGH and MEDIUM risk files and commits: understands the feature holistically, splits by file and commit, runs deep review on every HIGH/MEDIUM file, targeted review across the same scope, and per-commit shallow review, followed by cross-cut consistency checks. Use when: reviewing a large patch (feature branch, multi-commit, or single large diff, 1000+ LOC), doing a thorough pre-merge review, or when shallower reviews miss bugs due to patch size. Triggers on: "review this branch", "review these commits", "review this feature", "mega review", "thorough review", "full review of X commits", or when the user specifies a commit range or feature for review.

Deep code analysis with ASCII visualizations showing structure, flow, and state transitions. Use when analyzing patches/diffs, explaining classes or subsystems, understanding code architecture, reviewing changes for inconsistencies, or when asked to visualize how code works. Provides before/after diagrams, data/control flow, concurrency analysis, assumptions, and failure modes. Triggers on explain this patch/code/class, how does X work, show me the flow, visualize this change, code review requests, or proactive analysis during PR reviews.

Shallow (quick) ensemble bug-finding review using 6 specialist agents in parallel. Each specialist reviews the same patch through a different lens: Logic & Types, Boundaries & I/O, Concurrency & State, Resources & Serialization, Absence Analysis, and API Completeness. Findings are merged and deduplicated. Best for: quick first-pass review of patches, triage of diffs, broad surface-level bug scan. For deeper file-focused review with full pattern catalogs and codebase investigation, use the deep-review skill instead.

Findings-driven targeted code review. Understands the patch via patch-explainer and surrounding code via codebase-analysis, then consults a catalog of bug patterns (~11 categories under references/categories/). Picks only categories whose diff-signals match the patch and items whose "look for" hints match actual code shapes, groups them by review focus (function/file/feature), and spawns parallel subagents — each with a tight scope and selective checklist. Use for medium-to-large patches (50-1000 LOC) as a focused alternative to whole-patch ensemble or whole-file deep review. Triggers on: "review this patch/diff/change", "find bugs in this change", "scoped review", "what could go wrong here", "review using findings", or proactive PR review.

Upgrade the pinned Flask-AppBuilder (FAB) dependency in the Apache Airflow FAB provider (`providers/fab/`). Bumps the exact `flask-appbuilder==` pin and its mirror constant, regenerates `uv.lock`, drives the `test_fab_alignment.py` drift tripwire, reviews the vendored security-manager `override.py` against the new upstream FAB, and conditionally re-vendors static assets / DB migrations. Use when asked to "upgrade FAB", "bump flask-appbuilder", or move the FAB provider to a newer Flask-AppBuilder release.

Adopt and maintain the apache-magpie framework in a project repo via the snapshot-based adoption mechanism. The only framework skill committed in an adopter's repo; every other skill is a symlink the adopt sub-action wires up. Sub-actions: `/magpie-setup` - first-time adoption (default; main-checkout only) `/magpie-setup upgrade` - refresh the gitignored snapshot per the committed lock (main-checkout only) `/magpie-setup worktree-init` - symlink a worktree's snapshot to the main's `/magpie-setup verify` - health check + drift detection `/magpie-setup skill-sources` - fetch/pin/symlink skills from trusted external sources listed in the adopter trust list (main-checkout only) `/magpie-setup override <skill>` - open or scaffold an agentic override in `.apache-magpie-overrides/` `/magpie-setup unadopt` - reverse the adoption (snapshot, locks, symlinks, hook, doc sections); preserves `.apache-magpie-overrides/` by default (main-checkout only)

Replace the manual commit-by-commit classification step in `breeze release-management prepare-provider-documentation` with AI-driven classification. For each provider with pending changes, analyze every PR (batched into one sub-agent per provider, not one per PR), pay special attention to potentially breaking changes by inspecting the actual diff, scope multi-provider PRs to the current provider's slice, ask the release manager when uncertain, and apply version bumps + changelog entries. Use during the regular provider release cycle as an alternative to the interactive breeze prompts.

Guide for contributing to the Airflow Java SDK (AIP-108). Use this skill whenever a contributor is working in the `java-sdk/` directory or on the Java coordinator in `task-sdk/src/airflow/sdk/coordinators/java/` — whether they want to add a feature, write tests, fix a bug, understand the architecture, or prepare a PR. Trigger on phrases like "Java SDK", "JavaCoordinator", "java-sdk", "annotation processor", "Builder.Task", "BundleBuilder", or anything about running JVM tasks in Airflow.

Guide for implementing a brand-new language SDK for Airflow (AIP-108). Use this skill when a contributor wants to add support for a new programming language — designing the Python coordinator, implementing the wire protocol in the target language, writing the bundle format, and structuring the PR. Trigger on phrases like "new language SDK", "new SDK", "add support for [language]", "implement coordinator for", "SubprocessCoordinator", "BaseCoordinator", "new runtime", "AFBNDL01", "supervisor schema", or anything about bringing a new language into the Airflow executor ecosystem.

Add or update translations for the Apache Airflow UI. Guides through setting up locales, scaffolding translation files, translating with locale-specific guidelines, and validating results. Use when working with i18n tasks in airflow-core/src/airflow/ui/public/i18n/locales/.

Generate verified recipe playbooks from AIPs with PR implementations (post mode), or speculative user stories from AIPs without implementations (pre mode). Use when the user provides an AIP URL or AIP content, optionally with PR URLs and file paths.

Track Airflow Improvement Proposal (AIP) implementation progress by comparing Confluence specs against codebase evidence. Use when asked to assess, report on, or compare AIP status.

Verify, commit, and push changes on a PR branch. Runs pre-flight checks (compile, checkstyle, license headers) before every push. Also creates the PR if one doesn't exist yet.

Add a new monitoring target / layer to SkyWalking OAP. Orients you to the OAL / MAL / LAL / SpanListener / SegmentListener extension points, the UI template + submodule touchpoints, the docs set that must move together, and the cross-cutting traps that don't live in any one skill.

Run SkyWalking E2E tests locally

Rebuild the SkyWalking distribution and OAP Docker image after source changes. Use before running e2e tests so the image reflects your code changes. Avoids the "image looks updated but runtime has stale jars" trap.

Download and inspect CI e2e test logs from GitHub Actions artifacts. Use when investigating e2e test failures in CI.

Generate bytecode classes from DSL scripts (MAL, OAL, LAL, Hierarchy). Runs the compiler and dumps .class files for inspection.

Build SkyWalking OAP server, run javadoc checks, and verify checkstyle. Use to validate changes before submitting a PR.

Check and fix Apache 2.0 license headers and dependency licenses using skywalking-eyes. Use before submitting a PR.

Implements and reviews dubbo-admin Console API changes. Use when the user asks about HTTP endpoints, Gin routes, handlers, request or response models, console services, error handling, API pagination, or the handler to service to manager to store flow under pkg/console/. Do not use for frontend-only, discovery-only, or store-internals tasks unless they affect Console API behavior.

Implements and reviews dubbo-admin registry discovery changes. Use when the user asks about Zookeeper or Nacos discovery, ListAndWatch, informers, discovery factories, discovery subscribers, ServiceProviderMetadata or ServiceConsumerMetadata processing, or Application, Service, RPCInstance, and Instance derivation under pkg/core/discovery/ and pkg/core/controller/. Do not use for engine-sourced RuntimeInstance behavior.

Routes dubbo-admin architecture questions to the right domain skill. Use for cross-module questions, end-to-end flows, subsystem boundaries, or deciding whether runtime, discovery, engine, events, store, Console API, or frontend guidance applies. Prefer a narrower dubbo-admin-* skill when the request clearly targets one subsystem.

Implements and reviews dubbo-admin resource engine changes. Use when the user asks about runtime infrastructure discovery, engine factories, Kubernetes or mock engine ListWatchers, RuntimeInstance informers, RuntimeInstanceEventSubscriber, engine leader election, or merging RuntimeInstance data into Instance resources under pkg/core/engine/ and pkg/engine/. Do not use for registry discovery unless the task concerns engine-sourced RuntimeInstance resources.

Implements and reviews dubbo-admin EventBus dispatching. Use when the user asks about Event, Emitter, Subscriber, SubscriptionManager, EventBus component registration, Subscribe or Unsubscribe behavior, Send dispatch rules, subscriber ProcessEvent flow, resource-kind based routing, or event error handling under pkg/core/events/. Do not use for a domain subscriber unless the task changes the event bus contract or dispatch semantics.

Implements and reviews dubbo-admin Vue 3 frontend changes. Use when the user asks about ui-vue3, Vue views or components, frontend routing, route metadata, API clients, Pinia stores, SearchDomain, i18n, layout tabs, traffic rule form design, frontend tests, or Vite, ESLint, and Prettier configuration. Do not use for Go backend internals unless coordinating an API contract with the frontend.

Implements and reviews dubbo-admin runtime component changes. Use when the user asks about component abstraction, component composition, runtime bootstrap, dependency ordering, registration, lifecycle, startup, shutdown, runtime builder behavior, or pkg/core/runtime/ and pkg/core/bootstrap/. Do not use for discovery, engine, store, Console API, or frontend tasks unless component lifecycle or dependencies are affected.

Implements and reviews dubbo-admin resource storage and indexing changes. Use when the user asks about ResourceStore APIs, store routing, memory store behavior, index registration, IndexCondition, ListByIndexes, PageListByIndexes, ByMeshIndex, radix-tree prefix lookup, or pkg/core/store/, pkg/core/store/index/, and pkg/store/. Do not use for frontend, Console API, discovery, or engine tasks unless they require store or index changes.

Write tests for Apache Iggy connectors - sinks, sources, transforms, SDK, runtime. Covers BDD unit-test naming, the canonical source state round-trip tests, and the real-infra integration test layout under `core/integration/tests/connectors/` with `testcontainers-modules` + `#[iggy_harness]`. Load when writing or reviewing tests in `core/connectors/` or `core/integration/tests/connectors/`. Use for connector test authoring. NOT for runtime internals or non-connector test patterns.

Modify the Apache Iggy Connectors runtime (`core/connectors/runtime/`) - the host process that loads plugins, manages lifecycle, and bridges Apache Iggy streams to plugins via FFI. Use when changing plugin loading, the FFI dispatch, the sink/source manager, state storage, config providers, the HTTP control API, metrics, or transforms wiring. NOT for plugin code.

Extend or modify the Apache Iggy Connectors SDK (`core/connectors/sdk/`). Use when adding a new `Schema` variant, a new `StreamDecoder`/`StreamEncoder`, a new `Error` variant, modifying the `Sink`/`Source`/`Transform` trait surface, the FFI macros, or the `retry`/`api`/`convert` modules. NOT for writing plugins - use `connector-sink` or `connector-source` for those.

Author a new Apache Iggy connector sink plugin under core/connectors/sinks/. Sinks consume messages from Apache Iggy streams and push them to an external system (DB, search engine, HTTP endpoint, object store). Load when creating, modifying, or reviewing a sink crate. Use for sink plugin authoring. NOT for runtime internals (see connector-runtime).

Author a new Apache Iggy connector source plugin under core/connectors/sources/. Sources poll an external system (DB, API, queue) and produce messages into Apache Iggy streams. Load when creating, modifying, or reviewing a source crate. Use for source plugin authoring. NOT for runtime internals (see connector-runtime).

Add a new transform under `core/connectors/sdk/src/transforms/`. Transforms mutate, filter, or convert messages between source/encode and decode/sink. Use when adding field-level transforms (add/delete/update/filter), format conversions, envelope unwrapping, or similar config-driven message manipulations for Apache Iggy connectors. Use for transform authoring. NOT for runtime internals or sink/source loops.

Entry point and index for the Apache Iggy Connectors subsystem (`core/connectors/`). Load this first when working anywhere under `core/connectors/` - runtime, SDK, sinks, sources, or transforms. Routes to the focused per-area skills.

Comprehensive guide for current Grails development, covering web applications, REST APIs, GORM, controllers, services, views, plugins, and testing with Spock and Geb

Expert guide for Groovy 5 development, covering concise syntax, closures, DSLs, metaprogramming, static compilation, and integration with Java 21 and Grails

Guide for developing on the Java 21 baseline, including modern features, best practices, and integration with Groovy/Grails projects

Guide for upgrading Grails applications from Grails 7.x to Grails 8, covering Java 21, Spring Boot 4.1, Spring Framework 7, dependency management, Micronaut, Jackson 3, Hibernate 7, TagLibs, testing, content negotiation, and validation behavior changes

Guide for working in the grails-data-hibernate7 module, especially Hibernate 7 domain binding, mapping migration, generators, and integration tests. Use this when changing code or tests under grails-data-hibernate7.

Guide for running, interpreting, and fixing code style and analysis violations in grails-core using GrailsCodeStylePlugin, GrailsCodeAnalysisPlugin, and GrailsViolationAggregationPlugin — covering CodeNarc, Checkstyle, PMD, SpotBugs, and JaCoCo

Guide for running, reviewing, and fixing test failures across grails-core modules using Gradle test reports

Hamilton UI and SDK patterns for tracking, monitoring, and debugging dataflows. Use for observability, lineage tracking, and production monitoring.

Core Hamilton patterns for creating DAGs, applying decorators, testing, and debugging dataflows. Use for basic Hamilton development tasks.

Systematic 5-step workflow for building Hamilton DAGs - DOT graphs, signatures, validation, TDD implementation. Use this workflow when creating new Hamilton modules from scratch.

Hamilton integration patterns for Airflow, Dagster, FastAPI, Streamlit, Jupyter notebooks, and other frameworks. Use when integrating Hamilton with other tools.

LLM and AI workflow patterns for Hamilton including RAG pipelines, embeddings, vector databases, and prompt engineering. Use for building AI applications with Hamilton.

Interactive Hamilton DAG development via MCP tools. Validate, visualize, scaffold, and execute Hamilton pipelines without leaving the conversation. Use when building or debugging Hamilton dataflows interactively.

Performance and parallelization patterns for Hamilton including async I/O, Spark, Ray, Dask, caching, and multithreading. Use for scaling Hamilton workflows.

Use when optimizing the performance of an existing native scalar expression in the datafusion-comet-spark-expr crate (native/spark-expr/) — casts, string/JSON/array/math kernels that run per-row or per-batch. Covers benchmarking, keeping output bit-identical, and the no-regression gate. Not for adding new expressions (use implement-comet-expression) or wiring upstream functions (use wire-datafusion-function).

Triage open Comet issues marked `requires-triage` per the project bug triage guide. Classifies each issue as a bug or an enhancement, applies the recommended type (`bug`/`enhancement`), priority, and area labels, removes `requires-triage`, and files a dated summary issue listing what was done. A human reviews the summary issue and closes it when satisfied.

Audit an existing Comet expression for correctness and test coverage. Studies the Spark implementation across versions 3.4.3, 3.5.8, 4.0.1, and 4.1.1, reviews the Comet and DataFusion implementations, identifies missing test coverage, and offers to implement additional tests.

Use when implementing a new Spark expression in DataFusion Comet. Walks through cloning latest Spark master to study the canonical implementation, checking the upstream datafusion-spark crate before writing native code, building the Comet serde and Rust wire-up from the contributor guide, then running audit-comet-expression to drive a test-coverage iteration loop.

Review a DataFusion Comet pull request for Spark compatibility and implementation correctness. Provides guidance to a reviewer rather than posting comments directly.

Use when wiring an existing DataFusion or datafusion-spark function into Comet for a Spark expression. Identifies the right wiring pattern (one-line passthrough, datafusion-spark UDF registration, or custom serde with input massaging / restrictions), applies the Scala serde, registers the UDF in jni_api when needed, and adds SQL file tests. Assumes the function already exists upstream — if not, switch to `implement-comet-expression`.

Use this skill whenever the user wants to (re)generate Cayenne entity Java classes from a DataMap. Trigger on phrases like 'generate Java classes', 'regenerate entities', 'run cgen', 'create the entity classes', 'why is the Artist class missing fields', 'where did the `_Abstract*` classes come from', 'sync the entity classes with the model', or any request to materialize Java from the DataMap. Also trigger as a follow-up after modeling changes (someone added an entity, attribute, or relationship and now the Java side is stale). This skill exclusively uses the `mcp__cayenne__cgen_run` MCP tool — it does NOT use `mvn cayenne:cgen` or the Gradle cgen task.

Use this skill whenever the user wants to import database schema metadata into a Cayenne DataMap — full-schema sync from a live DB. Trigger on phrases like 'reverse engineer the database', 'import the schema', 'generate a DataMap from my DB', 'sync the model with the database', 'add the new tables from the DB', 'import the customer table', 'pick up the latest schema changes', 'create entities from these tables', or any request that involves reading database metadata to populate or update a DataMap. This is for *full schema* or *bulk table* import; one-off a-la-carte entity additions belong in the cayenne-modeling skill. The skill runs reverse engineering directly via the `mcp__cayenne__dbimport_run` MCP tool when a DBConnector is already configured; otherwise it opens the CayenneModeler GUI via `mcp__cayenne__open_project` to configure the connection first.

Use this skill when the user explicitly wants to open CayenneModeler (the GUI) on a Cayenne project, or when the modeling task is inherently visual — reverse engineering (delegated to cayenne-db-import), bulk relationship layout, multi-entity visual refactoring. Trigger on phrases like 'open the Modeler', 'open in CayenneModeler', 'launch the GUI', 'edit visually', 'show me the project in the Modeler'. Do NOT trigger as a fallback for ordinary a-la-carte XML edits — those belong in the cayenne-modeling skill, which is faster and doesn't require the user to context-switch.

Use this skill whenever the user wants to edit, inspect, or extend the Cayenne ORM model in a project — adding or modifying entities, attributes, relationships, embeddables, named queries, stored procedures, or DataNodes. Trigger on phrases like 'add an ObjEntity', 'add a DbEntity', 'add a relationship', 'expose this column as an attribute', 'create a new DataMap', 'add a named query', 'create an embeddable', 'add a stored procedure', 'change the attribute type', 'mark this column as nullable', 'rename this entity', or any mention of a Cayenne `*.map.xml` or `cayenne-*.xml` file. Also trigger when the user references modeling concepts (ObjEntity, DbEntity, ObjAttribute, DbAttribute, ObjRelationship, DbRelationship, Embeddable, dbEntityName, deleteRule, db-attribute-path, db-relationship-path, defaultPackage) in the context of a Cayenne-using app. This is the *primary* skill for a-la-carte ORM model manipulation — direct XML edits, not the Modeler GUI.

Use this skill whenever the user wants to write or modify a Cayenne query — fetching entities by criteria, joining, prefetching to avoid N+1, ordering, paginating, aggregating, or running raw SQL through Cayenne. Trigger on phrases like 'query for X', 'fetch all artists where ...', 'write an ObjectSelect', 'use SQLSelect', 'use SelectById', 'add a prefetch', 'get distinct values', 'count rows', 'find by ID', 'load by primary key', 'build a Cayenne expression', 'why am I getting N+1', 'how do I paginate', 'select a single column', 'select columns into a DTO', 'named query in the DataMap'. Do NOT trigger for modeling changes (use cayenne-modeling) or runtime bootstrap (use cayenne-runtime).

Use this skill whenever the user wants to bootstrap Cayenne in a Java application — constructing a CayenneRuntime, wiring a DataSource, configuring connection pools, creating ObjectContexts, or integrating Cayenne with a DI container (Bootique, Spring, plain Java). Trigger on phrases like 'set up Cayenne in my app', 'configure CayenneRuntime', 'wire Cayenne into Bootique/Spring', 'create an ObjectContext', 'configure a DataSource for Cayenne', 'connect Cayenne to Postgres/MySQL/etc.', 'where do I call newContext', 'how do I shut down Cayenne', or any question about the runtime lifecycle. Do NOT trigger for query writing (use cayenne-query) or model editing (use cayenne-modeling).