epam

Guides the UUI package release process including stable and beta releases, changelog updates, and handling failed releases. Use when releasing UUI packages, updating changelog, or troubleshooting release issues. For maintainers only.

Helps create and modify UUI (EPAM Unified UI) components following established patterns. Use when creating new components, modifying existing components, working with withMods, component props, styling, or component architecture in the UUI library.

Helps work with UUI DataSources (ArrayDataSource, LazyDataSource, AsyncDataSource) powering PickerInput, DataTable, FiltersPanel, and other data-driven components. Use when implementing or fixing features that load, filter, sort, or display lists of data.

Helps update UUI documentation, add doc examples, configure Property Explorer, and manage component API documentation. Use when adding documentation examples, updating Property Explorer configs, generating API references, working with UUI documentation site, or when adding/removing/modifying public props on component interfaces.

Helps create and maintain E2E and screenshot tests for UUI components using Playwright. Use when adding E2E tests, creating screenshot tests, updating preview configurations, or working with Property Explorer previews for testing.

Fetches GitHub issues from URLs and creates implementation plans for UUI. Use when the user provides a GitHub issue link (github.com/.../issues/N), asks to plan work from an issue, or implement/fix an issue by URL.

Guides the UUI pull request process including branch naming, pre-PR checklist, changelog updates, and quality requirements. Use when preparing a pull request, writing commit messages, or following UUI PR requirements.

Helps work with UUI services layer including ContextProvider, ApiContext, ModalContext, NotificationContext, and useUuiContext. Use when implementing features that need modals, notifications, API calls, error handling, or routing.

Use when the user asks to enhance, refine, polish, or "look at" the release notes for a tag — typically a fresh CI-generated pre-release (e.g. `0.45.0-rc.55`) or a stable cut. Reads the auto-generated notes off the GitHub release, classifies and rewrites each bullet in this project's editorial voice, builds the `Deployment Changes` section from `apps/chat/README.md` / PR bodies / source, and saves a draft to `claude/release-notes/`. Never edits GitHub directly.

Reference for writing ai-dial-chat Playwright e2e tests - dialFixtures composition, page object and assertion patterns, test data builders, GeneratorUtil naming, setTestIds, dialTest.step structure, and anti-patterns. Use when creating or fixing e2e tests, adding fixtures, page objects, assertions, or test data builders in apps/chat-e2e.

Reference for writing ai-dial-chat Next.js API routes - session validation with next-auth, the validate-session/validate-input/proxy pattern, streaming responses from DIAL Core, error handling, and status-code conventions. Use when creating or editing any handler under apps/chat/src/pages/api/.

Reference for the ai-dial-chat architecture - NX monorepo layout, Redux Toolkit + RxJS epics, Next.js API proxy, store/selectors/actions barrels, layer responsibilities and dependency rules. Use when adding a new store domain or API route, wiring up epics/selectors/actions, or reasoning about how data flows from a component through the store to DIAL Core.

Reference for ai-dial-chat code style and conventions - naming (PascalCase components, kebab-case files), import order, React FC component pattern, Redux hooks/epic patterns, lint/format/typecheck commands, conventional commits, and the pre-PR checklist. Use when writing components, hooks, or store code, or preparing a commit/PR.

Reference for testing ai-dial-chat - Vitest + @testing-library/react unit tests (Arrange/Act/Assert, vi.mock + vi.hoisted), Playwright e2e with dial fixtures and page objects, test locations, and run commands. Use when writing or fixing unit or e2e tests, setting up mocks, or running the test suites.

Formats file and URL parameters for tool calls. You must analyze the target tool's parameter names and descriptions to choose the correct format (base64, text, or URL ref).

Use when the user asks to "create a PR", "open a pull request", "raise a PR", "ship this", or "/quickapps-create-pr" in this repo. Drives the project's end-to-end PR flow — feature branch, conventional-commit title/body, the pre-PR format+lint gate, push, and `gh pr create --base development` with the repo's PR template filled in.

Use when the user asks to enhance, refine, polish, or "look at" the release notes for a tag — typically a fresh CI-generated pre-release (e.g. `0.8.0-rc.1`) or a stable cut. Reads the auto-generated notes off the GitHub release, classifies and rewrites each bullet in this project's editorial voice, builds the `Deployment Changes` section from `README.md` / `CONFIGURATION.md` / PR bodies, and saves a draft to `claude/release-notes/`. When the target is a stable cut (e.g. `0.8.0`) and its `-rc.*` pre-releases already carry enhanced notes, it assembles the stable draft by merging those rc notes — reusing their approved wording — instead of re-deriving every bullet from the raw stable notes. Never edits GitHub directly.

Use when the user wants to draft or file a GitHub feature-request issue for the Quick Apps 2.0 **editor** — the no-code app-builder UI that lives in the epam/ai-dial-chat repo ("create an issue for the quickapps editor", "draft a chat feature request for quick apps", "file an editor issue for the X toggle", "/quickapps-editor-issue"). Reach for it whenever a backend QuickApps capability needs an editor surface (a new toggle/field in the configurator) and the issue should follow ai-dial-chat's feature-request template, the `[Quick app 2.0] Feature: …` naming, a Config-mapping JSON snippet, and cross-repo references to ai-dial-quickapps-backend issues — even if the user only says "we should expose X in the editor".

Use before creating a PR or claiming a change is ready (or on explicit user invocation). Self-reviews the current diff against the patterns this team's reviewers consistently flag.

