Intelligently triage bug reports and error messages by searching for duplicates in Jira and offering to create new issues or add comments to existing ones. When an agent needs to: (1) Triage a bug report or error message, (2) Check if an issue is a duplicate, (3) Find similar past issues, (4) Create

Triage Issue Keywords triage bug, check duplicate, is this a duplicate, search for similar issues, create bug ticket, file a bug, report this error, triage this error, bug report, error message, similar issues, duplicate bug, who fixed this, has this been reported, search bugs, find similar bugs, create issue, file issue Overview Automatically triage bug reports and error messages by searching Jira for duplicates, identifying similar past issues, and helping create well structured bug tickets or add context to existing issues. This skill eliminates manual duplicate checking and ensures bugs are properly documented with relevant historical context. Use this skill when: Users need to triage error messages, bug reports, or issues to determine if they're duplicates and take appropriate action. Workflow Follow this 6 step process to effectively triage issues: Step 1: Extract Key Information Analyze the bug report or error message to identify search terms. Extract These Elements: Error signature: Error type or exception name (e.g., "NullPointerException", "TimeoutError") Error code or status (e.g., "500", "404", "ERR CONNECTION REFUSED") Specific error message text (key phrases, not full stack trace) Context: Component or system affected (e.g., "authentication", "payment gateway", "API") Environment (e.g., "production", "staging", "mobile app") User actions leading to error (e.g., "during login", "when uploading file") Symptoms: Observable behavior (e.g., "page blank", "infinite loading", "data not saving") Impact (e.g., "users can't login", "payments failing") Example Extractions: Input: "Users getting 'Connection timeout' error when trying to login on mobile app" Extracted: Error: "Connection timeout" Component: "login", "mobile app" Symptom: "can't login" Input: "NullPointerException in PaymentProcessor.processRefund() line 245" Extracted: Error: "NullPointerException" Component: "PaymentProcessor", "refund" Location: "processRefund line 245" Step 2: Search for Duplicates Search Jira using extracted keywords to find similar or duplicate issues. Search Strategy: Execute multiple targeted searches to catch duplicates that may use different wording: Search 1: Error focused Search 2: Component focused Search 3: Symptom focused Search Tips: Use key terms only: ✅ "timeout login mobile" ✅ "NullPointerException PaymentProcessor refund" ❌ "Users are getting a connection timeout error when..." (too verbose) Search recent first: Order by created DESC or updated DESC to find recent similar issues Recent bugs are more likely to be relevant duplicates Don't over filter: Include resolved issues (might have been reopened or regression) Search across all bug statuses to find fix history Step 3: Analyze Search Results Evaluate the search results to determine if this is a duplicate or a new issue. Duplicate Detection: High confidence duplicate ( 90%): Exact same error message in summary or description Same component + same error type Recent issue (< 30 days) with identical symptoms Action: Strongly recommend adding comment to existing issue Likely duplicate (70 90%): Similar error with slight variations Same component but different context Resolved issue with same root cause Action: Present as possible duplicate, let user decide Possibly related (40 70%): Similar symptoms but different error Same component area but different specific error Old issue ( 6 months) that might be unrelated Action: Mention as potentially related Likely new issue (<40%): No similar issues found Different error signature and component Unique symptom or context Action: Recommend creating new issue Check Fix History: If similar resolved issues are found: Extract relevant information: Who fixed it? (assignee on resolved issues) How was it fixed? (resolution comment or linked PRs) When was it fixed? (resolution date) Has it regressed? (any reopened issues) Present this context to help with triage decision. Step 4: Present Findings to User CRITICAL: Always present findings and wait for user decision before taking any action. Format for Likely Duplicate: Format for Possibly Related: Format for No Duplicates: Step 5: Execute User Decision Based on user's choice, either add a comment or create a new issue. Option A: Add Comment to Existing Issue If user wants to add to existing issue: Fetch the full issue first to understand context: Then add the comment: Comment Structure: Option B: Create New Issue If user wants to create new issue: First, check available issue types. listJiraProjectIssueTypesMetadata is not a primary tool, so run it through execute (see [Calling non primary tools]( calling non primary tools)): Determine appropriate issue type: For bugs/errors → Use "Bug" (if available) For issues without errors → Use "Task" or "Issue" Fallback → First available non Epic, non Subtask type Create the issue: Summary Format: Use the pattern: [Component] [Error Type] [Brief Symptom] Examples: ✅ "Mobile Login: Connection timeout during authentication" ✅ "Payment API: NullPointerException in refund processing" ✅ "Dashboard: Infinite loading on reports page" ❌ "Error in production" (too vague) ❌ "Users experiencing issues" (not specific) Description Structure: [Error message or stack trace] Step 6: Provide Summary After taking action, confirm what was done. If Comment Added: If New Issue Created: Edge Cases & Troubleshooting Multiple Potential Duplicates If you find 3+ very similar issues: Unclear Project Context If user doesn't specify which project: Insufficient Information If the bug report lacks critical details: Resolved Regression If you find a resolved issue that matches: Custom Required Fields If creating an issue fails due to required fields: 1. Check what fields are required. getJiraIssueTypeMetaWithFields is not a primary tool, so run it through execute : 2. Ask user for values: 3. Retry with additional fields: Tips for Effective Triage For Search: Do: ✅ Use multiple search queries with different angles ✅ Include both open and resolved issues in search ✅ Search for error signatures and symptoms separately ✅ Look at recent issues first (last 30 90 days) ✅ Check for patterns (multiple reports of same thing) Don't: ❌ Search with entire error messages (too specific) ❌ Only search open issues (miss fix history) ❌ Ignore resolved issues (miss regressions) ❌ Use too many keywords (reduces matches) For Issue Creation: Do: ✅ Write clear, specific summaries with component names ✅ Include complete error messages in code blocks ✅ Add environment and impact details ✅ Reference related issues found during search ✅ Use "Bug" issue type for actual bugs Don't: ❌ Create vague summaries like "Error in production" ❌ Paste entire stack traces in summary (use description) ❌ Skip reproduction steps ❌ Forget to mention user impact ❌ Hard code issue type without checking availability For Duplicate Assessment: High Confidence Duplicates: Exact same error + same component + recent (< 30 days) Same root cause identified Likely Different Issues: Different error signatures Different components/systems Significantly different contexts When Unsure: Present both options to user Lean toward creating new issue (can be closed as duplicate later) Linking issues is better than hiding information Examples Example 1: Clear Duplicate Found User Input: Process: 1. Extract: "Connection timeout", "login", "iOS" 2. Search: Find PROJ 456 (open, 2 days ago) with exact same error 3. Analyze: 95% match same error, component, symptom 4. Present: Show PROJ 456 as duplicate, recommend adding comment 5. Execute: User confirms, add comment with iOS specific details 6. Confirm: Comment added to PROJ 456 Output: Example 2: New Issue with Related Context User Input: Process: 1. Extract: "NullPointerException", "PaymentProcessor", "processRefund", "line 245" 2. Search: Find PROJ 789 (resolved, 3 weeks ago) about payment errors, but different line 3. Analyze: Related component but different specific error 4. Present: No duplicates, found related issue, recommend new ticket 5. Execute: User confirms, create new Bug with context 6. Confirm: PROJ 890 created Output: Example 3: Possible Regression User Input: Process: 1. Extract: "Upload failed", "5MB", "file upload" 2. Search: Find PROJ 234 (resolved 2 months ago) exact same issue 3. Analyze: Was fixed but now happening again 4. Present: Possible regression, recommend new issue linked to old one 5. Execute: Create new issue, link to PROJ 234 as "may be caused by" 6. Confirm: PROJ 891 created with regression context Output: When NOT to Use This Skill This skill is for triaging bugs and errors only . Do NOT use for: ❌ Feature requests (use spec to backlog) ❌ General task creation (use capture tasks from meeting notes) ❌ Searching for information (use search company knowledge) ❌ Generating status reports (use generate status report) Use this skill specifically for: ✅ "Is this a duplicate bug?" ✅ "Triage this error message" ✅ "Has this been reported before?" ✅ "Create a bug ticket for this" Quick Reference Primary workflow: Extract → Search → Analyze → Present → Execute → Confirm Search tool: searchJiraIssuesUsingJql(cloudId, jql, fields, maxResults) Action tools: addOrEditJiraIssueComment(cloudId, issueIdOrKey, commentBody) Add to existing createJiraIssue(cloudId, projectKey, issueType, summary, description) Create new Issue type: Always prefer "Bug" for error reports, check with executeRead(name="listJiraProjectIssueTypesMetadata", ...) (not a primary tool) Remember: Multiple searches catch more duplicates Present findings before acting Include error details and context Reference related issues Use "Bug" issue type when available Calling non primary tools The Atlassian Rovo MCP server exposes only a small set of primary tools directly in your tool list. Everything else lives in the catalog and is reached through meta tools: discover — describe the goal in natural language when you do not know an operation's name. It returns the exact name and inputs to use. Do not call discover for an operation you already have as a primary tool. An execute family tool — run a catalog operation by name. Check your tool list: some clients expose a single execute , others expose executeRead / executeWrite / executeDestructive and expect the tier matching the operation. The arguments are identical: Rules that matter: cloudId is a top level argument , a sibling of name and inputs — never put it inside inputs . Operations declared omitCloudId (such as getContentFormatGuide ) take no cloudId . inputs is a flat object. The server routes each parameter to path, query, or body itself. Use the exact parameter names from the live tool schema. Unrecognized parameters are dropped rather than reported as an error, so a wrong name fails silently — the call succeeds and your value is simply ignored. When in doubt, read the schema or discover result first. If the call reports an unknown operation, run discover with different keywords and use the name it returns rather than guessing.

triage-issue