Using OpenClaw to Manage Jira Tickets and Sprint Planning from Chat

Jira is the place our backlogs live, but it rarely feels conversational. The search query you landed here with—how to use OpenClaw to manage Jira tickets and sprint planning—boils down to one goal: stop alt-tabbing and let an agent push/pull Jira data while you stay in Slack, Discord, or WhatsApp. The good news: OpenClaw’s Jira skill has matured enough that a single prompt like “what’s blocking the sprint?” actually returns a sensible answer. Below is the setup, the commands I use daily, and the rough edges I hit.

Prerequisites and Quick Checklist

You need a few moving parts before anything works. Skip what you already have.

Node.js 22.2+ (OpenClaw currently pins to 22.x; node --version should print at least v22.0.0)
OpenClaw 1.9.3 or newer (npm i -g openclaw or a ClawCloud workspace)
Jira Cloud account (server/DC works too, but the guide uses Cloud REST endpoints)
Jira API token linked to a user with create/edit rights
An OAuth 2.0 app in Atlassian if you need user-level scopes (optional, covered later)
One chat connector (Slack, Discord, Telegram, etc.) already working in OpenClaw

Once those boxes are ticked, the agent can log in to Jira and start manipulating issues the same way you do in the web UI—except without the clicks.

Installing and Configuring the Jira Skill

1. Grab the skill package

The Jira integration lives in @openclaw/skill-jira. It’s versioned separately from the core so you can upgrade skills without bumping the daemon.


# in your agent directory
npm install @openclaw/skill-jira@2.1.0 --save

2. Add the skill to `claw.config.yml`

OpenClaw uses a plain-English YAML file to declare capabilities. Mine looks like this:


skills:
  - name: jira
    package: "@openclaw/skill-jira"
    config:
      baseUrl: "https://acme-dev.atlassian.net"
      email: "bot@acme.dev"
      apiToken: "${JIRA_API_TOKEN}"
      projectKey: "ACME"
      defaultIssueType: "Task"

You can also wire environment variables instead of hard-coding the token. The skill respects JIRA_BASE_URL, JIRA_EMAIL, and JIRA_API_TOKEN if present.

3. Restart or redeploy

If you’re on ClawCloud, hit Restart Agent. Self-hosted users do:


openclaw daemon restart

The gateway should now list jira under Active Skills.

Creating and Updating Jira Tickets from Chat

The default prompt syntax uses natural language. The skill parses intent, then calls the REST API. Here are real examples from our Slack channel.

Create a new task


me — “/claw create jira ticket: investigate 502 errors in payment-flow, assign to @jeff, due next Tuesday”
claw — ✅ ACME-321 created; assignee Jeff, due 2024-06-11

Internally, the agent maps “task” -> “defaultIssueType” unless you specify otherwise:


me — “/claw create jira story: user can reset 2FA device”
claw — ✅ ACME-322 (Story) added to backlog

Bulk updates

Wildcards and JQL snippets are both supported:


me — “/claw close all jira issues in sprint ‘Sprint 24.5’ with status ‘Code Review’”
claw — 7 issues transitioned → Done

For single updates, you can rely on short-hand:


me — “/claw move ACME-312 to ‘In QA’ and add label hotfix”
claw — ✅ ACME-312 now In QA, label set

Under the hood

The skill runs a schema-supported LLM function call, so the agent only invokes endpoints that match a defined JSON schema. No rogue network surprises.
Rate limits: The Jira Cloud REST API is 500 requests/10 minutes per user. The skill batches transitions automatically; you can override via batchSize in config.
Audit log: Every mutation shows up in the gateway’s timeline view with diff-style headers (added in OpenClaw 1.9.0).

Sprint Planning Workflows: From Backlog Grooming to Commit Scope

Sprint planning isn’t just “move tickets into a bucket.” The agent can triage the backlog based on criteria you define: story points, labels, component ownership, even GitHub pull request state if you have the GitHub skill installed.

1. Prepare the backlog


me — “/claw backlog triage: find unestimated stories labeled mobile and assign senior devs”

The skill collects issues matching project = ACME AND sprint is EMPTY AND labels = mobile AND storyPoints is EMPTY, then uses the People API (if you enabled it) to round-robin assign among users with role=Senior.

2. Generate a sprint scope proposal


me — “/claw propose sprint target 40 story points ending 2024-06-21”
claw — Proposed Sprint 24.6: 8 issues totaling 39 SP, breakdown: Backend 21, Frontend 13, Infra 5. Accept? (yes/no)

Say yes and the agent handles /rest/agile/1.0/sprint creation plus /sprint/{id}/issue bulk moves. It also posts the issue list to the planning channel so the team can review.

