tdg-personal/jira-integration
Use this skill when retrieving Jira tickets, analyzing requirements, updating ticket status, adding comments, or transitioning issues. Provides Jira API patterns via MCP or direct REST calls.
85
85%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong description that clearly identifies its domain (Jira), lists specific actions, and includes an explicit 'Use this skill when...' clause with natural trigger terms. The only minor note is that it uses second-person-adjacent phrasing ('Use this skill when') but this is standard trigger guidance rather than second-person voice, and the second sentence uses proper third person ('Provides Jira API patterns'). Overall, it is well-constructed and effective for skill selection.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: retrieving Jira tickets, analyzing requirements, updating ticket status, adding comments, transitioning issues. Also mentions implementation approach (MCP or direct REST calls). | 3 / 3 |
Completeness | Explicitly answers both 'what' (retrieving tickets, analyzing requirements, updating status, adding comments, transitioning issues via Jira API) and 'when' ('Use this skill when...' clause is present with clear triggers). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'Jira tickets', 'requirements', 'ticket status', 'comments', 'transitioning issues', 'Jira API', 'MCP', 'REST calls'. These cover common user language well. | 3 / 3 |
Distinctiveness Conflict Risk | Clearly scoped to Jira-specific operations with distinct triggers like 'Jira tickets', 'ticket status', 'Jira API', 'MCP'. Unlikely to conflict with other skills unless another Jira skill exists. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a comprehensive and actionable Jira integration skill with excellent executable examples for both MCP and REST API approaches. Its main weaknesses are verbosity — particularly the ticket analysis section and comment templates which contain general knowledge Claude already has — and the lack of verification steps after state-changing operations. Splitting into a concise overview with linked reference files would significantly improve token efficiency.
Suggestions
Remove or drastically condense the 'Analyzing a Ticket' section (test types, edge cases, structured output template) — this is general QA knowledge Claude already knows and doesn't need in a Jira integration skill.
Add verification steps after state-changing operations (e.g., after transitioning, re-fetch the issue to confirm the new status; after posting a comment, check the response code).
Split the REST API reference, comment templates, and ticket analysis sections into separate linked files to keep SKILL.md as a lean overview with progressive disclosure.
Trim comment templates to one example rather than four — Claude can adapt a single template pattern to different contexts.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably well-structured but includes unnecessary sections like 'Analyzing a Ticket' with extensive checklists (test types, edge cases, structured analysis output) that are general QA knowledge Claude already possesses. The comment templates and 'When to Update' table add bulk that could be trimmed. The security guidelines section also restates common sense practices. | 2 / 3 |
Actionability | The skill provides fully executable curl commands with proper authentication, jq formatting, and correct Jira REST API v3 syntax including the ADF format for comments. The MCP configuration is copy-paste ready with concrete JSON. The transition workflow correctly shows the two-step process of fetching transitions then executing. | 3 / 3 |
Workflow Clarity | The transition workflow correctly sequences 'get transitions first, then execute,' and the tip about calling jira_get_transitions is valuable. However, there are no validation/verification steps after API calls (e.g., confirming a transition succeeded, verifying a comment was posted). For operations that modify Jira state, feedback loops are missing. | 2 / 3 |
Progressive Disclosure | The content is well-organized with clear headers and tables, but it's monolithic — the 'Analyzing a Ticket' section, comment templates, and REST API reference could each be separate files linked from the main skill. At ~200+ lines, this would benefit from splitting into a quick-start overview with references to detailed sub-documents. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents