From 670e252d0516e804f72a5c1145a90c65cf024ea6 Mon Sep 17 00:00:00 2001 From: Patrick Honkonen Date: Tue, 4 Aug 2026 09:11:18 -0400 Subject: [PATCH 1/4] [AI-60] feat: Add filing-jira-tickets skill to bitwarden-atlassian-tools Drives the create_issue/link_issues/get_create_fields MCP tools end to end: reads a project's create screen before drafting so no project's field layout is assumed, previews each payload in plain language and takes approval before any live write, then wires and verifies dependency links. --- .claude-plugin/marketplace.json | 2 +- README.md | 2 +- .../.claude-plugin/plugin.json | 2 +- .../bitwarden-atlassian-tools/CHANGELOG.md | 6 ++ plugins/bitwarden-atlassian-tools/README.md | 13 ++++ .../skills/filing-jira-tickets/SKILL.md | 62 +++++++++++++++++++ 6 files changed, 84 insertions(+), 3 deletions(-) create mode 100644 plugins/bitwarden-atlassian-tools/skills/filing-jira-tickets/SKILL.md diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index d47cc6a0..4dbcbc40 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -48,7 +48,7 @@ { "name": "bitwarden-atlassian-tools", "source": "./plugins/bitwarden-atlassian-tools", - "version": "2.5.0", + "version": "2.6.0", "description": "Atlassian access via MCP server with deep Jira issue research skill, JQL search, Confluence pages, CQL search, attachments, and opt-in Jira write tools" }, { diff --git a/README.md b/README.md index e89f6979..b71b9aeb 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@ A curated collection of plugins for AI-assisted development at Bitwarden. Enable | [bitwarden-ai-telemetry](plugins/bitwarden-ai-telemetry/) | 1.1.0 | Claude Code hooks emitting metadata-only AI-usage telemetry (identity, git-linkage, MCP) via OTLP | | [bitwarden-tech-lead](plugins/bitwarden-tech-lead/) | 3.0.0 | Tech lead for technical planning, architecture coherence, and surfacing patterns to Technical Strategy Ideas | | [bitwarden-shepherd](plugins/bitwarden-shepherd/) | 1.0.1 | Champion of a technical strategy — shepherds a TSI through evaluation into the funnel, then through to adoption | -| [bitwarden-atlassian-tools](plugins/bitwarden-atlassian-tools/) | 2.5.0 | Atlassian access via MCP server with deep Jira issue research skill and opt-in Jira write tools | +| [bitwarden-atlassian-tools](plugins/bitwarden-atlassian-tools/) | 2.6.0 | Atlassian access via MCP server with deep Jira issue research skill and opt-in Jira write tools | | [bitwarden-code-review](plugins/bitwarden-code-review/) | 1.13.1 | Autonomous code review agent following Bitwarden engineering standards with GitHub integration | | [bitwarden-delivery-tools](plugins/bitwarden-delivery-tools/) | 2.4.0 | Delivery lifecycle skills: initiative funnel navigation, work transitions, tech breakdowns and task decomposition, commits, PRs, preflight, labeling | | [bitwarden-designer](plugins/bitwarden-designer/) | 0.1.0 | Product designer persona: Code of Conduct and 30/60/90 critique, critique facilitation; dispatches into bitwarden-design-tools | diff --git a/plugins/bitwarden-atlassian-tools/.claude-plugin/plugin.json b/plugins/bitwarden-atlassian-tools/.claude-plugin/plugin.json index 0cdf27a4..9f95a261 100644 --- a/plugins/bitwarden-atlassian-tools/.claude-plugin/plugin.json +++ b/plugins/bitwarden-atlassian-tools/.claude-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "bitwarden-atlassian-tools", - "version": "2.5.0", + "version": "2.6.0", "description": "Atlassian access via MCP server with deep Jira issue research skill, JQL search, Confluence pages, CQL search, attachments, and opt-in Jira write tools", "author": { "name": "Bitwarden" diff --git a/plugins/bitwarden-atlassian-tools/CHANGELOG.md b/plugins/bitwarden-atlassian-tools/CHANGELOG.md index 9e70bc95..513a1409 100644 --- a/plugins/bitwarden-atlassian-tools/CHANGELOG.md +++ b/plugins/bitwarden-atlassian-tools/CHANGELOG.md @@ -5,6 +5,12 @@ All notable changes to the Bitwarden Atlassian Tools plugin will be documented i The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). +## [2.6.0] - 2026-08-04 + +### Added + +- **`filing-jira-tickets` skill** — files work items that stand on their own: reads the target project's create screen first, translates work into real ticket titles and criteria placed in whatever field the project provides, previews each payload and takes approval before writing it, then wires and verifies dependency links. Approval is the default and only an explicit instruction skips it. + ## [2.5.0] - 2026-08-03 ### Added diff --git a/plugins/bitwarden-atlassian-tools/README.md b/plugins/bitwarden-atlassian-tools/README.md index aae03fb5..6bc94052 100644 --- a/plugins/bitwarden-atlassian-tools/README.md +++ b/plugins/bitwarden-atlassian-tools/README.md @@ -162,6 +162,19 @@ Features: - Automatic Confluence page follow-through from remote links - Context budget guidance and graceful degradation +### `filing-jira-tickets` + +Files Jira work items that stand on their own. Reads the target project's create screen before drafting, so no project's field layout is assumed, previews each payload before writing it, then wires and verifies dependency links. Triggered by intent to create or link tickets (e.g., "file a bug for this", "create a story for this work", "wire the blocked-by relationship"). + +Features: + +- Discovers issue types, required fields, and allowed values per project rather than hardcoding them, which matters because Bitwarden's projects differ (PM and SM expose an Acceptance criteria field, QA and VULN do not; VULN has no Story type; PLT's only creatable type is `Platform Initiative`) +- Dry-run preview of the exact payload before every live write +- Approval required before each create, unless explicitly told to skip it +- Role-named link arguments (`blockerKey`, `blockedKey`) so dependency direction cannot be inverted + +Live creation requires `ATLASSIAN_JIRA_WRITE_TOKEN`; without it the skill can still draft and preview. + ## Requirements - Claude Code with MCP support diff --git a/plugins/bitwarden-atlassian-tools/skills/filing-jira-tickets/SKILL.md b/plugins/bitwarden-atlassian-tools/skills/filing-jira-tickets/SKILL.md new file mode 100644 index 00000000..dcdfe737 --- /dev/null +++ b/plugins/bitwarden-atlassian-tools/skills/filing-jira-tickets/SKILL.md @@ -0,0 +1,62 @@ +--- +name: filing-jira-tickets +description: File Jira work items that stand on their own, with real ticket titles, acceptance criteria in whatever field the target project provides, and verified dependency links. Reads the target project's create screen first, so no project's field layout is assumed. +when_to_use: Use when the user is ready to create one or more Jira work items and wants them filed correctly. Phrasings like "file a bug for this", "create a story for this work", "open a spike", "file these tickets", "link these two tickets", or "wire the blocked-by relationship". Also use when another skill hands off a set of drafted tickets to create. Do not use for reading or researching existing issues (that is researching-jira-issues), or for editing tickets that already exist. +allowed-tools: Read, AskUserQuestion, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_issue, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_create_fields +--- + +# Filing Jira Tickets + +Tickets get read outside the context that produced them, so each one has to stand alone. + +Live tickets are awkward to unwind, so `create_issue` and `link_issues` both default to a dry run that returns the exact payload without sending it. Preview before every live write. A live write takes an explicit `dryRun: false`. + +Nothing gets created without approval unless you are explicitly told to skip it. See Step 3. + +## Step 1: Read the target project's create screen + +Bitwarden files into many projects and they do not share a shape. PM and SM expose an Acceptance criteria field; QA, VULN, and PLT do not. VULN has no Story type. PLT's only creatable type is `Platform Initiative`. Never assume a field id, a required field, or that an issue type exists. + +Call `get_create_fields` with the project key, and again with the intended issue type. It returns the project's creatable types, then every field on that type's create screen with its id, whether it is required, and its allowed values. + +- The type is not in the list: pick from what the project offers, or ask the user which one they want. +- The project answers "You cannot create issues in this project": stop and tell the user they lack create permission there. Do not try another project. + +**Completion criterion:** for the target project and issue type, a list of the required fields and the ids of any optional fields this work should populate. + +## Step 2: Draft the ticket + +Translate the work into fields. Do not paste in whatever the source document said. + +- **Title.** Imperative verb, outcome, and area: `Add CSV export to the item list (web)`. Match the style of sibling tickets under the same parent, and check one if you are unsure. +- **Description.** One short paragraph of the actual work, plus any caveat specific to this ticket. No lineage boilerplate such as `Part of PM-1234`, and no path to a source document; the parent link already conveys that. Spell out shorthand rather than using symbols. +- **Acceptance criteria.** If Step 1 showed the project has a criteria field, pass the criteria there through `fields`, keyed by that field's id. Gherkin (`Scenario`, `Given`, `When`, `Then`, `And`) as plain text. If the project has no such field, put the criteria in the description under their own paragraph and tell the user that is what you did. Do not invent a field id. +- **Required fields.** Supply every one Step 1 reported. Where a value is a business judgement rather than something derivable from the work, ask the user and offer the allowed values Step 1 returned. Do not guess, and do not pick the first option. +- **Labels.** Only what the user asked for. + +**Completion criterion:** a drafted payload per ticket that satisfies every required field Step 1 reported. + +## Step 3: Preview, approve, create + +For each ticket, in the order given: + +1. Dry-run it. +2. Verify the tool's raw output against Step 1: every required field present, criteria in the field Step 1 identified (or in the description if the project has none), parent correct, title makes sense to someone who has not read the source material. +3. Show the user a plain-language preview: title, full description text, full acceptance criteria, parent, labels. +4. Get approval on that preview. Then create it with `dryRun: false` and record the returned key. + +**Approval before every create is the default.** Skip it only when explicitly told to file without approval. + +If a create fails naming a field, re-read Step 1 for that project instead of guessing at the fix. + +**Completion criterion:** every requested ticket previewed, approved, and created, with each returned key recorded. + +## Step 4: Wire dependency links + +Linking is reversible, so this step can run as a batch once the tickets exist. + +- A hard dependency, where one item must land before another can start, is `Blocks`. Soft or ordering-only is `Relates`. +- For `Blocks`, pass `blockerKey` for the item that must land first and `blockedKey` for the item waiting on it. The tool maps those onto Jira's inward and outward sides internally, so the direction cannot be inverted by getting the argument order wrong. +- Verify each link by reading the ticket back with `get_issue`. Check it against the Linked Issues panel in Jira if anything looks off. + +**Completion criterion:** every relationship whose target ticket exists is created and verified. Relationships pointing at work that does not exist yet are reported back to the user, not dropped. From b2dd963c2a72b07004143243be9156fed342e77b Mon Sep 17 00:00:00 2001 From: Patrick Honkonen Date: Tue, 4 Aug 2026 11:09:28 -0400 Subject: [PATCH 2/4] Drop redundant manual link verification now that link_issues self-verifies --- .../skills/filing-jira-tickets/SKILL.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/plugins/bitwarden-atlassian-tools/skills/filing-jira-tickets/SKILL.md b/plugins/bitwarden-atlassian-tools/skills/filing-jira-tickets/SKILL.md index dcdfe737..a7fe3b4f 100644 --- a/plugins/bitwarden-atlassian-tools/skills/filing-jira-tickets/SKILL.md +++ b/plugins/bitwarden-atlassian-tools/skills/filing-jira-tickets/SKILL.md @@ -57,6 +57,6 @@ Linking is reversible, so this step can run as a batch once the tickets exist. - A hard dependency, where one item must land before another can start, is `Blocks`. Soft or ordering-only is `Relates`. - For `Blocks`, pass `blockerKey` for the item that must land first and `blockedKey` for the item waiting on it. The tool maps those onto Jira's inward and outward sides internally, so the direction cannot be inverted by getting the argument order wrong. -- Verify each link by reading the ticket back with `get_issue`. Check it against the Linked Issues panel in Jira if anything looks off. +- `link_issues` reads the link back itself and reports whether it verified. If it reports it could not verify, read the ticket back yourself with `get_issue` and check it against the Linked Issues panel in Jira before treating the link as done. **Completion criterion:** every relationship whose target ticket exists is created and verified. Relationships pointing at work that does not exist yet are reported back to the user, not dropped. From 2696116e3d70c49ca42d76b9bdc311d41eaad760 Mon Sep 17 00:00:00 2001 From: Patrick Honkonen Date: Tue, 4 Aug 2026 11:33:43 -0400 Subject: [PATCH 3/4] Address local review findings on the filing-jira-tickets skill Stop routing the link-verification fallback through get_issue, whose output has no links section to check. Split Gherkin criteria across descriptionParagraphs entries when there is no criteria field, since a single paragraph has no line-break node and would render as one run-on line. Reflect that a failed create screen read can mean either a missing project or missing permission, matching what get_create_fields actually reports. Drop get_issue from allowed-tools now that nothing in the skill calls it. --- .../skills/filing-jira-tickets/SKILL.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/plugins/bitwarden-atlassian-tools/skills/filing-jira-tickets/SKILL.md b/plugins/bitwarden-atlassian-tools/skills/filing-jira-tickets/SKILL.md index a7fe3b4f..78d92d37 100644 --- a/plugins/bitwarden-atlassian-tools/skills/filing-jira-tickets/SKILL.md +++ b/plugins/bitwarden-atlassian-tools/skills/filing-jira-tickets/SKILL.md @@ -2,7 +2,7 @@ name: filing-jira-tickets description: File Jira work items that stand on their own, with real ticket titles, acceptance criteria in whatever field the target project provides, and verified dependency links. Reads the target project's create screen first, so no project's field layout is assumed. when_to_use: Use when the user is ready to create one or more Jira work items and wants them filed correctly. Phrasings like "file a bug for this", "create a story for this work", "open a spike", "file these tickets", "link these two tickets", or "wire the blocked-by relationship". Also use when another skill hands off a set of drafted tickets to create. Do not use for reading or researching existing issues (that is researching-jira-issues), or for editing tickets that already exist. -allowed-tools: Read, AskUserQuestion, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_issue, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_create_fields +allowed-tools: Read, AskUserQuestion, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_create_fields --- # Filing Jira Tickets @@ -20,7 +20,7 @@ Bitwarden files into many projects and they do not share a shape. PM and SM expo Call `get_create_fields` with the project key, and again with the intended issue type. It returns the project's creatable types, then every field on that type's create screen with its id, whether it is required, and its allowed values. - The type is not in the list: pick from what the project offers, or ask the user which one they want. -- The project answers "You cannot create issues in this project": stop and tell the user they lack create permission there. Do not try another project. +- The tool reports it cannot read the create screen (a 404): this means the project key does not exist, or the user lacks create permission there — the tool cannot tell which. Re-check the project key for a typo before concluding the latter; if it's correct, tell the user they likely lack create permission and stop. Do not guess at a different project. **Completion criterion:** for the target project and issue type, a list of the required fields and the ids of any optional fields this work should populate. @@ -30,7 +30,7 @@ Translate the work into fields. Do not paste in whatever the source document sai - **Title.** Imperative verb, outcome, and area: `Add CSV export to the item list (web)`. Match the style of sibling tickets under the same parent, and check one if you are unsure. - **Description.** One short paragraph of the actual work, plus any caveat specific to this ticket. No lineage boilerplate such as `Part of PM-1234`, and no path to a source document; the parent link already conveys that. Spell out shorthand rather than using symbols. -- **Acceptance criteria.** If Step 1 showed the project has a criteria field, pass the criteria there through `fields`, keyed by that field's id. Gherkin (`Scenario`, `Given`, `When`, `Then`, `And`) as plain text. If the project has no such field, put the criteria in the description under their own paragraph and tell the user that is what you did. Do not invent a field id. +- **Acceptance criteria.** If Step 1 showed the project has a criteria field, pass the criteria there through `fields`, keyed by that field's id, as a single string of Gherkin (`Scenario`, `Given`, `When`, `Then`, `And`) — that field is plain text, so embedded line breaks render fine. If the project has no such field, put the criteria in the description instead: pass each Gherkin line as its own `descriptionParagraphs` entry, since each entry becomes one paragraph and a paragraph has no line-break node of its own. Tell the user that is what you did. Do not invent a field id. - **Required fields.** Supply every one Step 1 reported. Where a value is a business judgement rather than something derivable from the work, ask the user and offer the allowed values Step 1 returned. Do not guess, and do not pick the first option. - **Labels.** Only what the user asked for. @@ -57,6 +57,6 @@ Linking is reversible, so this step can run as a batch once the tickets exist. - A hard dependency, where one item must land before another can start, is `Blocks`. Soft or ordering-only is `Relates`. - For `Blocks`, pass `blockerKey` for the item that must land first and `blockedKey` for the item waiting on it. The tool maps those onto Jira's inward and outward sides internally, so the direction cannot be inverted by getting the argument order wrong. -- `link_issues` reads the link back itself and reports whether it verified. If it reports it could not verify, read the ticket back yourself with `get_issue` and check it against the Linked Issues panel in Jira before treating the link as done. +- `link_issues` reads the link back itself and reports whether it verified. If it reports it could not verify, tell the user and point them at Jira's Linked Issues panel directly — `get_issue`'s output has no links section, so it cannot confirm this for you. **Completion criterion:** every relationship whose target ticket exists is created and verified. Relationships pointing at work that does not exist yet are reported back to the user, not dropped. From 166f0ddfede4ecb2964160d4279a33bef43f719a Mon Sep 17 00:00:00 2001 From: Patrick Honkonen Date: Tue, 4 Aug 2026 11:48:29 -0400 Subject: [PATCH 4/4] Drop AskUserQuestion from allowed-tools; it needs no pre-approval --- .../skills/filing-jira-tickets/SKILL.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/plugins/bitwarden-atlassian-tools/skills/filing-jira-tickets/SKILL.md b/plugins/bitwarden-atlassian-tools/skills/filing-jira-tickets/SKILL.md index 78d92d37..a0acc377 100644 --- a/plugins/bitwarden-atlassian-tools/skills/filing-jira-tickets/SKILL.md +++ b/plugins/bitwarden-atlassian-tools/skills/filing-jira-tickets/SKILL.md @@ -2,7 +2,7 @@ name: filing-jira-tickets description: File Jira work items that stand on their own, with real ticket titles, acceptance criteria in whatever field the target project provides, and verified dependency links. Reads the target project's create screen first, so no project's field layout is assumed. when_to_use: Use when the user is ready to create one or more Jira work items and wants them filed correctly. Phrasings like "file a bug for this", "create a story for this work", "open a spike", "file these tickets", "link these two tickets", or "wire the blocked-by relationship". Also use when another skill hands off a set of drafted tickets to create. Do not use for reading or researching existing issues (that is researching-jira-issues), or for editing tickets that already exist. -allowed-tools: Read, AskUserQuestion, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_create_fields +allowed-tools: Read, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_create_fields --- # Filing Jira Tickets