一键导入
create-plan-for-jira
// Creates a plan to address a Jira issue. Use it when the user wants you to suggest how to address an issue or implement a feature.
// Creates a plan to address a Jira issue. Use it when the user wants you to suggest how to address an issue or implement a feature.
| name | create-plan-for-jira |
| description | Creates a plan to address a Jira issue. Use it when the user wants you to suggest how to address an issue or implement a feature. |
| disable-model-invocation | true |
Creates a plan describing how to fix or implement the specified Jira issue or refine an existing one
kubev2v remote must be configured (typically as upstream or kubev2v)If not in Plan mode, ask the user: "Please switch to Plan mode (Shift+Tab) so I can create a properly registered plan."
A Jira issue ID matching the pattern: ECOPROJECT-\d+
The agent cannot perform operations requiring user credentials. For these operations, provide ready-to-use commands for the user to copy-paste:
Always prepare complete commands so the user can execute them directly.
jira_get_issue to fetch the issue details; always pay attention to linked issues (parent and child issues) to understand the full context of the task.ECOPROJECT-3871 | fix: Default report view to first clusterkubev2v/master (see "Branch Creation" below)/create-pull-request skillImportant: Always base the new branch on the upstream kubev2v/master to ensure it includes the latest changes.
Fetch the latest from kubev2v remote:
git fetch kubev2v
Create and checkout the branch based on kubev2v/master:
git checkout -b <TICKET-ID> kubev2v/master
git fetch kubev2v && git checkout -b ECOPROJECT-1234 kubev2v/master
Note: If the remote is named differently (e.g.,
upstream), adjust accordingly. Usegit remote -vto check available remotes.
The make validate-all target runs all quality checks, but individual targets can be run selectively based on context:
| Target | Command | When to Run |
|---|---|---|
| lint | make lint | Always - after any code changes |
| format | make format | Always - after any code changes |
| type-check | make type-check | Always - after any code changes |
| test | make test | Always - after any code changes |
| security-scan | make security-scan | Only when dependencies change (package.json/package-lock.json modified) or before final PR |
During development:
make lint format type-check test
Before creating PR (or if dependencies changed):
make validate-all
FIX=1 make lint - Auto-fix ESLint issuesFIX=1 make format - Auto-format code with PrettierThe "In Progress" transition ID is: 31
Use jira_transition_issue tool:
{
"issue_key": "<TICKET-ID>",
"transition_id": "31",
"comment": "Starting implementation"
}
If the transition fails (ID changed or not available for current status), use jira_get_transitions to find the correct ID:
{
"issue_key": "<TICKET-ID>"
}
Then look for the transition named "In Progress" in the response and use that ID.
Track progress through these phases:
Create pull request. Use when the user asks to create a pull request after some refactor.
Provides ready-to-use commands for git operations requiring user authentication (commits, push, PR creation).
Executes code quality checks. Use when the user asks to validate changes after a refactor or to report test coverage