| name | jira |
| description | How to use the Jira connector's tools โ searching issues with JQL, reading and creating issues, editing fields, transitioning status, assigning, and commenting. Use when the user works with Jira, issues, tickets, bugs, stories, epics, sprints, boards, backlogs, or project tracking. |
You are using the Jira connector (via Composio). Its tools act on the connected
Jira site (projects, issues, boards). Apply this guidance whenever you touch Jira.
Find the target first
- To act on an issue you reference it by issue key (e.g.
PROJ-123) or numeric
id. Resolve a human description ("the login bug") into a key by searching
first โ don't guess keys.
- Search uses JQL, not plain keywords. Build a query:
project = PROJ,
status = "In Progress", assignee = currentUser(), text ~ "login", with
ORDER BY created DESC. Combine clauses (project = PROJ AND status != Done ORDER BY updated DESC) instead of fetching broadly and filtering yourself.
- Prefer the POST JQL search tool for anything non-trivial โ it carries the
query in the body and handles complex/long JQL more reliably than the simpler
search variant.
- Reading an issue returns its summary, description, status, assignee, comments,
and custom fields; pass a
fields list to keep responses small on large issues.
Creating and editing
- Creating an issue requires at minimum a project key, an issue type, and a
summary. Don't assume the type exists โ list a project's issue types first if
unsure (a
Bug/Story/Task that isn't configured for that project will error).
- Edit an existing issue rather than recreating it. Editing sets fields
(summary, description, priority, labels) in place.
Status transitions are not free-text
- You cannot set an issue's status by name directly. Status changes go through a
workflow transition: first get the available transitions for that specific
issue, pick the one you want, then transition the issue with that
transition id. The valid transitions depend on the issue's current status and
the project's workflow, so always fetch them per-issue rather than caching ids.
Users are accountIds, not usernames
- Assigning and user lookups use Atlassian accountId, not username or email
(Jira's privacy changes removed username access). To assign by a person's name,
find the user first to get their accountId, then assign with it. Setting the
assignee to null/unassigned is the way to clear an assignee.
Comments and context
- Add comments to record decisions or hand off context; comments are visible to
everyone with project access. Don't paste large dumps โ link or summarize.
- Boards and sprints are agile concepts layered on projects: list boards to find a
board id, then list its sprints. Issues live in projects; sprint membership is a
board-level view.
Care
- Deleting an issue is permanent and irreversible โ there is no trash. Never
delete without explicit, specific confirmation; default to closing/transitioning
to a "Done" or "Won't Do" status instead.
- Transitions, edits, assignments, and comments are immediately visible to the team
and can fire notifications and automations. Confirm the target issue key before
writing; prefer commenting/transitioning over destructive edits.
- If an issue or project "isn't found," it may simply be outside the connector's
permissions rather than missing โ say so instead of inventing it.
- Large result sets: page through search results and summarize rather than pulling
every issue at once.
