skilld
All skills
bitwarden avatar

/filing-breakdown-tasks

@c50ba9d official
by bitwardenbitwarden/ai-plugins155 stars
20

Turn a tech breakdown's tasks.md into Jira ticket drafts — an epic parent plus one child story/task per task entry, each a real ticket with acceptance criteria and mapped Blocked-by/Depends-on links — then hand off to filing-jira-tickets to file them.

Ask your Agent

Use this Skill: https://skilld.dev/gh/bitwarden/ai-plugins/filing-breakdown-tasks

This session only. Nothing lands on disk.

SKILL.md

≈70 tokens always: the name and description. ≈977 when used: this file. ≈2.5k more on demand in 3 files.

Filing Breakdown Tasks into Jira

This skill owns the tech-breakdown half of ticketing: turning a tasks.md decomposition into a parented set of ticket drafts. It does not file them. Once the drafts are ready it hands off to filing-jira-tickets, which reads the target project's create screen, previews each ticket, takes approval, and creates and links them through the Atlassian MCP write tools.

Tickets are read outside the breakdown's context, so translate each task entry into a ticket that stands on its own — never paste the decomposition label.

Step 1 — Build the ticket tree

Read tasks.md and its sibling breakdown.md. The pair lives in one breakdown folder (<team>/<JIRA-KEY>-<short-slug>/) in a bitwarden/tech-breakdowns checkout — Glob for it when the user gave no path, and ask which one when more than one matches. If breakdown.md is missing or names no epic key, ask for the key.

Establish the hierarchy before drafting any fields:

  • The breakdown's epic is the parent. Take its key from breakdown.md. If no epic exists, ask whether to create one or attach children to an existing key — do not guess a key. Confirm the key is an Epic (get_issue, check issuetype) before parenting under it.
  • Each task entry becomes one child — Story by default; Task or Bug only if the entry says so.
  • For each child, capture its Blocked by and Depends on.

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 2 — Draft each child ticket

Translate each entry into ticket fields; don't copy it:

  • Title — imperative verb + outcome + context (client/area), matching sibling-ticket house style, e.g. Add CSV export to the item list (web). NOT the decomposition label (ExportService + column mapping (libs/exporter)).
  • Description — one short paragraph of the actual work plus genuinely per-ticket caveats. No lineage boilerplate (Part of PM-XXXX), no breakdown path — the epic-child link already conveys that.
  • Acceptance criteria — written in Gherkin (Scenario / Given / When / Then / And). Supply the content only; filing-jira-tickets decides the field — the project's criteria field, or the description if it has none.
  • Parent — the epic key from Step 1.

Leave labels unset unless the user asked for a specific one.

Completion criterion: for every child, a draft of {title, description, acceptance criteria, type, parent}.

Step 3 — Map the dependency links

From each task's Blocked by / Depends on, build the link map filing-jira-tickets will wire:

  • Hard dependency (must land first) → Blocks, with the must-land-first ticket as the blocker.
  • Soft / ordering-only → Relates.
  • A dependency whose target has no ticket in this set (e.g. a sibling slice not yet filed) → report it to the user, don't drop it.

Completion criterion: a link map of {blocker, blocked, type} for every dependency whose both ends are tickets in this set.

Step 4 — Hand off to filing-jira-tickets

Hand the drafted tickets (Step 2) and the link map (Step 3) to Skill(bitwarden-atlassian-tools:filing-jira-tickets). It owns the rest: reading the project's create screen, dry-run previews, per-ticket approval, live creation, and link verification.

That skill ships in bitwarden-atlassian-tools. If it is unavailable, stop and prompt the user to install the plugin (/plugin install bitwarden-atlassian-tools@bitwarden-marketplace), then hand off. Never file the drafts by another route, and never drop them silently.

If an epic is being created rather than reused, file it first so the children have a parent key to reference.

Completion criterion: filing-jira-tickets has the full draft set and link map and has taken over creation.

Source: SKILL.md on GitHub

Third-party checks

No alerts24d3 checks · Risk SAFE
  • Gen Agent Trust Hub24d

    The skill is safe. It is designed to automate the creation of Jira ticket drafts from local tech breakdown files (tasks.md). It includes a developer utility for testing the skill's triggering logic via the agent CLI. The skill operates within the vendor's ecosystem, referencing other Bitwarden-authored tools.

  • Socket24d

    No alerts

  • Snyk24d

    Risk: LOW · No issues

Provenance

Signed by skilld at c50ba9d. This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub yesterday.

Activeupdated last month

Capability

What it can do
Reads files
MCP servers
plugin_bitwarden-atlassian-tools_bitwarden-atlassian
All 4 allowed tools
ReadGlobSkill(bitwarden-atlassian-tools:filing-jira-tickets)mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_issue
Other metadata
when_to_use
Use only when starting from a finished tasks.md (a tech breakdown's task decomposition) to create a set of new Jira tickets — 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 a tech breakdown in bitwarden/tech-breakdowns hands off a finished tasks.md. Do not use to edit or update an existing ticket's fields such as description, acceptance criteria, status, or labels (there's no tasks.md involved); to read or research existing issues (that is researching-jira-issues); or to move, organize, or otherwise manage breakdown files and folders.

README badge

README badge for bitwarden/ai-plugins/filing-breakdown-tasks