Administer Jira projects. Use when creating/archiving projects, managing components, versions, roles, permissions, or project configuration.
76
71%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./data/skills-md/01000001-01001110/agent-jira-skills/jira-project-management/SKILL.mdQuality
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, well-crafted skill description. It concisely identifies the domain (Jira project administration), lists specific capabilities, and includes an explicit 'Use when' clause with natural trigger terms. The description is appropriately scoped to avoid conflicts with related but distinct skills like Jira issue tracking.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: creating/archiving projects, managing components, versions, roles, permissions, and project configuration. These are distinct, actionable capabilities. | 3 / 3 |
Completeness | Clearly answers both 'what' (administer Jira projects with specific sub-tasks listed) and 'when' (explicit 'Use when' clause with trigger scenarios like creating/archiving projects, managing components, versions, roles, permissions, or project configuration). | 3 / 3 |
Trigger Term Quality | Includes natural keywords users would say: 'Jira', 'projects', 'components', 'versions', 'roles', 'permissions', 'project configuration', 'creating', 'archiving'. These cover the domain well and match how users naturally describe Jira administration tasks. | 3 / 3 |
Distinctiveness Conflict Risk | Clearly scoped to Jira project administration specifically, which is a distinct niche. The mention of Jira-specific concepts like components, versions, roles, and permissions makes it unlikely to conflict with other skills. It's distinguishable from general Jira issue management or other project management tools. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is essentially a complete API reference manual inlined into a single file, which is highly actionable but extremely verbose and poorly structured for token efficiency. It provides concrete, executable code for every operation but fails to respect Claude's existing knowledge of REST patterns and TypeScript, and desperately needs content split across multiple files with a concise overview in the main SKILL.md.
Suggestions
Reduce the main SKILL.md to a concise overview with the API endpoints summary table and common patterns, moving detailed TypeScript implementations and curl examples into separate referenced files (e.g., COMPONENTS.md, VERSIONS.md, ROLES.md).
Remove TypeScript interface definitions entirely — Claude can infer these from the function signatures and API responses. At minimum, consolidate them into a single TYPES.md reference file.
Eliminate the curl examples section since it duplicates information already present in the TypeScript functions; keep only one representation per operation.
Add explicit validation/verification steps for destructive operations (delete project, delete component, delete version) — e.g., check issue counts before deleting a component, verify unresolved issues before releasing a version.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~600+ lines. The full TypeScript type definitions, every CRUD function signature, curl examples duplicating the same information, AND an API endpoint summary table create massive redundancy. Claude already knows how to construct REST API calls and TypeScript interfaces — this reads like auto-generated API documentation rather than a skill. | 1 / 3 |
Actionability | The code is fully executable TypeScript with complete function signatures, concrete curl examples with real payloads, and specific API paths. Every operation is copy-paste ready with proper HTTP methods, headers, and request bodies. | 3 / 3 |
Workflow Clarity | Steps are numbered (Step 1-9) but there's no validation/verification workflow for destructive operations like deleteProject or deleteComponent. The 'setupProject' helper shows a multi-step sequence but lacks error handling or rollback guidance. Delete operations mention enableUndo but don't enforce a validate-before-proceed pattern. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of content with everything inlined. The type definitions, all CRUD operations for 5+ resource types, curl examples, endpoint tables, and reference tables could easily be split into separate files (e.g., COMPONENTS.md, VERSIONS.md, ROLES.md). The References section links externally but no internal progressive disclosure exists. | 1 / 3 |
Total | 7 / 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 |
|---|---|---|
skill_md_line_count | SKILL.md is long (834 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
e437c3c
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.