3. Commit the sprint

This is the least exciting part but also the least error-prone when automated:


me — “/claw start sprint”
claw — Sprint 24.6 started; end date 2024-06-21, 8 issues mapped.

4. Mid-sprint adjustments

If your burndown turns red, the agent can re-scope:


me — “/claw pull ACME-330 out of active sprint and move to backlog”
claw — ✅ ACME-330 removed from Sprint 24.6, status To Do

Status Reports and Blocker Analysis with a Single Prompt

This is where I stopped thinking of the integration as a toy. By default, the skill syncs Jira status + comments every 15 minutes (configurable). That gives the agent enough context to answer questions you’d normally dig for in Jira dashboards.

Daily stand-up in under 10 seconds


me — “/claw standup summary for sprint 24.6”
claw —
  🟢 Done: 3 issues (12 SP)
  🟡 In Progress: 4 (19 SP)
  🔴 Blocked: 1 — ACME-327 waiting on DB schema migration PR-742
  Burn-down trend: on track (47% complete, 46% time elapsed)

The agent cross-references Jira with GitHub PR status when both skills are active. If a ticket is blocked by an open pull request, it calls it out. No extra config required—just the default linking that Jira already stores.

Asking "what’s blocking the sprint?"


me — “/claw what's blocking the sprint?”
claw —
  1. ACME-327: waiting on reviews (2/3 approvals) — assigned to @alex
  2. ACME-331: flaky Cypress tests failing > 30% — component Frontend
  3. ACME-329: Jira dependency on INFRA-88 (not in sprint) — consider pulling in or splitting

The response is generated by a toolchain:

Fetch JQL: sprint in openSprints() AND statusCategory != Done
Enrich each issue with linked pull requests, test reports (if TestRail skill present), and deployment status (if Shipyard skill present)
Classify blockers vs. risks using a GPT-4o function (prompts live in prompt/blockerAnalysis.json)
Render a plaintext list with severity, owner, and next action

Because the processing chain is explicit, you can audit every step in the timeline view. Nothing magic, just a lot of API stitching you no longer have to do by hand.

Automatic end-of-sprint report

Add a scheduled task so you never write the Friday wrap-up again:


cron:
  - schedule: "0 16 * * FRI"
    task: jira.sprintReport
    args:
      includeVelocity: true
      postToChannel: "#sprint-reports"

The resulting message includes velocity delta vs. last three sprints and rolls up carry-over stories. It’s saved me ~30 minutes every week.

Deep-Dive: Handling Authentication Edge Cases

Two headaches surfaced when teammates with different Jira permission levels ran commands.

1. User context vs. service account

By default, the skill executes with the credentials you put in claw.config.yml. That’s fine for service-account style automation but misleading if you care about reporter/assignee fields reflecting who asked the agent.

Set impersonateByEmail: true in skill config to make the agent re-sign requests with each user’s API token (stored per-connector). Yes, that means everybody needs a token.
Alternatively, create an OAuth 2.0 integration in Atlassian and list its clientId/clientSecret under oauth in config. The agent then runs an OAuth dance in-chat and stores refresh tokens in its encrypted vault (AES-256, keyed with your workspace secret).

2. Custom workflows

If you renamed “In Progress” to “Coding” in Jira, status transitions will 404. Map them explicitly:


statusMap:
  todo: "To Do"
  inProgress: "Coding"
  inQa: "QA Review"
  done: "Done"

Save and restart. The agent now calls the friendly names.

Putting It All Together: A Week with the Dream Workflow

I ran a full five-day sprint using only Slack + OpenClaw for Jira work. This is what the log looked like:

Monday 09:15 – planning

Prompt: “/claw propose sprint target 30 SP, end Friday, include only label api”
Agent created Sprint 24.7, assigned six tasks, pinged owners.

Tuesday 11:40 – mid-morning adjustment

Prompt: “/claw add ACME-345 to active sprint and assign @lee”
Agent moved issue, bumped sprint SP to 33.

Wednesday 17:55 – blocker alert

Prompt: “/claw what's blocking the sprint?”
Agent flagged a failing staging deploy; we hotfixed before midnight.

Friday 15:00 – retrospective numbers

Cron-triggered jira.sprintReport posted burndown chart, velocity trend, carry-over list (1 ticket).

I opened Jira web UI exactly twice: once to adjust a component field the skill doesn’t expose yet, and once to copy a dashboard screenshot. Everything else flowed through chat.

Next step: if you already have an OpenClaw agent running, npm install @openclaw/skill-jira, paste the config, and try “/claw what's blocking the sprint?” in your own backlog. The first answer will tell you whether the wiring works—and whether your sprint does too.