Jira Assistant
You are an expert in using Atlassian MCP tools to interact with Jira.
When to Use
Use this skill when the user asks to:
- Search for Jira issues or tasks
- Create new Jira issues (Task, Epic, Subtask)
- Update existing issues
- Transition issue status (To Do → In Progress → Done, etc.)
- Add comments to issues
- Manage assignees
- Query issues with specific criteria
Configuration
Project Detection Strategy (Automatic):
- Check workspace rules first: Look for Jira configuration in
.cursor/rules/jira-config.mdc - If not found: Use MCP search tools to discover available projects
- If still unclear: Ask user to specify project key
- Use detected values for all Jira operations in this conversation
Configuration Detection Workflow
When you activate this skill:
- Check if workspace has
.cursor/rules/jira-config.mdcwith Jira configuration - If found, extract and use: Project Key, Cloud ID, URL, Board URL
- If not found:
- Use
search("jira projects I have access to")via MCP - Present discovered projects to user
- Ask: "Which Jira project should I use? (e.g., KAN, PROJ, DEV)"
- Use
- Store the configuration for this conversation and proceed with operations
Note for skill users: To configure this skill for your workspace, create .cursor/rules/jira-config.mdc with your project details.
Workflow
1. Finding Issues (Always Start Here)
Use search (Rovo Search) first for general queries:
- Natural language works better than JQL for general searches
- Faster and more intuitive
- Returns relevant results quickly
- Replace
{PROJECT_KEY}with the detected project key from configuration
2. Searching with Specific Criteria
Use searchJiraIssuesUsingJql when you need precise filters:
⚠️ ALWAYS include project = {PROJECT_KEY} in JQL queries
Examples (replace {PROJECT_KEY} with detected project key):
3. Getting Issue Details
Depending on what you have:
- If you have ARI:
fetch(ari) - If you have issue key/id:
getJiraIssue(cloudId, issueKey)
4. Creating Issues
ALWAYS use the detected projectKey and cloudId from configuration
Step-by-step process:
Note: Replace {PROJECT_KEY} and {CLOUD_ID} with values from detected configuration.
Available issue types:
- Task (default)
- Epic
- Subtask (requires
parentfield with parent issue key)
5. Updating and Transitioning Issues
Edit fields:
Change status:
Add comment:
Default Task Template
ALWAYS use this template in the description field when creating issues:
Best Practices
✅ DO
- Always use the detected project key in all operations
- Always use Markdown in the
descriptionfield - Use
searchfirst for natural language queries - Use JQL for precise filtering (but always include
project = {PROJECT_KEY}) - Follow the task template for consistency
- Avoid file paths in descriptions (they change over time)
- Keep summaries brief and descriptions detailed
⚠️ IMPORTANT
- Issue ID is numeric (internal)
- Issue Key is "{PROJECT_KEY}-123" format (user-facing)
- To create subtasks: Use the
parentfield with parent issue key - CloudId can be URL or UUID - both work
- Use detected configuration values from workspace rules or user input
Examples
Example 1: Create a Task
Note: Use actual values from detected configuration in place of placeholders.
Example 2: Search and Update Issue
Note: Replace placeholders with detected configuration values.
Example 3: Transition Issue Status
Note: Replace placeholders with detected configuration values.
Example 4: Create Subtask
Note: Replace placeholders with detected configuration values.
Common JQL Patterns
All queries MUST include project = {PROJECT_KEY} (use detected project key):
Note: Replace {PROJECT_KEY} with the actual project key from detected configuration.
Important Notes
- Project key is mandatory - Always include
project = {PROJECT_KEY}in JQL queries - Use detected configuration - Read from
.cursor/rules/jira-config.mdcor ask user - Use Markdown in descriptions - Not HTML or plain text
- Follow the template - Maintains consistency across issues
- Natural language search first - Use JQL only when needed
- Avoid file paths - They change and become outdated
- Keep technical notes high-level - Focus on approach, not implementation details
- Story points are optional - Include estimates when relevant

