apache

Adopt and maintain the apache-steward 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: `/setup-steward` — first-time adoption (default; main-checkout only) `/setup-steward upgrade` — refresh the gitignored snapshot per the committed lock (main-checkout only) `/setup-steward worktree-init` — symlink a worktree's snapshot to the main's `/setup-steward verify` — health check + drift detection `/setup-steward override <skill>` — open or scaffold an agentic override in `.apache-steward-overrides/` `/setup-steward unadopt` — reverse the adoption (snapshot, locks, symlinks, hook, doc sections); preserves

Generate a self-contained HTML dashboard of `<tracker>` repository statistics: issue-lifecycle bands (untriaged / triaged / PR-merged / fixed-released / closed-other), opened-vs-untriaged backlog, cumulative opened/closed, mean time to triage, mean time to first response, and — when `<upstream>` is configured — mean time createdAt -> PR-opened, PR-open -> PR-merged, and PR-merged -> advisory announced. All charts are line / area (no bars) with `connectgaps: true`. Vertical annotations on every chart mark the milestones declared in the project's overlay (e.g. "skill adoption", "team handover", "process change").

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).

Read-only nomination brief for a named GitHub contributor on <upstream>. Aggregates GitHub activity across all contribution tracks plus maintainer-supplied off-GitHub signal, and flags vendor-neutrality context — the evidence a PMC needs to open a committer or PMC nomination thread.

Read-only maintainer dashboard for the open-PR backlog of <upstream>. Surfaces a health rating, prioritised action recommendations, weekly closure velocity trends, area pressure ranking, and a triage-funnel breakdown — with the underlying area-grouped tables as a collapsible details section.

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`.

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.

Draft a teaching-register comment on a single GitHub issue or PR thread on the configured `<upstream>` repo, aimed at a contributor who is missing repo context the maintainer would otherwise have to spell out. The skill reads the thread, decides whether a mentoring intervention is warranted, drafts one comment per the project's tone guide and convention pointers, and waits for explicit maintainer confirmation before posting via `gh`. Escalates to the configured maintainer team on the four hand-off triggers.

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.

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.

Explains core Apache Beam programming model concepts including PCollections, PTransforms, Pipelines, and Runners. Use when learning Beam fundamentals or explaining pipeline concepts.

Guides understanding and working with Apache Beam's CI/CD system using GitHub Actions. Use when debugging CI failures, understanding test workflows, or modifying CI configuration.

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.

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.

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.

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 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 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-reverse-engineer), 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 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 drives this through CayenneModeler's reverse-engineering wizard via the `mcp__cayenne__open_project` MCP tool — it does NOT use Maven `cdbimport` or any Gradle equivalent.

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).

Fix BE (C++) code formatting issues using clang-format

Review code with Doris-specific checklists

Run clang-tidy on newly added/modified BE C++ code

Fix FE (Java) code style issues using Checkstyle

Run Doris docker-based regression tests from a clean package

Triage open Comet issues marked `requires-triage` per the project bug triage guide. Applies the recommended 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.

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 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.

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

Create a new HTTP or Network filter for Apache dubbo-go-pixiu. Use whenever the user wants to add a custom filter, extend gateway per-request behavior, implement a new auth/logging/transformation/proxy filter, or mentions "pixiu filter", "dgp.filter", "http_filters", "filter chain", "custom filter", "extend pixiu", or is porting a filter from Envoy/Kong/APISIX to pixiu. Strongly prefer this skill over ad-hoc generation even when the user does not say the word "skill" — getting the SPI registration right is the single biggest source of "my filter does not run" bug reports.

Map a REST/HTTP endpoint onto a backend Dubbo service through dubbo-go-pixiu. Use whenever the user wants to "expose Dubbo as HTTP", "REST gateway for Dubbo", "Dubbo generic invoke", configure `api_config.yaml`, `integrationRequest`, `mappingParams`, `mapType`, `opt.types` / `opt.values`, group / version, or says "how do I call my Dubbo service from curl". Use this even when the user only asks to tweak an existing yaml route — the combination of conf.yaml + api_config.yaml is where most "500 from pixiu" reports come from, and this skill encodes the invariants.

Configure Apache dubbo-go-pixiu as an AI / LLM gateway. Use when the user asks to proxy OpenAI-compatible, Claude-compatible, Gemini, vLLM, DeepSeek, or self-hosted model endpoints; configure `dgp.filter.llm.proxy`, `dgp.filter.llm.tokenizer`, `dgp.filter.ai.kvcache`, LLM retry/fallback, endpoint `llm_meta`, token metrics, LMCache/vLLM cache-aware routing, or Nacos LLM registry discovery. This skill is for Pixiu `conf.yaml`, not `api_config.yaml`.

Use when configuring dubbo-go-pixiu as an MCP gateway: `dgp.filter.mcp.mcpserver`, Streamable HTTP/SSE, `tools/list`, `tools/call`, OAuth/JWT `dgp.filter.http.auth.mcp`, Nacos `dgp.adapter.mcpserver`, or stdio MCP bridge guidance.

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/.

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 (using sub-agents 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.

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.

Used to review whether an Apache ShardingSphere PR truly fixes the root cause, assess side effects and regression risks, and determine whether it can be safely merged. If not mergeable, produce committer-tone change request suggestions. Supports targeted comparison across multiple review rounds.

Generate standard unit tests for one or more target classes in Apache ShardingSphere; by default, target 100% class/line/branch coverage and pass quality gates; perform explicit merge analysis, suitability filtering, and refactor optimization for parameterized tests.

Used to analyze Apache ShardingSphere community issues. Emphasizes root-cause-first and evidence-first analysis with issue-type classification before conclusions, and outputs traceable results plus label recommendations in a fixed four- or five-section structure.