Add Jira Delivery Bridge community module

[mathi0u]

New Module Submission

Module name: Jira Delivery Bridge
Repository: https://github.com/mathi0u/jira-delivery-bridge
Release: https://github.com/mathi0u/jira-delivery-bridge/releases/tag/v1.0.0
Version tag: v1.0.0
Commit SHA: d266fb00b04e4695d1013ef6cad3675cb7e13ba4
Category / Subcategory: business-and-strategy / project-management

Checklist

• Repository contains a valid .claude-plugin/marketplace.json
• All skill paths in the manifest resolve to directories with SKILL.md
• Module passes Validate Module (VM) with no critical findings
• README.md documents what the module does, how to install, and any external dependencies
• LICENSE file present in source repo
• Registry YAML entry added to registry/community/ with pinned tag, SHA, category, and subcategory
• Category and subcategory exist in categories.yaml

Description

Jira Delivery Bridge is a reusable BMad module for teams that run planning and execution inside BMad but need structured delivery visibility in Jira.

The module is intentionally scoped around one rule: BMad remains the source of truth. Jira receives bounded, reviewable publication output rather than becoming the hidden driver of delivery state.

This first release includes five workflows:

• jdb-setup registers config and help entries
• jdb-configure-jira-sync validates a Jira target and seeds mappings, audience profiles, and schema notes
• jdb-publish-story-sync publishes or previews story-level visibility
• jdb-publish-sprint-sync publishes or previews sprint-level summaries for different audiences
• jdb-ingest-jira-signals ingests only allowlisted Jira-side signals as advisories or explicitly approved updates

Why This Module Adds Value

This module fills a gap between BMad execution artifacts and stakeholder-facing Jira visibility:

• teams can keep BMad as the planning system while still exposing progress in Jira
• publication is preview-first and conservative about Jira writes
• return sync is narrow and controlled instead of broad bidirectional mirroring
• visibility can be tailored for clients, administrative staff, leads, and engineers
• generated previews, reports, and receipts make sync runs auditable

Validation Evidence

The submission is not just packaged; it has been exercised:

• dedicated public source repo created: mathi0u/jira-delivery-bridge
• tagged public release created: v1.0.0
• remote install smoke test passed using:

npx bmad-method install --custom-source https://github.com/mathi0u/jira-delivery-bridge --tools claude-code --yes

Smoke test outcome:

• installer discovered Jira Delivery Bridge v1.0.0
• module installed successfully into _bmad/jdb/
• the 5 JDB skills were installed and visible in the Claude Code skill set
• generated module config and module help catalog were present after install

External Dependencies

• python3
• uv recommended for merge-config.py
• Jira API access and credentials via an environment variable such as JIRA_API_TOKEN

Reviewer Notes

• Repo is public and license is MIT
• Release tag and pinned SHA match the submitted registry entry
• The module is intentionally conservative about external writes and keeps Jira-side synchronization bounded to the documented contract

[coderabbitai]

Walkthrough

A new community module registry entry for jira-delivery-bridge is added with metadata including identifiers, description, repository reference, module definition path, author/license, versioning (1.0.0), and initial unverified trust status with pending review.

Changes

Module Registry Entry

Layer / File(s)	Summary
Registry Metadata registry/community/jira-delivery-bridge.yaml	New module entry for jira-delivery-bridge (code: jdb) with name, display name, description, GitHub repository, module definition path (skills/jdb-setup/assets/module.yaml), author/license, category/subcategory, keywords, version 1.0.0, approval metadata, trust_tier: unverified, and reviewer: pending.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐰 A bridge to Jira now rests in our keep,
With metadata neat, stacked row after row,
Code jdb hops where our workflows will leap,
Awaiting review, we let trust gently grow. ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The pull request title accurately summarizes the primary change—adding a new community module for Jira Delivery Bridge to the registry.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull request overview

Adds a new community module entry to the BMad module registry for “Jira Delivery Bridge”, enabling it to be discovered/installed via the registry under the business-and-strategy / project-management category.

Changes:

• Added a new community registry YAML entry for jira-delivery-bridge with pinned approved_tag and approved_sha.
• Declared module metadata (display name, short code, description, keywords, category/subcategory, trust tier, and approval date).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[coderabbitai]

🧹 Nitpick comments (1)

registry/community/jira-delivery-bridge.yaml (1)

24-25: Clarify approved_date semantics; reviewer: pending appears to follow registry convention.

The grep results show that reviewer: pending is an established convention in other community modules (e.g., suno-band-manager.yaml), so this is not a schema violation—it indicates awaiting reviewer assignment.

However, clarify the approved_date field: it's set to "2026-05-02" (the PR creation date), but this should reflect the actual approval date, not the submission date. Either update this at merge time when the PR is formally approved, or confirm that this field captures submission date rather than approval date per registry conventions.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@registry/community/jira-delivery-bridge.yaml` around lines 24 - 25, The YAML
has ambiguous semantics: leave reviewer: pending as-is (that's an established
convention), but change how approved_date is handled—either clear or remove the
current hard-coded "2026-05-02" and ensure approved_date in
jira-delivery-bridge.yaml is set only when the PR is formally approved (i.e.,
update approved_date at merge to the actual approval date) or set it to an
explicit sentinel (null/empty) to indicate "not yet approved"; update any
documentation or a short inline note near the approved_date field to state that
approved_date represents the approval date, not the submission date.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@registry/community/jira-delivery-bridge.yaml`:
- Around line 24-25: The YAML has ambiguous semantics: leave reviewer: pending
as-is (that's an established convention), but change how approved_date is
handled—either clear or remove the current hard-coded "2026-05-02" and ensure
approved_date in jira-delivery-bridge.yaml is set only when the PR is formally
approved (i.e., update approved_date at merge to the actual approval date) or
set it to an explicit sentinel (null/empty) to indicate "not yet approved";
update any documentation or a short inline note near the approved_date field to
state that approved_date represents the approval date, not the submission date.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: a3cea83c-0eea-4a7c-be11-b86202312f45

📥 Commits

Reviewing files that changed from the base of the PR and between b1cc5e3 and 118b2f0.

📒 Files selected for processing (1)

• registry/community/jira-delivery-bridge.yaml

[mathi0u]

Thanks for the review. I checked the current marketplace contribution template before making any change.

For new community module submissions, the repository currently documents this exact shape in CONTRIBUTING.md:

• approved_date: "<today's date>"
• reviewer: pending

The existing community entries also follow that convention today. Based on that, I’m leaving approved_date: "2026-05-02" as-is for now because it matches the documented submission template for a new module entry.

If the maintainers want approved_date to mean merge or approval date instead of submission date, I’m happy to update this PR to the preferred convention.

[bmadcode]

@mathi0u thank you - team is reviewing!