Add skill to triage jira issues against code #108
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,9 +1,16 @@ | ||
| { | ||
| "name": "bitwarden-atlassian-tools", | ||
| "version": "2.3.0", | ||
| "description": "Read-only Atlassian access via MCP server with deep Jira issue research skill, JQL search, Confluence pages, CQL search, and attachments", | ||
| "author": { | ||
| "name": "Bitwarden" | ||
| }, | ||
| "keywords": [ | ||
| "atlassian", | ||
| "jira", | ||
| "confluence", | ||
| "mcp", | ||
| "read-only", | ||
| "cql" | ||
| ] | ||
| } |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,111 @@ | ||
| --- | ||
| name: triaging-jira-issues | ||
| description: Use when the user provides a single Jira issue key and asks whether it is still relevant, still applicable, still pending, still a bug, has been fixed, or can be closed. Trigger phrases include "Is [TICKET] still relevant?", "Is this still an issue?", "Is PM-123 still pending?", "Has this been fixed?", "Can we close this?", "Is this ticket still valid?", "Is this still applicable?", "Does this bug still exist?". Fetches the ticket and verifies the described problem against the current codebase to return a verdict with evidence. This skill triages a single ticket at a time; invoke it iteratively for multiple tickets. | ||
| --- | ||
|
|
||
| # Triaging a Jira Issue for Relevance | ||
|
|
||
| Determine whether a Jira issue still applies to the current codebase. Fetch the ticket, locate the specific code path it describes, compare current behavior against the ticket's description, and return a verdict with evidence. | ||
|
|
||
| This skill is distinct from `researching-jira-issues`. That skill synthesizes context to *understand* a ticket. This skill verifies whether the described problem or task still exists in code — the answer should be a clear verdict, not a summary. | ||
|
|
||
| ## Workflow | ||
|
|
||
| ### Step 1: Fetch the Ticket and Its Context | ||
|
Member
There was a problem hiding this comment. @ariane-bitwarden should we consider also fetching the Github issue if it's linked to one via the "Github URL" field, and doing the same staleness checks there? If users are reporting it as still happening in Github then that's a signal. |
||
|
|
||
| Use `get_issue` with `expand: ["renderedFields", "names"]`. Extract: | ||
|
|
||
| - **The specific problem or task**: Read beyond the summary. The description, acceptance criteria, and replication steps are more precise. For bugs: what is the actual broken behavior and what is expected? For tasks: what specific code change is required? | ||
| - **Technical identifiers**: Method names, class names, file paths, API endpoint routes, UI strings that appear in source, config keys, feature flag names — anything named in the ticket that can be searched in code. Note these explicitly before moving on. | ||
| - **Filed date**: Used to scope `git log` searches. | ||
| - **Repo scope signal**: Determine whether this applies to `clients`, `server`, `sdk-internal`, or a combination. Use the team field, component labels, and description content (see Scope Notes below). | ||
|
Contributor
There was a problem hiding this comment. ❓Is this skill intentionally limited to these specific repositories? |
||
|
|
||
| Also note these **staleness signals** from the ticket fields before moving on: | ||
|
|
||
| - **Age**: How many months since the ticket was filed? | ||
| - **Priority and assignee**: Is it Low/Lowest priority? Unassigned? | ||
| - **Parent epic**: Does the ticket have a parent epic? If so, fetch it (`get_issue`) and check whether all other child tickets are resolved. A lone surviving task in an otherwise-completed epic is a strong signal that the work may have been intentionally deferred or forgotten — not that it's still needed. | ||
|
|
||
| After fetching the ticket, always do both of the following: | ||
|
|
||
| **Fetch issue comments** (`get_issue_comments`): Comments often contain decisions that never made it back into the description — root cause findings, "we decided not to fix this", priority calls, or pointers to where the fix landed. Read them before building search targets. | ||
|
|
||
| **Fetch linked issues** (`get_issue_remote_links` and the `issuelinks` field): Look specifically for blocking relationships — issues this ticket blocks or is blocked by. A ticket blocked by unresolved work may not be actionable yet; a blocker that has since been resolved may mean this ticket is now ready. Fetch (`get_issue`) any directly linked issues to check their current status and extract additional technical context. Do not traverse more than one level deep. | ||
|
|
||
| ### Step 2: Build Search Targets | ||
|
|
||
| From the ticket, identify 2–5 specific identifiers to search for in code. Prioritize: | ||
|
|
||
| - Method or function names mentioned in the ticket (e.g., `ValidateLegacyMigrationAsync`, `unlockViaBiometrics`, `validateCanManagePermission`) | ||
| - Class or component names (e.g., `BaseRequestValidator`, `LockComponent`, `CollectionDialog`) | ||
| - API route strings (e.g., `"trial/send-verification-email"`, `"verify-email-token"`) | ||
| - UI strings that appear in source or i18n JSON (e.g., `"managePermissionRequired"`) | ||
| - Config or feature flag keys (e.g., `DenyLegacyUserMinimumVersion`) | ||
|
|
||
| If the ticket names no specific identifiers, derive them from the described behavior: what function would implement this, what component would render this UI, what endpoint would serve this request? | ||
|
|
||
| ### Step 3: Search the Code | ||
|
|
||
| Run searches in the relevant repo(s): | ||
|
|
||
| 1. **Grep for each identifier** in the relevant source directories. Don't stop at confirming existence — read the surrounding code to understand current behavior. A symbol that still exists but now behaves differently may mean the bug is already fixed. | ||
|
|
||
| 2. **Read the actual implementation** at each match. The grep result shows where; the file content shows what it currently does. Confirm whether the behavior the ticket describes is still present, partially changed, or gone. | ||
|
|
||
| 3. **Check git history on affected files** since the ticket was filed: | ||
| ``` | ||
| git log --oneline --since="<filed-date>" -- <file-path> | ||
| ``` | ||
| Look for commits that might have silently addressed the issue — refactors, renames, feature flag removals, component rewrites. If a commit looks relevant, read its diff on the affected lines. | ||
|
|
||
| 4. **Trace refactored paths**: If a named symbol no longer exists, find what replaced it. A deleted method does not mean the bug is fixed — the logic may have moved. Search for the behavior, not just the original name. | ||
|
|
||
| ### Step 4: Deliver Verdict | ||
|
|
||
| Compare what the ticket describes against what the code does today. Reach a conclusion. | ||
|
|
||
| **Verdict options**: | ||
|
|
||
| - **Still relevant** — The described problem exists unchanged in the current code. Show the specific `file:line` that proves it. | ||
| - **Partially addressed** — Some part of the described problem was fixed, but a gap remains. State precisely what was fixed and what remains open, with evidence for each. | ||
| - **No longer relevant** — The problem no longer exists. Explain what changed and cite the current code or commit that proves it. Note whether the ticket is safe to close. | ||
| - **Technically relevant, but question whether still needed** — The gap exists in code, but staleness signals are strong enough that the work should be confirmed with the reporter or PM before picking it up. Use this when multiple signals combine: ticket is significantly old (> ~9 months), unassigned, low priority, and/or is the lone surviving task in an otherwise-completed epic. State the code evidence and the staleness signals separately so the reader can weigh both. | ||
| - **Cannot determine** — The ticket description is too vague to trace to specific code, and `git log` provides no signal. State what you searched and why it was inconclusive. Only use this after exhausting the search targets. | ||
|
|
||
| **Format**: Lead with the verdict and its justification in plain prose. Cite `file:line` references as evidence. If still relevant, state what specifically remains to be done — do not just restate the ticket. If staleness signals are present even for a "Still relevant" verdict, note them at the end: ticket age, epic completion state, priority, and assignee. Keep it tight; a verdict paragraph with supporting evidence is sufficient. | ||
|
|
||
| ## Scope Notes | ||
|
|
||
| Use these to determine which repo and directories to search: | ||
|
|
||
| **Server repo** (`server/src/`): | ||
| - Team field (including but not limited to): Billing, Auth (server-side), Admin Console (server-side) | ||
| - Keywords in description: C#, .NET, API endpoint, stored procedure, Stripe, webhook, IdentityServer, database | ||
| - Key directories: `src/Identity/IdentityServer/` (auth/token flow), `src/Core/Billing/` and `src/Identity/Billing/` (billing), `src/Core/Services/Implementations/` (user/org services), `src/Api/` (REST controllers) | ||
|
|
||
| **Clients repo** (`clients/`): | ||
| - Team field (including but not limited to): Key Management, Browser, Desktop, Admin Console (frontend), Vault | ||
| - Keywords in description: Angular, TypeScript, browser extension, desktop app, web vault, UI component, form | ||
| - Key directories: `apps/browser/src/` (extension), `apps/desktop/src/` (desktop), `apps/web/src/` (web vault), `libs/key-management-ui/src/lock/` (shared lock/unlock UI), `libs/key-management/src/` and `libs/auth/src/` (shared auth) | ||
|
|
||
| **SDK repo** (`sdk-internal/crates/`): | ||
| - Team field (including but not limited to): SDK, Platform | ||
| - Keywords in description: Rust, crate, SDK, FFI, bitwarden-crypto, bitwarden-auth, bitwarden-core | ||
| - Key crates: `bitwarden-crypto/` (encryption), `bitwarden-auth/` (authentication), `bitwarden-core/` (core types), `bitwarden-ffi/` (cross-platform bindings) | ||
|
|
||
| **Multiple repos**: Auth and key management tickets often span clients and server. Vault timeout, biometrics, and unlock flow bugs commonly touch both `clients` and `sdk-internal`. Start with the repo the team field suggests, then check the other if the first shows only half the picture. | ||
|
|
||
| ## What NOT to Do | ||
|
|
||
| - Don't traverse linked issues more than one level — fetch directly linked issues (blocks, is blocked by, parent epic) but do not follow their links further | ||
| - Don't skip the parent epic check for task tickets — one extra `get_issue` call often changes the recommendation from "build this" to "confirm whether this is still wanted" | ||
| - Don't read Confluence pages unless the ticket has no description and a Confluence link is the only available context | ||
| - Don't return "cannot determine" without first checking both the named symbols AND `git log` on the relevant files | ||
| - Don't treat "symbol still exists" as "bug still present" — read the current behavior, not just the name | ||
| - Don't restate the ticket description as the verdict — the verdict must reflect what the code says today | ||
|
|
||
| ## Examples | ||
|
|
||
| ### examples/triage_workflow.md | ||
|
|
||
| Three worked examples: a bug where the described code path was silently refactored away, a task whose implementation gap is confirmed present, and a spike made obsolete by later work. | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,55 @@ | ||
| # Example: Triage Workflow | ||
|
|
||
| Three representative cases showing how the verdict changes depending on what the code investigation finds. | ||
|
|
||
| --- | ||
|
|
||
| ## Case 1: Bug silently fixed by a refactor (No longer relevant) | ||
|
|
||
| **User request**: "Is PM-XXXX still relevant?" | ||
|
|
||
| **Ticket**: Bug: a cache extension method calls `cache.Get(key)` outside a try/catch, so a cache connection failure throws an unhandled exception instead of returning null. | ||
|
|
||
| **Workflow**: | ||
|
|
||
| 1. Fetch PM-XXXX via `get_issue` → extract the described behavior and identifiers: `TryGetValue`, `DistributedCacheExtensions`, `cache.Get`. | ||
| 2. Grep in `server/src/` → `DistributedCacheExtensions.cs` exists, `TryGetValue` present. | ||
| 3. Read the file → the method exists but has **zero callers** in the codebase — the code path described by the ticket is dead. | ||
| 4. `git log` on the file → confirms no callers were added recently; the extension was made obsolete by a service refactor. | ||
|
|
||
| **Verdict**: No longer relevant. `TryGetValue` still has the exception-swallowing bug described in the ticket, but the method has no callers — the code path it describes is unreachable. Safe to close with a note that the method can be deleted. | ||
|
|
||
| --- | ||
|
|
||
| ## Case 2: Task implementation gap confirmed (Still relevant) | ||
|
|
||
| **User request**: "Is PM-YYYY still relevant?" | ||
|
|
||
| **Ticket**: Task: when only one member/group has "Can Manage" permission on a collection, that row should be disabled (greyed out) with a tooltip, rather than allowing removal and showing a validation error on save. | ||
|
|
||
| **Workflow**: | ||
|
|
||
| 1. Fetch PM-YYYY via `get_issue` → identifiers extracted: `validateCanManagePermission`, `managePermissionRequired`, `AccessItemView`, `readonly`. | ||
| 2. Grep in `clients/apps/web/src/` → `validateCanManagePermission` found in `collection-dialog.component.ts:564` and wired into the form at lines 331–333. The i18n key `managePermissionRequired` resolves to "At least one member or group must have can manage permission." | ||
| 3. Read `collection-dialog.component.html` → an error div shows the `managePermissionRequired` message when the validator fires — the error-on-submit path is what's there. | ||
| 4. Check `AccessItemView` model → has a `readonly` flag that disables the permission editor and keeps the row selected, but no logic in the component or template computes "this is the last Manage-permission row → set `readonly: true`." | ||
| 5. `git log --since` on both files → no recent commits touching the disabled-row behavior. | ||
|
|
||
| **Verdict**: Still relevant. The current implementation is the error-on-submit model: `validateCanManagePermission` blocks save when no Manage permission exists, showing an error at `collection-dialog.component.html:91-96`. The required behavior — proactively disabling the last Manage row with a tooltip — has not been implemented. `AccessItemView.readonly` could support it, but the reactive logic that sets it has never been written. | ||
|
|
||
| --- | ||
|
|
||
| ## Case 3: Spike obsoleted by later architectural work (No longer relevant) | ||
|
|
||
| **User request**: "Is PM-ZZZZ still relevant?" | ||
|
|
||
| **Ticket**: Spike from 2022: ~7,000 users have `Premium = false` but a future `PremiumExpirationDate`. The referenced code in `UserService.cs` sets `Premium = false` while preserving the expiration date. Investigate whether this is broken or intentional. | ||
|
|
||
| **Workflow**: | ||
|
|
||
| 1. Fetch PM-ZZZZ via `get_issue` → identifiers extracted: `DisablePremiumAsync`, `PremiumExpirationDate`, `Premium = false`. | ||
| 2. Grep in `server/src/` → `DisablePremiumAsync` still present at `UserService.cs:894`; sets `user.Premium = false` with `user.PremiumExpirationDate = expirationDate` — same as described. | ||
| 3. Search how `Premium` is used for access control → `ValidateUserPremiumAsync` in `LicensingService.cs` returns `user.Premium` directly for cloud users. No check on `PremiumExpirationDate`. | ||
| 4. Find a more recent `UserPremiumAccessView` SQL view → `PersonalPremium` mapped directly from `U.[Premium]`; expiration date not consulted. | ||
|
|
||
| **Verdict**: No longer relevant as an open investigation. The inconsistency (`Premium = false` with a future `PremiumExpirationDate`) still exists in the data, but later billing system work answered the spike's question in code: `PremiumExpirationDate` is billing lifecycle metadata and plays no role in access gating on cloud — `user.Premium` is the sole gate. The data inconsistency has no user-facing impact. Safe to close with a note documenting this as intentional design. |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
allowed-toolsfrontmatter property.