How to use a Righthand with Jira

Ask Jira a concrete planning question

Righthand can help prepare a Jira planning brief for a selected project: which issues need clearer ownership, missing acceptance details, or a date decision before the next planning meeting. Start with that question. A summary of all visible issues can hide the few items that actually require a decision.

Jira's issue reference describes issue retrieval and fields. Preserve both issue identity and the human-readable key when available. Custom fields need the project's actual mapping; their labels and meanings should not be inferred from another team's configuration.

Give the assistant the project conventions

Specify the project, approved filter or issue list, included statuses, and relevant field names. For an illustrative planning review, include Assignee, Status, Due date, and your own Acceptance criteria field. Tell the assistant whether subtasks are included and how blocked work is represented.

Inspect Jira's exposed reads in integrations. If the filter or necessary fields cannot be retrieved, use an approved issue export or browser review. A provider API can support transitions without proving those transitions are available or authorized in your Righthand connection.

A worked first-run request

At 2 PM America/Los_Angeles on Friday, review the approved planning filter for the named Jira project. Return a private brief with issue ID and key, source URL, current status, assignee, due date where present, and missing acceptance information under the supplied policy. Identify parent and subtask relationships when available. Do not transition issues, assign people, or change sprint scope. Send to me for product-owner review and reconcile the unique issue count and filter definition.

This example is illustrative. The report should identify missing evidence, not decide whether an engineering estimate or deadline is realistic without the team's input.

Define the output before the meeting

An example item could say: “PROJ-27; Ready for planning; acceptance field blank; linked subtask still open; product owner must clarify expected behavior.” Keep the exact recorded status and distinguish the proposed next step from an actual transition.

Issue comments can explain a field mismatch, but a comment is not necessarily the final decision. Show the source and ask the owner to resolve conflicts. Do not convert a tentative date mentioned in discussion into a committed due date.

Reconcile changes and authorization gaps

Match issue identities across repeat runs. An issue key can change after a move, so preserve the relationship to the original record when the source supplies it. Refresh the field mapping after configuration changes rather than guessing a replacement custom field.

Permission loss, filter changes, and incomplete pagination can alter the apparent queue. Report those limits. If the owner approves supported updates later, target the exact issues and fields or transitions, then retrieve their resulting state independently.

Use Righthand's responsibility guide to define the recurring planning preparation and reviewer. Check plans for the intended scope.