Use when the user asks to review, critique, validate, or approve a design doc under docs/designs/. Appends a Review Notes block; on explicit approval, strips notes and flips Status to Approved.

Use when adding a new field to an existing Custom Resource. Guides the full workflow: API types, code generation, CRD examples, client investigation, handler mapping, and tests.

Use when generating testify mocks for an interface. Ensures the interface is registered in .mockery.yml, runs make mocks, and verifies the output file.

Run tests for the edp-keycloak-operator. By default runs unit + integration tests. Use /run-tests e2e for end-to-end tests.

Run golangci-lint linters and fix any linting errors. Use when fixing lint issues or before committing code.

Interactively create GitHub issues (Bug, Feature, Task) for the current repository. Infrastructure changes are Tasks auto-labeled `ops-request`. Parses optional args for type and description, asks targeted questions, assigns labels, and creates the issue via gh CLI.

Use this skill whenever the user wants to commit, push, or ship changes in a git repository. Triggers include: "commit changes", "push my changes", "ship it", "commit and push", "create a branch and commit", "make a PR", "open a pull request", "create draft PR", or any variation of committing/pushing work. Always use this skill when the user mentions committing — even casually — as it handles the full cycle: branch → add → commit → push → (optionally) PR, with Conventional Commits format and automatic area detection.

Verify an OpenSpec change's browser-observable acceptance scenarios against the live local app. Reads the change's delta + affected consolidated specs, builds a VerificationRequest, spawns the spec-verification-gate sub-agent (which drives the Playwright MCP), and reports verdicts back. Additive to the OpenSpec workflow — it reads specs but never modifies opsx artifacts, config, or code, and never makes the "done" call. Use when the user wants to verify a change works in the browser, or to retest specific scenarios after a fix.

Use when the user asks to enhance, refine, polish, or "look at" the release notes for a tag — typically a fresh CI-generated pre-release (e.g. `0.16.1-rc.0`) or a stable cut. Reads the auto-generated notes off the GitHub release, classifies and rewrites each bullet in this project's editorial voice, builds the `Deployment Changes` section from `docs/INFRA-CHANGELOG.md` and `docs/upgrade-plans/`, and saves a draft to `claude/release-notes/`. Never edits GitHub directly.

Structured CRITICAL→NIT review for diffs or paths; review-only until the user requests code changes.

End-to-end feature work across Next.js UI, Redux store, tests, and verification commands for this repo.

Align new edits with neighboring files—imports, Redux epics, Next.js patterns, and Tailwind rules in dial-mind-map-frontend.

Run the standard npm lint, test, format, and build checks expected before sharing dial-mind-map-frontend changes.

Use when generating, reviewing, repairing, explaining, or executing TimeBase QQL, including MCP-grounded query answers, and small result sets that can be returned directly. Prefer this over the Python client skill unless the user needs a Python artifact, local file export, large result extraction, or downstream Python post-processing.

Use when the user explicitly asks for TimeBase C# or .NET client code, for example typed stream reads/writes, stream creation, bound QQL execution from C#, Deltix.Timebase package setup, or TimeBase .NET client debugging.

Use when the user needs TimeBase Python client code, for example scripts, apps, services, local file export, large result extraction, pandas workflows, visualization prep, or downstream Python computation. Do not use for pure MCP discovery or pure QQL tasks answerable via QQL plus MCP without a Python artifact.

Write unit tests for Ember trading algorithms using the algo test framework (BaseAbstractAlgorithmTest). Use when asked to create or modify algo unit tests, add test coverage, or understand how the test framework works.

Scan the codebase for DFP (Decimal64) misuse — raw Java comparison operators used on DFP-encoded long values instead of Decimal64Utils helper methods. Run periodically to catch regressions.

Add or update logging statements using GFLog library. Use when creating new log statements, refactoring existing logging code (JUL/SLF4J), or when you see string concatenation in log statements.

TODO: Write a concise description explaining the skill's purpose — managing users in the UMS via CRUD operations, search, web enrichment; and when to activate it

# TODO: # Write a 2-3 sentence description of what this skill does and when the agent should use it. # Cover: what types of calculations it handles, what operations are supported, # and what user requests should trigger this skill (e.g. calculate, compute, evaluate, solve, etc.).

# TODO: Write when the agent should activate this skill. # Cover: what content types it handles and what user actions trigger it.

Create a GitHub pull request with Conventional Commits title and structured description. Use when creating PRs, opening pull requests, or submitting code for review.

Create a GitHub issue (Bug Report or Feature Request) for the current project. Use when filing bugs, reporting issues, or requesting features.

Review a GitHub pull request with inline comments on specific diff lines. Use when reviewing PRs, analyzing pull request changes, or providing code review feedback.

# TODO: # Write a 2-3 sentence description of what this skill does and when the agent should use it. # Cover: what types of calculations it handles, what operations are supported, # and what user requests should trigger this skill (e.g. calculate, compute, evaluate, solve, etc.).

# TODO: Write when the agent should activate this skill. # Cover: what content types it handles and what user actions trigger it.

Manages users in the User Management Service (UMS). Supports CRUD operations on user records: create, read, update, and delete users, search by various criteria, and answer questions about existing users. Use when the user asks to find, add, update, or remove users in the system.

Five-axis code review before merge. Use for quality passes after implementation, before merge, and when asked to review a diff.

Design-to-code workflow for Figma designs. Use when the user shares a Figma URL or asks to implement a design into the codebase.

Researches feature directions before implementation. Use when the user asks to investigate approaches, compare options, assess risks/trade-offs, and recommend an implementation path.