Inspiration
Software teams often have Jira issues that look complete on a board but lack a clear owner, acceptance criteria, a due date, test evidence, or an explicit resolution of blockers. This creates avoidable back-and-forth during review and release preparation. Status alone does not explain whether a work item is sufficiently documented, so we wanted Jira to say what is missing, in the place where the team already works.
What it does
EvidencePulse adds two lightweight, read-only Forge modules inside Jira:
- Issue readiness panel (
jira:issuePanel) analyzes the issue currently being viewed and shows one of Ready, Needs attention, or Blocked, the number of passing checks, and specific hints for missing information, with a "Refresh checks" button. - Project overview (
jira:projectPage, "EvidencePulse Overview") reviews a bounded sample of up to 25 most recently updated issues visible to the current user. It shows status counts, the most frequent documentation gaps, and a next action for each sampled issue. This is a sample, not a full project audit.
Both modules use the same six deterministic checks: meaningful summary; assigned owner; due date; acceptance criteria or definition of done; linked or attached evidence (or an evidence label); and no unresolved blocker. These checks measure visible issue metadata, not actual software quality or compliance. EvidencePulse does not claim to prove that a release is safe.
How we built it
Built on Atlassian Forge with Forge UI Kit, Node.js 24 runtime, and current-user requestJira bridge calls to the Jira Cloud REST API. The only permission scope is read:jira-work. A shared pure deterministic analyzer powers both modules and is covered by unit tests and mocked API tests. There is no storage, no third-party API calls, no LLM or Rovo, and the app never writes to Jira.
Testing in real Jira
We verified the app in a live Jira Cloud site: on a KAN issue the panel showed "Needs attention, 2 of 6 checks met" with the six checks listed (due date passed, blocker check passed, summary, owner, acceptance criteria and evidence flagged), and the project page showed a sample of 3 issues: 0 Ready, 3 Needs attention, 0 Blocked, with common gaps (acceptance criteria 3, evidence 3, owner 3, summary 2, due date 1) and a next action per issue. No errors were observed.
Challenges
Keeping the analysis explainable and honest: every hint maps to a visible field, the sample limit is stated explicitly in the UI, and the app stays read-only and permission-aware so it is simple to deploy and review.
What we learned
Forge makes it quick to ship a native, permission-aware experience; small deterministic checks are often more trustworthy than opaque scoring.
What's next
Configurable checks per project, more evidence sources, and a fuller project-level audit view.
Judge testing instructions
- Install EvidencePulse on a Jira Cloud site using the official Forge installation link provided to judges in the private submission fields, as a Jira site admin.
- Open a Jira issue and expand the EvidencePulse issue panel.
- On an issue with an assigned owner, due date, an "Acceptance Criteria:" section in the description, a non-empty summary, an evidence URL/attachment/
qa-verifiedlabel and no blocker, inspect the readiness summary. - Remove any of those fields and use "Refresh checks" to see an actionable missing-information hint. The app makes no changes to issues.
- Open a Jira project and select "EvidencePulse Overview" to inspect sample counts and common gaps.
- If an issue is marked Blocked or carries a blocker label, the app shows Blocked.
The source repository is private; installation is through the official Forge installation link provided to judges in the private submission fields (too long for the "Try it out" field, which allows 255 characters).
Judges can access the official Forge installation link and testing instructions through the private submission fields provided to the Codegeist organizers.
