Help us improve
Share bugs, ideas, or general feedback.
Reviews JIRA admin SKILL.md documentation for CLI command syntax accuracy, optional parameters, shorthand flags, filters, and discoverability by comparing against actual --help outputs across 8 admin categories.
npx claudepluginhub grandcamel/jira-assistant-skills --plugin jira-assistant-skillsHow this agent operates — its isolation, permissions, and tool access model
Agent reference
jira-assistant-skills:agents/reviewers/findings/jira-admin-reviewThe summary Claude sees when deciding whether to delegate to this agent
**Date:** 2026-01-31 **Reviewer:** Claude Code **Skill:** jira-admin (SKILL.md) **Target:** `jira-as admin` CLI commands --- The jira-admin SKILL.md documentation is well-structured with comprehensive coverage of 8 major administration areas. However, there are **5 significant findings** that affect command usability: - **3 HIGH severity** issues affecting command syntax clarity - **2 MEDIUM se...
Reviews jira-admin SKILL.md documentation against jira-as admin CLI to identify discrepancies in commands, options, syntax, and examples. Outputs JSON findings. Use for doc validation or post-CLI updates.
Expert Java code reviewer for Spring Boot and Quarkus projects. Automatically detects the framework and applies appropriate review rules. Covers layered architecture, JPA/Panache, MongoDB, security, and concurrency.
Share bugs, ideas, or general feedback.
Date: 2026-01-31
Reviewer: Claude Code
Skill: jira-admin (SKILL.md)
Target: jira-as admin CLI commands
The jira-admin SKILL.md documentation is well-structured with comprehensive coverage of 8 major administration areas. However, there are 5 significant findings that affect command usability:
The documentation covers all major command categories but lacks precision in:
jira-as admin --help and 20+ subcommand helps to capture actual syntax| Category | Subcommands Tested |
|---|---|
| Project Management | list, get, create, update, delete, archive, restore |
| Configuration | config get |
| Categories | list, create, assign |
| Automation | list, get, search, enable, disable, toggle, invoke, automation-template |
| Permissions | permission-scheme (list, get, create, assign), permission (list, check) |
| Users & Groups | user (search, get), group (list, members, create, delete, add-user, remove-user) |
| Notifications | notification-scheme (list, get, create), notification (add, remove) |
| Screens | screen (list, get, tabs, fields, add-field, remove-field), screen-scheme (list, get) |
| Issue Types | issue-type (list, get, create, update, delete), issue-type-scheme (list, get, create, assign, project) |
| Workflows | workflow (list, get, search, for-issue), workflow-scheme (list, get, assign), status (list) |
Location: Line 158, Available Commands section
Documented:
jira-as admin automation list --project PROJ # List automation rules
Actual CLI:
jira-as admin automation list [OPTIONS]
Options:
-p, --project TEXT - optional filter-s, --state [enabled|disabled] - optional filter--all - optional flag for all pages-o, --output [text|json] - optional output formatIssue: The documentation shows --project PROJ as if it's required, but it's actually optional. Users expecting to list ALL automation rules without filtering won't know they can omit --project.
Impact: Moderate - users may be confused about the command's flexibility
Recommendation:
jira-as admin automation listjira-as admin automation list # All rules
jira-as admin automation list --project PROJ # Rules for specific project
jira-as admin automation list --state enabled # Enabled rules only
Location: Line 181, Permission Diagnostics section
Documented:
jira-as admin permission check --project DEMO
Actual CLI:
jira-as admin permission check [OPTIONS]
Required Options:
-p, --project TEXT - required, not shown clearly as suchIssue: The documented example is correct, but the documentation doesn't clearly indicate that --project is REQUIRED. Users might attempt to run the command without the project parameter and receive an error.
Impact: Moderate - users may misunderstand the command's requirements
Additional Issue: Troubleshooting section (lines 327, 338) shows inconsistent presentation of the same command without emphasizing the required parameter.
Recommendation:
-p/--project is requiredjira-as admin permission check --project DEMO # Check permissions on a project (--project required)
Location: Line 191, User & Group Management section
Documented:
jira-as admin group delete GROUP_NAME --confirm
Actual CLI:
jira-as admin group delete GROUP_NAME [OPTIONS]
Available Options:
-y, --confirm - shorthand available as -y--dry-run - preview deletion without executing-o, --output [text|json] - output formatIssue: The documentation omits:
-y flag (equivalent to --confirm)--dry-run flag for safe preview before deletionGiven the DANGER risk level noted in the skill (line 41: "Delete group - !!! - Members lose group access"), the omission of --dry-run is particularly significant.
Impact: High - users may not know they can preview deletions before executing
Recommendation:
jira-as admin group delete GROUP_NAME --confirm # or -y
jira-as admin group delete GROUP_NAME --dry-run # Preview deletion
jira-as admin group delete GROUP_NAME --confirm # Execute deletion
Location: Line 193, User & Group Management section
Documented:
jira-as admin group remove-user GROUP_NAME --user EMAIL --confirm
Actual CLI:
jira-as admin group remove-user GROUP_NAME [OPTIONS]
Available Options:
-u, --user TEXT - shorthand available as -u, accepts account ID OR email-y, --confirm - shorthand available as -y-o, --output [text|json] - output formatIssue: The documentation:
-u flag option-y as shorthand for --confirmImpact: Medium - users may not discover shorthand options or may try email when account ID is required
Recommendation:
jira-as admin group remove-user GROUP_NAME --user ACCOUNT_ID_OR_EMAIL --confirm
jira-as admin group remove-user GROUP_NAME -u EMAIL -yLocation: Lines 186, 261, User & Group Management section
Documented:
jira-as admin user search "name" # Search for users by name or email
jira-as admin user search "your.name" --include-groups # From line 261
Actual CLI:
jira-as admin user search QUERY [OPTIONS]
Available Options:
-g, --include-groups - include group memberships (shown in example at line 261)-p, --project TEXT - filter by assignable to project-a, --assignable - search only assignable users (requires --project)--all - include inactive users--max-results INTEGER - limit results-o, --output [text|json] - output formatIssue: The main command reference (line 186) doesn't document available filter options. Line 261 includes one example with --include-groups, which is good, but other powerful filters are not mentioned:
--assignable for finding assignable users in a project--all for including inactive users--max-results for paginationImpact: Medium - users won't discover filtering capabilities that could optimize searches
Recommendation:
jira-as admin user search "name" # Search by name/email
jira-as admin user search "name" --include-groups # Show group membership
jira-as admin user search "name" --project PROJ --assignable # Find assignable users
jira-as admin user search "name" --all # Include inactive users
The SKILL.md demonstrates excellent practices in several areas:
| Strength | Location | Example |
|---|---|---|
| Risk level clarity | Lines 18-41 | Clear matrix of operation risks |
| Comprehensive coverage | Lines 51-62 | 8 major admin areas documented |
| Troubleshooting guide | Lines 322-346 | Addresses common permission issues |
| Common patterns section | Lines 274-291 | Shows dry-run and JSON output |
| Permission requirements | Lines 295-307 | Clear permission matrix |
| Best practices reference | Lines 397-410 | Links to detailed guides |
| Related skills integration | Lines 381-393 | Shows workflow between skills |
Areas where documentation could be enhanced:
| Weakness | Impact | Location |
|---|---|---|
| Optional parameters not marked | Medium | Throughout "Available Commands" |
| Shorthand flags not documented | Low | User/Group operations |
| Filter options incomplete | Medium | User search, automation list |
| --dry-run capability underexposed | High | Deletion operations |
| Inconsistent parameter naming | Low | Examples (PROJ vs PROJECT_KEY) |
| automation search vs list distinction unclear | Low | Automation Rules section |
The documentation follows the project's patterns well:
✓ Skills - Uses third-person description for triggering ✓ Component Conventions - Body in imperative form directed at Claude ✓ Risk Assessment - Comprehensive risk levels defined ✓ Error Handling - Common errors section included ✓ Related Skills - Integration with other skills documented
Areas for improvement:
--project is optional for automation list--project is required for permission check--dry-run capability for group delete--user accepts both account ID and email| Finding | Severity | Recommendation | Effort |
|---|---|---|---|
| automation list option clarity | HIGH | Rewrite line 158 with examples | Low |
| permission check requirement clarity | HIGH | Add note emphasizing required --project | Low |
| group delete --dry-run omission | HIGH | Add to Common Patterns section | Low |
| group remove-user parameter clarity | MEDIUM | Update parameter description | Low |
| user search filters undocumented | MEDIUM | Expand with filter examples | Medium |
Total effort: Low to Medium. Most findings can be addressed with documentation clarifications rather than code changes.
/Users/jasonkrueger/IdeaProjects/Jira-Assistant-Skills/skills/jira-admin/SKILL.mdjira-as admin [subcommand] --help on 2026-01-31