[AI-62] feat: Add filing-jira-tickets skill to bitwarden-atlassian-tools #189
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
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 |
|---|---|---|
| @@ -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, 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 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. | ||
|
|
||
| ## 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, 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. | ||
|
Contributor
There was a problem hiding this comment. 🎨 SUGGESTED: "that field is plain text" is only verified for PM's Details and fix
Rationale: everywhere else this skill refuses to assume project shape ("Never assume a field id, a required field, or that an issue type exists"), and Step 1 is already the authority on the type. This closes the one place where a shape is assumed.
Contributor
Author
There was a problem hiding this comment. Speculative failure. If/when this manifests as an issue it will be addressed at that time. |
||
| - **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. | ||
| - `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. | ||
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.
Uh oh!
There was an error while loading. Please reload this page.