feat: add creating-jira-tickets delivery skill - #170
Conversation
Turns a tech breakdown's tasks.md into Jira tickets — an epic plus one child story/task per task entry, with real ticket titles, a Gherkin Acceptance criteria ADF section, and wired Blocked-by/Depends-on links. Creates tickets one at a time behind a human-in-the-loop review gate and goes through the acli CLI. Includes an acli/ADF reference and a skill-creator eval set (7 behavior cases + a 10/10 trigger set). Bumps bitwarden-delivery-tools 2.1.0 -> 2.2.0 (marketplace.json, plugin.json, README, CHANGELOG) and adds acli/workitem to the cspell dictionary.
gbubemismith
added
the
ai-review-vnext
Plugin Validation Summary — PR #170Plugin: All three validation passes completed: plugin structure (plugin-validator), skill review (skill-reviewer), and security review (reviewing-claude-config). Findings are minor/non-blocking warnings only. 1. Plugin Validation (plugin-validator) — ✅ PASS
2. Skill Review (skill-reviewer) — ✅ PASSReviewed
3. Security Review (reviewing-claude-config) — ✅ PASS
Minor Warnings (non-blocking — should-fix, optional)
NoteThe repo validators Overall: ✅ All checks pass. The new |
🤖 Bitwarden Claude Code ReviewOverall Assessment: APPROVE Reviewed the new Code Review DetailsNo new findings. The one prior unresolved thread on Verified during review:
|
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
SaintPatrck
left a comment
SaintPatrck
left a comment
There was a problem hiding this comment.
💭 creating-jira-tickets seems to be conflating two separate functions that can be split into smaller, composable skills; filing-jira-tickets as a bitwarden-atlassian-tools skill responsible for providing instructions on how to create a Bitwarden Jira ticket, and filing-breakdown-tasks as another separate skill responsible for providing instructions on how to process tasks.md and feed the details to filing-jira-tickets.
That type of hierarchy makes filing-jira-tickets reusable outside of tech-breakdown context. There has already been desire expressed for a standalone Skill to create Jira tickets. I think splitting them now would be easier and cheaper than deferring it.
What do you think? I'm happy to help draft the split if you like the idea.
| name: creating-jira-tickets | ||
| description: Create Jira tickets from a tech breakdown's tasks.md — an epic plus one child story/task per task entry, with real ticket titles, a Gherkin Acceptance criteria section, and wired Blocked-by/Depends-on links. | ||
| when_to_use: Use when the user is ready to file a breakdown's tasks in Jira — phrasings like "create the tickets from tasks.md", "make Jira tickets for these tasks", "file the epic and stories", "turn this breakdown into Jira tickets". Also use when decomposing-into-tasks or developing-breakdown-plan hands off a finished tasks.md. Do not use for reading or researching existing issues (that is researching-jira-issues), or for editing tickets that already exist. | ||
| allowed-tools: Read, Write, Glob, AskUserQuestion, Bash(acli jira auth status:*), Bash(acli jira workitem view:*), Bash(acli jira workitem create:*), Bash(acli jira workitem edit:*), Bash(acli jira workitem link:*) |
There was a problem hiding this comment.
AskUserQuestion does not need to be specified. It's implicitly granted.
| allowed-tools: Read, Write, Glob, AskUserQuestion, Bash(acli jira auth status:*), Bash(acli jira workitem view:*), Bash(acli jira workitem create:*), Bash(acli jira workitem edit:*), Bash(acli jira workitem link:*) | |
| allowed-tools: Read, Write, Glob, Bash(acli jira auth status:*), Bash(acli jira workitem view:*), Bash(acli jira workitem create:*), Bash(acli jira workitem edit:*), Bash(acli jira workitem link:*) |
|
|
||
| Two facts shape every step: | ||
|
|
||
| - **acli for everything.** Reads and writes go through the `acli` CLI. |
There was a problem hiding this comment.
❓ Did you happen to consider adding a create_issue tool and sibling Skill to our bitwarden-atlassian-tools MCP server instead of using acli? If so, what was the deciding factor?
| Confirm `acli` can write before drafting anything: | ||
|
|
||
| - Run `acli jira auth status`. | ||
| - Missing binary → prompt to install (`brew install atlassian/homebrew-acli/acli`, or the Atlassian CLI docs) and **stop**. |
There was a problem hiding this comment.
brew isn't available on Windows, and not every consumer will have brew installed. This could cause Claude to fall down a rabbit-hole. What do you think about rephrasing this so that it only points to the installation docs? That puts onus on the user to set their environment up properly.
|
|
||
| **Completion criterion:** an echoed tree — epic key, then the ordered children with type and parent — where the child count matches the task count in `tasks.md`. | ||
|
|
||
| ## Step 3 — Turn each task into real ticket fields |
There was a problem hiding this comment.
❓ Available and Required fields vary based on several factors, but I don't see any guidance provided around that. How does the LLM behave when it encounters required fields it didn't/can't populate, or a field not being available?
Thanks for the comments @SaintPatrck. Yeah I agree, I'll split these into two skills |
2 participants
🎟️ Tracking
No linked Jira ticket — introduces a new delivery skill for the
bitwarden-delivery-toolsplugin in the ai-plugins marketplace.📔 Objective
Adds the
creating-jira-ticketsskill, which turns a tech breakdown'stasks.mdinto Jira tickets: an epic plus one child story/task per task entry, with real ticket titles, a Gherkin Acceptance criteria ADF section, and wired Blocked-by/Depends-on links. Tickets are created one at a time behind a human-in-the-loop review gate, and all reads/writes go through theacliCLI (the Atlassian MCP is read-only).Ships alongside:
acli/ADF reference doc (references/acli-and-adf.md),skill-creatoreval set — 7 behavior cases plus a 10/10 trigger set.Bumps
bitwarden-delivery-tools2.1.0 → 2.2.0 (marketplace.json, plugin.json, README, CHANGELOG) and addsacli/workitemto the cspell dictionary.