원클릭으로
ai-dial-quickapps-backend
ai-dial-quickapps-backend에는 epam에서 수집한 skills 6개가 있으며, 저장소 수준 직업 범위와 사이트 내 skill 상세 페이지를 제공합니다.
이 저장소의 skills
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.