Jira Metric
ReviewAudited by ClawScan on May 10, 2026.
Overview
This looks like a real Jira helper, but it uses a Jira API token and includes commands that can change Jira issues and worklogs beyond the metric-only description.
Install only if you want the agent to have Jira account access that may include both reading metrics and changing issues or worklogs. Use a least-privilege Jira token, set JIRA_BOARD to specific projects, and require manual approval before running status, assign, comment, create, or log commands.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
An agent could be given the ability to change Jira records when the user expected only worklog reporting.
The supplied registry description is metric retrieval, but the skill instructions disclose broader Jira management and write capabilities. This under-description could lead a user to install it expecting read-only analytics.
description: Manage Jira issues, transitions, and worklogs via the Jira Cloud REST API ... status ABC-123 ... assign ABC-123 ... comment ABC-123 ... create "Title" ... log ABC-123
Update the public description and capability metadata to clearly state Jira write access, or split the skill into a read-only metrics skill and a separate issue-management skill.
The agent could change issue status, assignments, comments, created issues, or time logs in Jira, affecting team workflows or reporting.
The helper script implements Jira write operations for transitions, assignees, and worklogs. The artifacts do not show an explicit user-confirmation gate before these business-impacting changes.
resp=$(api POST "/rest/api/3/issue/${issue}/transitions" ...)
resp=$(api PUT "/rest/api/3/issue/${issue}/assignee" ...)
resp=$(api POST "/rest/api/3/issue/${issue}/worklog" ...)Require explicit user confirmation for all write actions, make read-only reporting the default, and add dry-run or preview output before applying Jira mutations.
The agent may act under the user's Jira identity and access or modify more Jira data than the user realizes.
The skill requires a Jira API token and allows an empty project scope to search all accessible Jira data, while the registry metadata declares no required env vars or primary credential.
export JIRA_EMAIL="you@example.com" export JIRA_API_TOKEN="your-api-token" export JIRA_URL="https://your-domain.atlassian.net" # Optional project scope (comma-separated). Empty = search all.
Declare the Jira credential requirement in metadata, use least-privilege credentials where possible, set JIRA_BOARD to an explicit project list, and separate read-only from write-capable credentials.
Users may not see the credential and tool requirements before installing or enabling the skill.
The registry metadata under-declares prerequisites that SKILL.md lists, including local binaries and Jira credential environment variables. No remote install or hidden dependency is shown, but the packaging metadata is incomplete.
Required binaries (all must exist): none ... Required env vars: none ... No install spec — this is an instruction-only skill.
Align registry metadata with SKILL.md by declaring required binaries, required environment variables, and credential expectations.
