feat: add creating-jira-tickets delivery skill

[gbubemismith]

🎟️ Tracking

No linked Jira ticket — introduces a new delivery skill for the bitwarden-delivery-tools plugin in the ai-plugins marketplace.

📔 Objective

Adds the creating-jira-tickets skill, which 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. Tickets are created one at a time behind a human-in-the-loop review gate, and all reads/writes go through the acli CLI (the Atlassian MCP is read-only).

Ships alongside:

• an acli/ADF reference doc (references/acli-and-adf.md),
• a skill-creator eval set — 7 behavior cases plus 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.

[github-actions]

Plugin Validation Summary — PR #170

Plugin: bitwarden-delivery-tools · Version: 2.2.0
Result: ✅ PASS — no critical or major issues. Ready to merge.

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

Check	Result
plugin.json manifest (name, semver, required fields)	✅ Valid — bitwarden-delivery-tools / 2.2.0, well-formed author, homepage, repository, keywords
Version consistency across plugin.json / marketplace.json / CHANGELOG	✅ All three at 2.2.0
CHANGELOG format (Keep a Changelog)	✅ ## [2.2.0] - 2026-07-23 under Added; correct for a MINOR bump (new backward-compatible skill)
Directory structure & auto-discovery	✅ Skill lives at skills/creating-jira-tickets/ with SKILL.md, references/, evals/
Eval JSON parse (evals.json, trigger-eval.json)	✅ Both parse cleanly; hermetic placeholder fixtures
Hardcoded credentials	✅ None

2. Skill Review (skill-reviewer) — ✅ PASS

Reviewed skills/creating-jira-tickets/SKILL.md.

Check	Result
Frontmatter (name, description, when_to_use, allowed-tools)	✅ All present and valid
Description quality (specific, third-person, ~258 chars)	✅ Names the tasks.md artifact, output shape, and distinctive features
Trigger design	✅ Concrete phrases + explicit negative boundaries (defers to researching-jira-issues, excludes editing existing tickets)
Word count (target 1,000–3,000)	✅ Lean: ~700–830 words body, ~583 words in reference
Writing style (imperative/infinitive)	✅ Consistent; each step ends with a testable Completion criterion
Progressive disclosure	✅ Mechanics/ADF JSON/inverted-link details pushed to references/acli-and-adf.md
Referenced files exist	✅ references/acli-and-adf.md link at SKILL.md:46 resolves
allowed-tools scoping	✅ Least-privilege — Bash gated to specific acli jira subcommands, no bare Bash/Edit/network

3. Security Review (reviewing-claude-config) — ✅ PASS

Check	Result
Committed secrets / API keys / tokens / passwords	✅ None found
Hardcoded credentials	✅ None — acli jira auth login --web uses interactive web auth
settings.local.json committed	✅ N/A — no settings files in this PR
Permission scoping	✅ allowed-tools narrowly scoped to acli jira subcommands
Host references	✅ bitwarden.atlassian.net is the org's public Jira host, not a credential

---

Minor Warnings (non-blocking — should-fix, optional)

• skills/creating-jira-tickets/evals/README.md:11 — Instructs running trigger-eval.json via a sibling skill's runner (../creating-pull-request/evals/run_real_eval.py) "after setting its TARGET_SKILL_TOKEN to creating-jira-tickets". Editing another skill's file in place is fragile — an accidental commit would break the creating-pull-request eval. Fix: copy the runner into this skill's evals/, or parameterize the token via env var / CLI arg instead of an in-place edit.
• skills/creating-jira-tickets/SKILL.md:4 (when_to_use) — Upstream skill-creator guidance prefers folding triggers into description, but this repo's sibling skills (force-multiplier, creating-pull-request) consistently use when_to_use. Kept as-is is fine for repo consistency; flagged only for awareness.
• skills/creating-jira-tickets/SKILL.md:66 — Prose mention of "the reference" is not a clickable link, unlike SKILL.md:46. Optional: make it a link for parity.

Note

The repo validators ./scripts/validate-plugin-structure.sh and ./scripts/validate-marketplace.sh could not be executed in this sandbox (command approval unavailable). All fields those scripts check — required files, plugin.json fields, frontmatter presence, changelog format, and cross-file version consistency — were verified manually and pass. Recommend confirming they run green in CI.

---

Overall: ✅ All checks pass. The new creating-jira-tickets skill is complete, well-structured, and secure. Versioning is consistent at 2.2.0 across all tracked locations with a correct CHANGELOG entry. The three findings above are minor documentation/process improvements and do not block the PR.

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

Reviewed the new creating-jira-tickets delivery skill (SKILL.md, acli/ADF reference, and eval set), plus the bitwarden-delivery-tools 2.1.0 → 2.2.0 version bump and cspell additions. The version bump is consistent across marketplace.json, plugin.json, README, and CHANGELOG. Skill frontmatter matches the sibling creating-pull-request conventions and follows progressive disclosure. The previously flagged link-direction contradiction in the acli reference is now resolved: the create example (blocker on --in), the link list read-back interpretation, and eval case 6 are all internally consistent.

Code Review Details

No new findings. The one prior unresolved thread on references/acli-and-adf.md (inverted link-list read-back) is now addressed and marked outdated — the create example and read-back describe the same relationship in the same direction.

Verified during review:

• Referenced sibling eval script ../creating-pull-request/evals/run_real_eval.py exists and its TARGET_SKILL_TOKEN variable is real.
• No dependency manifest or lock file changes; no new dependencies requiring AppSec review.
• No security-sensitive code paths introduced (documentation/skill content only).