GitHub Issue Creation Skill
Create a GitHub issue for the repository epam/ai-dial-admin-deployment-manager-backend.
If $ARGUMENTS starts with bug or feature, use that as the issue type. Otherwise, ask the user whether this is a Bug Report or a Feature Request.
Workflow
Determine issue type from $ARGUMENTS or by asking the user.
Get the project version — read build.gradle and extract the version field (e.g. 0.15.0-rc).
Gather context — investigate the codebase thoroughly to understand the issue. Use multiple approaches:
- Search for relevant code, configs, logs, tests, and error messages
- Read related source files to understand current behavior
- Check recent commits and changes that might be related
- Look at existing tests to understand expected behavior
- Consider the issue from different angles: user perspective, developer perspective, system perspective
- If it's a bug, try to identify the root cause or narrow down the area of code involved
- If it's a feature, understand current architecture to describe where the feature fits
Draft the issue — read the appropriate GitHub issue template from .github/ISSUE_TEMPLATE/ and use it as the structure for the issue body:
- Bug Report: read
.github/ISSUE_TEMPLATE/01_bug_report.yml — extract the field labels and structure from the YAML form definition.
- Feature Request: read
.github/ISSUE_TEMPLATE/02_feature_request.yml — extract the field labels and structure from the YAML form definition.
Convert the YAML form fields into a Markdown body where each field's label becomes a ### Heading and the content is filled in based on your investigation.
Determine labels and metadata:
- Type labels: read the
labels field from the corresponding .github/ISSUE_TEMPLATE/*.yml file to get the correct labels (e.g. bug reports use bug; feature requests use enhancement and to-be-documented).
- Priority label (one of):
Priority-Low, Priority-Medium, Priority-High. Guess the appropriate priority based on context, but always confirm with the user.
- Severity label (one of):
Severity-Low, Severity-Minor, Severity-Major, Severity-Critical. Guess the appropriate severity based on context, but always confirm with the user.
- Milestone: Use
release-<MAJOR>.<MINOR> format (version from build.gradle without the bugfix/patch part, e.g. version 0.15.0-rc → milestone release-0.15). Always confirm the milestone with the user.
- Project: AI DIAL Admin (project number 68, added via
gh project item-add after issue creation)
Show the draft to the user — present the full issue title, body, labels, milestone, and project for review. Ask if they want to adjust anything before creating.
Create the issue using gh issue create on epam/ai-dial-admin-deployment-manager-backend with the title, body, labels, and milestone. Use a HEREDOC for the body. Example:
gh issue create --repo epam/ai-dial-admin-deployment-manager-backend \
--title "the title" \
--label "bug" --label "Priority-Medium" --label "Severity-Minor" \
--milestone "release-0.15" \
--body "$(cat <<'EOF'
issue body here
EOF
)"
Add to project — after creating the issue, add it to the AI DIAL Admin project (number 68):
gh project item-add 68 --owner epam --url <ISSUE_URL>
Set the issue type — use the mcp__github__issue_write tool to set the GitHub issue type. The available types for the epam org are: Bug, Feature, Task. Set Bug for bug reports and Feature for feature requests. Example:
mcp__github__issue_write(method="update", owner="epam", repo="ai-dial-admin-deployment-manager-backend", issue_number=<NUMBER>, type="Feature")
Return the issue URL to the user.
Issue Templates
Templates are defined in .github/ISSUE_TEMPLATE/ — always read the appropriate YAML file to get the current field structure. Do NOT hardcode template fields here; the YAML files are the single source of truth.
- Bug Report:
.github/ISSUE_TEMPLATE/01_bug_report.yml
- Feature Request:
.github/ISSUE_TEMPLATE/02_feature_request.yml
General format for the issue body — for each field in the template YAML, create a ### <label> heading followed by the content. Use the version from build.gradle for the Name and Version field (e.g. [BE] 0.15.0-rc).
Important rules
- ALWAYS read
build.gradle to get the current version for both bug reports and feature requests.
- ALWAYS gather as much context as possible from the codebase before drafting — search code, read files, check tests, review recent commits.
- ALWAYS approach the issue from multiple perspectives (user, developer, system) to write a thorough description.
- ALWAYS show the full draft (title, body, labels, milestone, project) to the user before creating the issue.
- ALWAYS confirm Priority, Severity, and Milestone with the user before creating.
- ALWAYS read the labels from the corresponding
.github/ISSUE_TEMPLATE/*.yml file and apply them to the issue.
- ALWAYS set the GitHub issue type after creation:
Bug for bug reports, Feature for feature requests (using mcp__github__issue_write).
- ALWAYS add the issue to the AI DIAL Admin project (number 68) using
gh project item-add.
- Do NOT create the issue without user confirmation.
- Keep titles concise but descriptive.
- For bug reports, include concrete reproduction steps — not vague descriptions.
- For feature requests, explain both the "what" and the "why".
1---2name: create-issue3description: GitHub Issue Creation Skill4---56# GitHub Issue Creation Skill78Create a GitHub issue for the repository `epam/ai-dial-admin-deployment-manager-backend`.910If `$ARGUMENTS` starts with `bug` or `feature`, use that as the issue type. Otherwise, **ask the user** whether this is a **Bug Report** or a **Feature Request**.1112## Workflow13141. **Determine issue type** from `$ARGUMENTS` or by asking the user.15162. **Get the project version** — read `build.gradle` and extract the `version` field (e.g. `0.15.0-rc`).17183. **Gather context** — investigate the codebase thoroughly to understand the issue. Use multiple approaches:19 - Search for relevant code, configs, logs, tests, and error messages20 - Read related source files to understand current behavior21 - Check recent commits and changes that might be related22 - Look at existing tests to understand expected behavior23 - Consider the issue from different angles: user perspective, developer perspective, system perspective24 - If it's a bug, try to identify the root cause or narrow down the area of code involved25 - If it's a feature, understand current architecture to describe where the feature fits26274. **Draft the issue** — read the appropriate GitHub issue template from `.github/ISSUE_TEMPLATE/` and use it as the structure for the issue body:28 - **Bug Report**: read `.github/ISSUE_TEMPLATE/01_bug_report.yml` — extract the field labels and structure from the YAML form definition.29 - **Feature Request**: read `.github/ISSUE_TEMPLATE/02_feature_request.yml` — extract the field labels and structure from the YAML form definition.3031 Convert the YAML form fields into a Markdown body where each field's `label` becomes a `### Heading` and the content is filled in based on your investigation.32335. **Determine labels and metadata**:34 - **Type labels**: read the `labels` field from the corresponding `.github/ISSUE_TEMPLATE/*.yml` file to get the correct labels (e.g. bug reports use `bug`; feature requests use `enhancement` and `to-be-documented`).35 - **Priority label** (one of): `Priority-Low`, `Priority-Medium`, `Priority-High`. Guess the appropriate priority based on context, but **always confirm with the user**.36 - **Severity label** (one of): `Severity-Low`, `Severity-Minor`, `Severity-Major`, `Severity-Critical`. Guess the appropriate severity based on context, but **always confirm with the user**.37 - **Milestone**: Use `release-<MAJOR>.<MINOR>` format (version from `build.gradle` without the bugfix/patch part, e.g. version `0.15.0-rc` → milestone `release-0.15`). **Always confirm the milestone with the user**.38 - **Project**: AI DIAL Admin (project number 68, added via `gh project item-add` after issue creation)39406. **Show the draft to the user** — present the full issue title, body, labels, milestone, and project for review. Ask if they want to adjust anything before creating.41427. **Create the issue** using `gh issue create` on `epam/ai-dial-admin-deployment-manager-backend` with the title, body, labels, and milestone. Use a HEREDOC for the body. Example:43 ```44 gh issue create --repo epam/ai-dial-admin-deployment-manager-backend \45 --title "the title" \46 --label "bug" --label "Priority-Medium" --label "Severity-Minor" \47 --milestone "release-0.15" \48 --body "$(cat <<'EOF'49 issue body here50 EOF51 )"52 ```53548. **Add to project** — after creating the issue, add it to the **AI DIAL Admin** project (number 68):55 ```56 gh project item-add 68 --owner epam --url <ISSUE_URL>57 ```58599. **Set the issue type** — use the `mcp__github__issue_write` tool to set the GitHub issue type. The available types for the `epam` org are: `Bug`, `Feature`, `Task`. Set `Bug` for bug reports and `Feature` for feature requests. Example:60 ```61 mcp__github__issue_write(method="update", owner="epam", repo="ai-dial-admin-deployment-manager-backend", issue_number=<NUMBER>, type="Feature")62 ```636410. **Return the issue URL** to the user.6566---6768## Issue Templates6970Templates are defined in `.github/ISSUE_TEMPLATE/` — always read the appropriate YAML file to get the current field structure. Do NOT hardcode template fields here; the YAML files are the single source of truth.7172- **Bug Report**: `.github/ISSUE_TEMPLATE/01_bug_report.yml`73- **Feature Request**: `.github/ISSUE_TEMPLATE/02_feature_request.yml`7475**General format for the issue body** — for each field in the template YAML, create a `### <label>` heading followed by the content. Use the version from `build.gradle` for the `Name and Version` field (e.g. `[BE] 0.15.0-rc`).7677---7879## Important rules8081- ALWAYS read `build.gradle` to get the current version for both bug reports and feature requests.82- ALWAYS gather as much context as possible from the codebase before drafting — search code, read files, check tests, review recent commits.83- ALWAYS approach the issue from multiple perspectives (user, developer, system) to write a thorough description.84- ALWAYS show the full draft (title, body, labels, milestone, project) to the user before creating the issue.85- ALWAYS confirm Priority, Severity, and Milestone with the user before creating.86- ALWAYS read the labels from the corresponding `.github/ISSUE_TEMPLATE/*.yml` file and apply them to the issue.87- ALWAYS set the GitHub issue type after creation: `Bug` for bug reports, `Feature` for feature requests (using `mcp__github__issue_write`).88- ALWAYS add the issue to the AI DIAL Admin project (number 68) using `gh project item-add`.89- Do NOT create the issue without user confirmation.90- Keep titles concise but descriptive.91- For bug reports, include concrete reproduction steps — not vague descriptions.92- For feature requests, explain both the "what" and the "why".