Mode: Cognitive/Prompt-Driven - No standalone utility script; use via agent context.
Required:
- JIRA_URL - Base URL of your Jira instance (e.g., https://yourcompany.atlassian.net)
- JIRA_API_TOKEN - API token for authentication (generate at Jira Account Settings -> Security -> API Tokens)
- JIRA_USER_EMAIL - Email address associated with the API token
Optional:
- JIRA_DEFAULT_PROJECT - Default project key for operations (e.g., PROJ)
- JIRA_API_VERSION - API version (default: 3)
Issues
| Tool |
Description |
Confirmation Required |
| search |
Search issues using JQL |
No |
| get-issue |
Get detailed issue information |
No |
| create-issue |
Create a new issue |
Yes |
| update-issue |
Update existing issue fields |
Yes |
| transition |
Change issue status/workflow state |
Yes |
Projects
| Tool |
Description |
| list-projects |
List all accessible projects |
| project-info |
Get detailed project information |
Sprints
| Tool |
Description |
| active-sprint |
Get currently active sprint for a board |
| sprint-issues |
List all issues in a specific sprint |
Comments
| Tool |
Description |
| get-comments |
Retrieve all comments on an issue |
| add-comment |
Add a comment to an issue |
Common Workflows
Issue Creation: List projects -> Get project info -> Create issue -> Add comment
Sprint Management: Get active sprint -> List sprint issues -> Update issue status -> Add comments
Issue Search: Use JQL for targeted searches -> Retrieve issue details -> Update issues
Primary Agent: planner
- Use Case: Project backlog management, sprint planning, requirement tracking
- Common Operations: Create issues, update priorities, manage sprints
Secondary Agent: developer
- Use Case: Issue tracking during development, status updates
- Common Operations: Search assigned issues, transition issues, add comments
Common Error Scenarios
- Authentication Errors: Missing or invalid API token, expired credentials, insufficient permissions
- Rate Limiting: Too many API requests in short period, implement exponential backoff
- Invalid Inputs: Non-existent project keys, invalid issue types, invalid transition IDs
- Network Errors: Connection timeouts, unreachable Jira instance
- Use JQL Efficiently: Craft precise JQL queries to reduce result sets and API calls
- Cache Metadata: Store project keys, issue types, and transitions locally
- Verify Before Create: Always verify project and issue type before creating issues
- Use Transitions: Respect workflow states when changing issue status
- Batch Operations: Group related API calls when possible
- Handle Errors Gracefully: Provide clear error messages and recovery suggestions
- Respect Rate Limits: Implement backoff strategies for high-volume operations
Context Optimization
- Lazy Loading: Only load issue details when explicitly requested
- Field Selection: Request only necessary fields from Jira API
- Caching: Store frequently accessed metadata (projects, issue types)
- Streaming: Not supported - all responses are complete payloads
- Pagination: Automatically handle large result sets
Context Savings: 90%+ compared to loading full Jira MCP server
Jira REST API Endpoints Used
- /rest/api/3/search - JQL search
- /rest/api/3/issue/{issueKey} - Get/update issue
- /rest/api/3/issue - Create issue
- /rest/api/3/issue/{issueKey}/transitions - Transition issue
- /rest/api/3/project - List projects
- /rest/api/3/project/{projectKey} - Get project details
- /rest/agile/1.0/board/{boardId}/sprint - Get sprints
- /rest/agile/1.0/sprint/{sprintId}/issue - Get sprint issues
- /rest/api/3/issue/{issueKey}/comment - Get/add comments
See https://developer.atlassian.com/cloud/jira/platform/rest/v3/ for full reference.
Iron Laws
- ALWAYS verify the project key exists before creating an issue — Jira silently ignores invalid project keys in some API versions, creating orphaned issues or returning cryptic errors.
- NEVER use
PUT /issue to change status — Jira status changes must go through valid workflow transitions via POST /issue/{key}/transitions; direct field updates bypass workflow validators and automation rules.
- ALWAYS use JQL for issue searches rather than fetching all issues and filtering client-side — returning all issues wastes quota and causes timeouts on projects with thousands of tickets.
- NEVER create duplicate issues without first searching for existing ones — duplicate tickets fragment tracking, confuse assignees, and produce misleading velocity metrics.
- ALWAYS include
summary, issuetype, and project fields when creating an issue — these three fields are the minimum required by Jira Cloud REST API v3; missing any produces a 400 error.
Anti-Patterns
| Anti-Pattern |
Why It Fails |
Correct Approach |
| Updating status via field PUT |
Bypasses workflow guards; invalid state transitions succeed silently; automation rules don't fire |
Use POST /issue/{key}/transitions with the correct transition ID |
| Fetching all issues and filtering locally |
Times out on large projects; wastes API quota; slow for paginated results |
Always use JQL with specific project/sprint/status filters |
| Creating issues without duplication check |
Splits work tracking; team sees multiple tickets for same task |
Search with JQL (project = X AND summary ~ "keyword") before creating |
Hardcoding field IDs (e.g., customfield_10016) |
Field IDs differ between Jira instances and cloud/server; breaks across projects |
Discover field IDs dynamically via /rest/api/3/field endpoint |
| No error handling for rate limits (429) |
Jira Cloud rate limits at ~300 requests/minute; unhandled 429 crashes automation |
Implement exponential backoff; check Retry-After header on 429 responses |
Memory Protocol (MANDATORY)
Before starting:
Read .claude/context/memory/learnings.md
After completing:
- New pattern -> .claude/context/memory/learnings.md
- Issue found -> .claude/context/memory/issues.md
- Decision made -> .claude/context/memory/decisions.md
ASSUME INTERRUPTION: If it is not in memory, it did not happen.
1---2name: jira-pm-23description: Jira project management and issue tracking integration4---5
6**Mode: Cognitive/Prompt-Driven** - No standalone utility script; use via agent context.
7
8<identity>
9Jira PM (Project Management) - Provides integration with Atlassian Jira for issue tracking, project management, and workflow automation. Enables 90%+ context savings over direct MCP integration.
10</identity>
11
12<capabilities>
13- Issue management: search, create, update, transition
14- Project discovery and metadata retrieval
15- Sprint management and issue tracking
16- Comment management on issues
17- JQL-based advanced queries
18</capabilities>
19
20<requirements>
21## Environment Variables
22
23Required:
24
25- JIRA_URL - Base URL of your Jira instance (e.g., https://yourcompany.atlassian.net)
26- JIRA_API_TOKEN - API token for authentication (generate at Jira Account Settings -> Security -> API Tokens)
27- JIRA_USER_EMAIL - Email address associated with the API token
28
29Optional:
30
31- JIRA_DEFAULT_PROJECT - Default project key for operations (e.g., PROJ)
32- JIRA_API_VERSION - API version (default: 3)
33 </requirements>
34
35<instructions>
36<execution_process>
371. Authentication: All requests use Basic Auth with JIRA_USER_EMAIL and JIRA_API_TOKEN
382. Progressive Disclosure: Load only necessary issue fields to minimize API calls
393. Validation: Verify project keys and issue keys before operations
404. Error Handling: Gracefully handle rate limits, authentication errors, and invalid inputs
41</execution_process>
42
43<tool_categories>
44
45## Issues
46
47| Tool | Description | Confirmation Required |
48| ------------ | ---------------------------------- | --------------------- |
49| search | Search issues using JQL | No |
50| get-issue | Get detailed issue information | No |
51| create-issue | Create a new issue | Yes |
52| update-issue | Update existing issue fields | Yes |
53| transition | Change issue status/workflow state | Yes |
54
55## Projects
56
57| Tool | Description |
58| ------------- | -------------------------------- |
59| list-projects | List all accessible projects |
60| project-info | Get detailed project information |
61
62## Sprints
63
64| Tool | Description |
65| ------------- | --------------------------------------- |
66| active-sprint | Get currently active sprint for a board |
67| sprint-issues | List all issues in a specific sprint |
68
69## Comments
70
71| Tool | Description |
72| ------------ | --------------------------------- |
73| get-comments | Retrieve all comments on an issue |
74| add-comment | Add a comment to an issue |
75
76</tool_categories>
77
78<usage_patterns>
79
80## Common Workflows
81
82**Issue Creation**: List projects -> Get project info -> Create issue -> Add comment
83
84**Sprint Management**: Get active sprint -> List sprint issues -> Update issue status -> Add comments
85
86**Issue Search**: Use JQL for targeted searches -> Retrieve issue details -> Update issues
87
88</usage_patterns>
89
90<agent_integration>
91
92## Primary Agent: planner
93
94- Use Case: Project backlog management, sprint planning, requirement tracking
95- Common Operations: Create issues, update priorities, manage sprints
96
97## Secondary Agent: developer
98
99- Use Case: Issue tracking during development, status updates
100- Common Operations: Search assigned issues, transition issues, add comments
101
102</agent_integration>
103
104<error_handling>
105
106## Common Error Scenarios
107
108- Authentication Errors: Missing or invalid API token, expired credentials, insufficient permissions
109- Rate Limiting: Too many API requests in short period, implement exponential backoff
110- Invalid Inputs: Non-existent project keys, invalid issue types, invalid transition IDs
111- Network Errors: Connection timeouts, unreachable Jira instance
112
113</error_handling>
114
115<best_practices>
116
1171. Use JQL Efficiently: Craft precise JQL queries to reduce result sets and API calls
1182. Cache Metadata: Store project keys, issue types, and transitions locally
1193. Verify Before Create: Always verify project and issue type before creating issues
1204. Use Transitions: Respect workflow states when changing issue status
1215. Batch Operations: Group related API calls when possible
1226. Handle Errors Gracefully: Provide clear error messages and recovery suggestions
1237. Respect Rate Limits: Implement backoff strategies for high-volume operations
124
125</best_practices>
126</instructions>
127
128<progressive_disclosure>
129
130## Context Optimization
131
1321. Lazy Loading: Only load issue details when explicitly requested
1332. Field Selection: Request only necessary fields from Jira API
1343. Caching: Store frequently accessed metadata (projects, issue types)
1354. Streaming: Not supported - all responses are complete payloads
1365. Pagination: Automatically handle large result sets
137
138Context Savings: 90%+ compared to loading full Jira MCP server
139</progressive_disclosure>
140
141<api_reference>
142
143## Jira REST API Endpoints Used
144
145- /rest/api/3/search - JQL search
146- /rest/api/3/issue/{issueKey} - Get/update issue
147- /rest/api/3/issue - Create issue
148- /rest/api/3/issue/{issueKey}/transitions - Transition issue
149- /rest/api/3/project - List projects
150- /rest/api/3/project/{projectKey} - Get project details
151- /rest/agile/1.0/board/{boardId}/sprint - Get sprints
152- /rest/agile/1.0/sprint/{sprintId}/issue - Get sprint issues
153- /rest/api/3/issue/{issueKey}/comment - Get/add comments
154
155See https://developer.atlassian.com/cloud/jira/platform/rest/v3/ for full reference.
156</api_reference>
157
158## Iron Laws
159
1601. **ALWAYS** verify the project key exists before creating an issue — Jira silently ignores invalid project keys in some API versions, creating orphaned issues or returning cryptic errors.
1612. **NEVER** use `PUT /issue` to change status — Jira status changes must go through valid workflow transitions via `POST /issue/{key}/transitions`; direct field updates bypass workflow validators and automation rules.
1623. **ALWAYS** use JQL for issue searches rather than fetching all issues and filtering client-side — returning all issues wastes quota and causes timeouts on projects with thousands of tickets.
1634. **NEVER** create duplicate issues without first searching for existing ones — duplicate tickets fragment tracking, confuse assignees, and produce misleading velocity metrics.
1645. **ALWAYS** include `summary`, `issuetype`, and `project` fields when creating an issue — these three fields are the minimum required by Jira Cloud REST API v3; missing any produces a 400 error.
165
166## Anti-Patterns
167
168| Anti-Pattern | Why It Fails | Correct Approach |
169| ------------------------------------------------ | ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
170| Updating status via field PUT | Bypasses workflow guards; invalid state transitions succeed silently; automation rules don't fire | Use `POST /issue/{key}/transitions` with the correct transition ID |
171| Fetching all issues and filtering locally | Times out on large projects; wastes API quota; slow for paginated results | Always use JQL with specific project/sprint/status filters |
172| Creating issues without duplication check | Splits work tracking; team sees multiple tickets for same task | Search with JQL (`project = X AND summary ~ "keyword"`) before creating |
173| Hardcoding field IDs (e.g., `customfield_10016`) | Field IDs differ between Jira instances and cloud/server; breaks across projects | Discover field IDs dynamically via `/rest/api/3/field` endpoint |
174| No error handling for rate limits (429) | Jira Cloud rate limits at ~300 requests/minute; unhandled 429 crashes automation | Implement exponential backoff; check `Retry-After` header on 429 responses |
175
176## Memory Protocol (MANDATORY)
177
178**Before starting:**
179Read .claude/context/memory/learnings.md
180
181**After completing:**
182
183- New pattern -> .claude/context/memory/learnings.md
184- Issue found -> .claude/context/memory/issues.md
185- Decision made -> .claude/context/memory/decisions.md
186
187> ASSUME INTERRUPTION: If it is not in memory, it did not happen.