Half your backlog is one-line tickets nobody has had time to think about yet.
What it does
- Drag a ticket into your "analyze" status → the AI posts a breakdown grounded in your actual repo
- Comment back to challenge or refine it → it answers in the same thread
- Transition it to your "build" status → it opens a pull request
- It listens to the whole Jira event stream — issues, comments, sprints, versions, worklogs — not just one board
What it does not do
It never transitions your tickets, merges PRs or closes issues. Status changes stay a human decision.
Honest note: this recipe is beta — built and smoke-tested, still waiting on live-fire use. Tell me what breaks.
Setup
clone → ./setup.sh → pick Jira → answer a few questions
~5 minutes. No server, no database, free.
Get it
The recipe is open source: github.com/akshaypatel-ai/ai-automations
This is one of 30+ automations in the series — the full write-up lives on my site.
Top comments (1)
Dug into the jira/project-agent README because the webhook auth line caught my eye: "Jira doesn't sign these, so authentication is the secret-in-URL pattern." Worth a second look. Jira Cloud webhooks, including the ones registered through Settings -> System -> WebHooks, do support an optional secret field, and when it's set Jira signs the payload with HMAC and sends it as an X-Hub-Signature header (WebSub-style, method=signature). That's in Atlassian's own webhooks doc under "Secure admin webhooks." So the secret doesn't have to live in the URL at all, it can be a server-side signing key you verify against the request body, same shape as a GitHub or Stripe webhook secret, which avoids it ever showing up in logs or a proxy's access log. Is the secret-in-URL choice here about something else, maybe simplicity on the relay side, or did the admin UI not expose that option when you built this?