Agent skill

Status Analysis

by openshift-eng in openshift-eng/ai-helpers

Shared engine for analyzing Jira issue activity and generating status summaries

Apache-2.0Auto-check passed

Install Status Analysis

skills CLI
$ npx skills add openshift-eng/ai-helpers --skill status-analysis -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install openshift-eng/ai-helpers status-analysis --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/openshift-eng/ai-helpers.git skills-src && mkdir -p .claude/skills && cp -r skills-src/plugins/jira/skills/status-analysis .claude/skills/status-analysis && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
status-analysis
GitHub stars
120
Token cost
~4.2k tokens
SKILL.md length
1,038 words
Files
9 (incl. scripts)
Skills in repo
118
Repo updated
First seen
Licence
Apache-2.0

At a glance

Shared engine for analyzing Jira issue activity and generating status summaries

  • Works in 6 steps: Initialize Configuration → Data Collection → Activity Analysis → …
  • SKILL.md covers When to Use This Skill, Architecture Overview, Sub-Modules and Configuration Parameters, plus 7 more sections
  • Runs Python scripts from its folder; calls gh, python3 and glab; reaches issues.redhat.com and github.com; needs JIRA_API_TOKEN and GITHUB_TOKEN

What it does

Status Analysis is an agent skill from openshift-eng/ai-helpers. Shared engine for analyzing Jira issue activity and generating status summaries

Its SKILL.md is about 4.2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 9 other files, including scripts (for example `activity-analysis.md`, `data-collection.md` and `external-links.md`).

It works with Jira. The repository describes itself as: Developer productivity tools for Claude Code & other AI assistants. The licence is Apache-2.0.

Example prompts

  • “/status-analysis”

Requirements

  • Python 3

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Initialize Configuration
  2. Data Collection
  3. Activity Analysis
  4. External Links (if enabled)
  5. Format Output
  6. Return to Calling Command

What it can do on your machine

Read from SKILL.md and the folder at commit a627176. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 4 files in scripts/ (Python), which the agent can run.

    Shell commands in SKILL.md call:

    • gh
    • python3
    • glab

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • issues.redhat.com
    • github.com

    Also links to:

    • id.atlassian.com

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • JIRA_API_TOKEN
    • GITHUB_TOKEN

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Status Analysis loads about 4.2k tokens when it runs. Until then it costs about 24 tokens; SKILL.md has 1,038 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~24
When it runs · the whole SKILL.md, loaded when a task matches
~4.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from openshift-eng/ai-helpers at commit a627176, republished under its Apache-2.0 licence (© openshift-eng). 1,038 words, ~4,240 tokens.

Download SKILL.mdSave it as .claude/skills/status-analysis/SKILL.md (or your agent's skills folder). This skill also uses 8 other files; get the full folder from GitHub.
name
status-analysis
description
Shared engine for analyzing Jira issue activity and generating status summaries

Jira Status Analysis Engine

This skill provides the core analysis logic shared by status-related commands (/jira:status-rollup, /jira:update-weekly-status, and /jira:generate-feature-updates). It handles data collection, activity analysis, and status generation in a unified way.

IMPORTANT FOR AI: This is a procedural skill - when invoked by a command, you should execute the implementation steps defined in this document and its sub-modules. The calling command determines the configuration parameters.

When to Use This Skill

This skill is invoked automatically by:

  • /jira:status-rollup - Single root issue, outputs as Jira comment
  • /jira:update-weekly-status - Multiple root issues (batch), outputs to Status Summary field
  • /jira:generate-feature-updates - Multiple root issues (batch), outputs as markdown to stdout

Do NOT invoke this skill directly. Use the commands above.

Architecture Overview

For update-weekly-status (Pre-Gathered Data)
┌─────────────────────────────────────────────────────────────────┐
│                  /jira:update-weekly-status                     │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                    Python Data Gatherer                         │
│                  (gather_status_data.py)                        │
│                                                                 │
│  • Async HTTP requests (aiohttp)                                │
│  • Jira: issues, descendants, changelogs                        │
│  • GitHub: PRs via GraphQL (batched)                            │
│  • Output: .work/weekly-status/{date}/issues/*.json             │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                    Status Analysis Engine                       │
│  ┌───────────────┐  ┌──────────────────┐  ┌──────────────────┐  │
│  │ Read JSON     │  │ Activity         │  │ PR Activity      │  │
│  │ (pre-gathered)│─▶│ Analysis         │─▶│ (pre-gathered)   │  │
│  └───────────────┘  └──────────────────┘  └──────────────────┘  │
│                              │                                  │
│                              ▼                                  │
│                    ┌──────────────────┐                         │
│                    │ Formatting       │                         │
│                    │ (formatting.md)  │                         │
│                    └──────────────────┘                         │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                Status Summary field (R/Y/G template)            │
└─────────────────────────────────────────────────────────────────┘
For status-rollup (Direct MCP Calls)
┌─────────────────────────────────────────────────────────────────┐
│                      /jira:status-rollup                        │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                    Status Analysis Engine                       │
│                         (SKILL.md)                              │
│  ┌───────────────┐  ┌──────────────────┐  ┌──────────────────┐  │
│  │ Data          │  │ Activity         │  │ External         │  │
│  │ Collection    │─▶│ Analysis         │─▶│ Links            │  │
│  │ (data-        │  │ (activity-       │  │ (external-       │  │
│  │ collection.md)│  │ analysis.md)     │  │ links.md)        │  │
│  └───────────────┘  └──────────────────┘  └──────────────────┘  │
│                              │                                  │
│                              ▼                                  │
│                    ┌──────────────────┐                         │
│                    │ Formatting       │                         │
│                    │ (formatting.md)  │                         │
│                    └──────────────────┘                         │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                   Jira comment (markdown)                       │
└─────────────────────────────────────────────────────────────────┘

Sub-Modules

Read the modules listed below when executing the analysis:

ModuleFilePurpose
Data Collectiondata-collection.mdReading pre-gathered JSON or fetching via MCP
Activity Analysisactivity-analysis.mdDetecting blockers, progress, risks, completion
External Linksexternal-links.mdGitHub PR and GitLab MR integration
Formattingformatting.mdOutput templates for different modes
Data Gathererscripts/gather_status_data.pyAsync batch data collection (update-weekly-status)
Issue Summarizerscripts/summarize_issue.pyCompact summaries of pre-gathered issue JSON
Issue Triagescripts/triage_issues.pyBatch triage of pre-gathered issue directories
Feature Update Validatorscripts/validate_feature_updates.pyValidate generated feature-update markdown

Configuration Parameters

Both commands share the same engine with different configuration:

Parameterstatus-rollupupdate-weekly-statusgenerate-feature-updates
data_sourceMCP API callsPre-gathered JSON filesPre-gathered JSON files
root_issuesSingle issue keyMultiple (from manifest.json)Multiple (from manifest.json)
date_range.startUser-specified or issue creationtoday - 7 daystoday - 7 days
date_range.endUser-specified or todaytodaytoday
output_formatmarkdown_commentryg_fieldfeature_markdown
output_targetComment on root issueStatus Summary fieldstdout
external_linksVia gh CLIPre-gathered in JSONPre-gathered in JSON
user_reviewYes (before posting comment)Yes (approve/modify/skip per issue)Yes (full-section review)
cachingTemp file for refinementJSON files in .work/JSON files in .work/

Hierarchy Traversal

Both commands use the same traversal mechanism via childIssuesOf() JQL:

Root Issue (FEATURE-123)
    │
    ├── Epic 1 (EPIC-456)
    │   ├── Story 1.1
    │   │   └── Subtask 1.1.1
    │   └── Story 1.2
    │
    └── Epic 2 (EPIC-789)
        └── Story 2.1

JQL: issue in childIssuesOf(FEATURE-123)
Returns: ALL descendants at any depth (EPIC-456, Story 1.1, Subtask 1.1.1, Story 1.2, EPIC-789, Story 2.1)

Key benefit: childIssuesOf() is already recursive - a single JQL query returns the entire hierarchy regardless of depth. No manual recursion needed.

The difference between commands is not in traversal but in:

  • Data source: update-weekly-status uses pre-gathered JSON; status-rollup uses MCP calls
  • Scope: status-rollup analyzes one root; update-weekly-status analyzes many roots
  • Filtering: update-weekly-status data is pre-filtered to date range by the Python script
  • Aggregation: status-rollup combines all descendants into one summary; update-weekly-status generates per-root summaries

Shared Data Structures

AnalysisConfig

Configuration passed from calling command:

json
{
  "root_issues": ["OCPSTRAT-1234"],
  "date_range": {
    "start": "2025-01-06",
    "end": "2025-01-13"
  },
  "output_format": "markdown_comment",
  "output_target": "comment",
  "external_links_enabled": true,
  "cache_to_file": true,
  "filters": {
    "component": null,
    "label": null,
    "assignees": [],
    "excluded_assignees": []
  }
}
IssueActivityData

The core data structure for each analyzed issue:

json
{
  "issue_key": "OCPSTRAT-1234",
  "summary": "Implement feature X",
  "status": "In Progress",
  "assignee": "user@example.com",
  "issue_type": "Story",
  "date_range": {
    "start": "2025-01-06",
    "end": "2025-01-13"
  },
  "changelog": {
    "status_transitions": [
      {"from": "To Do", "to": "In Progress", "date": "2025-01-07", "author": "user@example.com"}
    ],
    "field_changes": [],
    "last_status_summary_update": "2025-01-05T10:30:00Z"
  },
  "comments": [
    {"author": "user@example.com", "date": "2025-01-08", "body": "Started work on PR #123", "is_bot": false}
  ],
  "descendants": [
    {"key": "OCPSTRAT-1235", "summary": "Sub-task 1", "status": "Done", "updated_in_range": true}
  ],
  "external_links": {
    "github_prs": [
      {"url": "https://github.com/org/repo/pull/123", "state": "MERGED", "title": "Add feature X"}
    ],
    "gitlab_mrs": []
  },
  "analysis": {
    "health": "green",
    "blockers": [],
    "risks": [],
    "achievements": ["PR #123 merged", "Sub-task 1 completed"],
    "in_progress": ["Sub-task 2 under review"],
    "metrics": {
      "total_descendants": 3,
      "completed": 1,
      "in_progress": 1,
      "blocked": 0,
      "completion_percentage": 33
    }
  }
}

Execution Flow

When a command invokes this skill, follow this sequence:

Step 1: Initialize Configuration

The calling command provides an AnalysisConfig. Parse and validate:

REQUIRED parameters:
  - root_issues: Array of issue keys to analyze
  - date_range: {start, end} in YYYY-MM-DD format
  - output_format: "markdown_comment", "ryg_field", or "feature_markdown"

OPTIONAL parameters:
  - external_links_enabled: boolean (default: true)
  - cache_to_file: boolean (default: false)
  - filters: component, label, assignee filters
Step 2: Data Collection

Follow data-collection.md which supports two modes:

Option A: Pre-Gathered Data (update-weekly-status)

Data has already been collected by the Python script (gather_status_data.py):

  1. Read manifest from .work/weekly-status/{date}/manifest.json
  2. For each issue, read .work/weekly-status/{date}/issues/{ISSUE-KEY}.json
  3. Data includes: issue metadata, descendants, changelogs, comments, PRs (all pre-filtered to date range)

Option B: Direct MCP Calls (status-rollup)

  1. For each root issue:

    • Fetch issue details with fields=summary,status,assignee,issuelinks,comment,{custom-fields}
    • Fetch changelog with expand=changelog
  2. Discover all descendants:

    • Use issue in childIssuesOf({root-issue}) to get full hierarchy
    • Optionally filter by date range: AND updated >= {start-date}
    • Use limit=100 (increase if needed for large hierarchies)
  3. For each descendant issue:

    • Fetch issue details and changelog
    • Track which descendants were updated within date range
  4. Build IssueActivityData for root and all descendants

  5. Optionally cache to temp file (for refinement workflows)

Step 3: Activity Analysis

Follow activity-analysis.md to:

  1. Filter to date range:

    • Changelog entries within [start_date, end_date]
    • Comments created within [start_date, end_date]
  2. Identify key events:

    • Status transitions (especially: started, completed, blocked)
    • Assignee changes
    • Priority/severity changes
  3. Analyze comment content:

    • Blockers: "blocked", "waiting on", "stuck", "dependency"
    • Risks: "risk", "concern", "problem", "at risk"
    • Completion: "completed", "done", "merged", "delivered"
    • Progress: "started", "working on", "implementing"
  4. Determine health status:

    • Green: Good progress, PRs merged/in review, no blockers
    • Yellow: Minor concerns, slow progress, manageable blockers
    • Red: Significant blockers, no progress, major risks
  5. Calculate metrics:

    • Total/completed/in-progress/blocked descendants
    • Completion percentage
Show full SKILL.md (385 more words)Show less

Follow external-links.md to:

  1. Extract GitHub PR URLs:

    • From issuelinks field (remote links)
    • From description and comments (text parsing)
    • From descendants' links
  2. Fetch PR metadata (if gh CLI available):

    bash
    gh pr view {PR-NUMBER} --repo {REPO} --json state,updatedAt,mergedAt,title
  3. Track PR activity:

    • PRs merged within date range
    • PRs updated within date range
    • Open PRs awaiting review
  4. Handle GitLab MRs:

    • Extract URLs, note for manual checking
    • Use glab if available
Step 5: Format Output

Follow formatting.md to generate output based on output_format:

For markdown_comment (status-rollup):

markdown
## Status Rollup From: {start-date} to {end-date}

**Overall Status:** [Health assessment]

**This Week:**
- Completed:
  1. [ISSUE-KEY] - [Achievement]
- In Progress:
  1. [ISSUE-KEY] - [Current state]
- Blocked:
  1. [ISSUE-KEY] - [Blocker reason]

**Next Week:**
- [Planned items]

**Metrics:** X/Y issues complete (Z%)

Note: When posting via addCommentToJiraIssue, always include contentFormat: "markdown".

For ryg_field (update-weekly-status):

* Color Status: {Red, Yellow, Green}
 * Status summary:
     ** Thing 1 that happened since last week
     ** Thing 2 that happened since last week
 * Risks:
     ** Risk 1 (or "None at this time")

For feature_markdown (generate-feature-updates):

- [ISSUE-KEY](https://issues.redhat.com/browse/ISSUE-KEY): Issue summary
    - 1-3 sentences of executive prose. No metrics, no R/Y/G.
- [ISSUE-KEY-2](https://issues.redhat.com/browse/ISSUE-KEY-2): Issue summary
    - Prose focusing on significant progress, deliveries, blockers, or risks.
Step 6: Return to Calling Command

Return structured result:

json
{
  "issues_analyzed": [...IssueActivityData],
  "formatted_outputs": {
    "OCPSTRAT-1234": "formatted status text..."
  },
  "summary": {
    "total": 5,
    "by_health": {"green": 3, "yellow": 1, "red": 1}
  },
  "cache_file": "/tmp/jira-status-{issue-id}-{timestamp}.md"
}

The calling command then handles:

  • User review and approval workflow
  • Posting to Jira (comment or field update)
  • Summary report generation

Error Handling

All modules should handle these error cases:

ErrorHandling
Issue not foundLog warning, skip issue, continue with others
Permission deniedDisplay clear error, suggest checking MCP config
No activity in date rangeGenerate summary based on current state
GitHub CLI not availableSkip PR analysis, note in output
Rate limitingDisplay error with retry guidance
Large hierarchies (100+ issues)Show progress indicators
Missing JSON fileLog warning: "Data file for {key} not found, skipping"

Performance Considerations

  • Use pre-gathered data: For batch operations (update-weekly-status), always use the Python data gatherer
  • Minimize API calls: Only fetch fields you need (for status-rollup)
  • Fetch changelogs via expand: Use expand=changelog in getJiraIssue calls
  • BFS hierarchy traversal: Use parent = KEY per level with recursive BFS (Cloud-compatible replacement for childIssuesOf())
  • Cache data: Store in temp file for refinement iterations
  • Parallelize: Python script handles parallel fetching; MCP calls can run concurrently
  • Limit comments: Truncate comments post-fetch to reduce analysis scope
  • Filter early: Data gatherer pre-filters to date range; apply in JQL for MCP calls

Custom Fields

Field NameField IDTypePurpose
Status Summarycustomfield_10814StringStores R/Y/G status text for update-weekly-status

Prerequisites

For update-weekly-status

Check setup:

bash
python3 -c "import aiohttp; print('aiohttp OK')"
echo $JIRA_API_TOKEN
gh auth token
For status-rollup
  • Jira MCP server configured and accessible
  • GitHub CLI (gh) installed and authenticated (optional but recommended)
  • GitLab CLI (glab) installed and authenticated (optional)

Check for tools:

bash
which gh && gh auth status
which glab && glab auth status  # optional

© openshift-eng, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 8 other files (scripts) in plugins/jira/skills/status-analysis of openshift-eng/ai-helpers.

  • SKILL.md
  • activity-analysis.md
  • data-collection.md
  • external-links.md
  • formatting.md
  • scripts/gather_status_data.py
  • scripts/summarize_issue.py
  • scripts/triage_issues.py
  • scripts/validate_feature_updates.py

Open the folder on GitHubat commit a627176

Compare with similar skills

Status Analysis next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Status Analysis compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Status Analysis this skillopenshift-eng/ai-helpers120—~4.2kAutomated safety check: PassApache-2.0
Management Talkthananon/9arm-skills3.2k—~3.2kAutomated safety check: PassNone
YugabyteDB Issue Creatoryugabyte/yugabyte-db11k—~2kAutomated safety check: PassCustom licence
Dynamo Jira TicketDynamoDS/Dynamo2k—~1.1kAutomated safety check: PassApache-2.0
Code Reviewcroffasia/itsaplan903—~2kAutomated safety check: PassAGPL-3.0
Connect Apps with ComposioComposioHQ/awesome-claude-skills77k3 repos~557Automated safety check: PassNone

Similar skills

  • Management Talk

    thananon/9arm-skills

    Rewrite engineer-to-engineer content for engineering-org leadership (VPs, directors, PMs, release managers, execs in an engineering-savvy company) and shape it for the channel it is going to — JIRA…

    3.2k GitHub stars~3.2k tokensUpdated 3 mo ago
    Productivity & AutomationAuto-check passed
  • YugabyteDB Issue Creator

    yugabyte/yugabyte-db

    Creates a GitHub issue or JIRA ticket for a YugabyteDB change or bug, after scrubbing customer data, secrets and unreleased details from anything public.

    11k GitHub stars~2k tokensUpdated today
    DevelopmentAuto-check passed
  • Dynamo Jira Ticket

    DynamoDS/Dynamo

    Create structured Jira tickets for Dynamo from bug reports, failing tests, or feature requests.

    2k GitHub stars~1.1k tokensUpdated today
    Testing & QAAuto-check passed
  • Code Review

    croffasia/itsaplan

    A skill your agent uses when reviewing code — a diff, a merge request, a file, a directory, or a feature.

    903 GitHub stars~2k tokensUpdated today
    DevelopmentAuto-check passed
  • Connect Apps with Composio

    ComposioHQ/awesome-claude-skills

    Connects an agent to 1000+ external apps through the Composio Tool Router plugin, so it can actually send emails, create issues and post messages instead of only drafting them.

    77k GitHub starsUsed in 3 repos~557 tokens
    Productivity & AutomationAuto-check passed
  • PR Body

    SAP/spartacus

    Official

    A skill your agent uses when the user asks to generate, write, or draft a pull request (PR) body or description for the current branch.

    784 GitHub stars~499 tokensUpdated today
    DevelopmentAuto-check passed

More from openshift-eng/ai-helpers

All 118 skills in this repo
  • Investigate CI Reliability

    openshift-eng/ai-helpers

    Find and independently validate actionable reliability defects across OpenShift release jobs and presubmits, then export portable issue handoffs.

    120 GitHub stars~1.9k tokensUpdated yesterday
    Auto-check passed
  • Address Review PR

    openshift-eng/ai-helpers

    Fetch and address all PR review comments — categorize by priority, make code changes, post replies, and push.

    120 GitHub stars~2.9k tokensUpdated yesterday
    Auto-check passed
  • Categorize Activity Types

    openshift-eng/ai-helpers

    Categorize Jira issues into Red Hat Sankey Activity Type categories using MCP Jira tools.

    120 GitHub stars~2.4k tokensUpdated yesterday
    Auto-check passed
  • Has Review Work

    openshift-eng/ai-helpers

    Decide whether a GitHub PR has unanswered authorized review comments or new required CI failures worth a follow-up agent.

    120 GitHub stars~1.9k tokensUpdated yesterday
    Auto-check passed
  • Must Gather Analyzer

    openshift-eng/ai-helpers

    Analyze OpenShift must-gather diagnostic data including cluster operators, pods, nodes, and network components.

    120 GitHub stars~2.3k tokensUpdated yesterday
    Auto-check passed
  • Payload Autodl JSON

    openshift-eng/ai-helpers

    Schema for the autodl JSON data file produced by payload-analysis for database ingestion — you must use this skill whenever generating the autodl JSON file

    120 GitHub stars~2.6k tokensUpdated yesterday
    Auto-check passed

Works with

Questions about Status Analysis

What does Status Analysis do?

Shared engine for analyzing Jira issue activity and generating status summaries. Status Analysis is an agent skill from openshift-eng/ai-helpers.

How do I install Status Analysis in Claude Code?

Run `npx skills add openshift-eng/ai-helpers --skill status-analysis -a claude-code`. Or copy the skill folder (plugins/jira/skills/status-analysis in openshift-eng/ai-helpers) into .claude/skills/status-analysis in your project. Claude Code loads it when a task matches its description.

How do I install Status Analysis in Codex?

Run `npx skills add openshift-eng/ai-helpers --skill status-analysis -a codex`. Or copy the skill folder (plugins/jira/skills/status-analysis in openshift-eng/ai-helpers) into .agents/skills/status-analysis in your project. Codex loads it when a task matches its description.

Can I use Status Analysis in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add openshift-eng/ai-helpers --skill status-analysis -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/status-analysis, .gemini/skills/status-analysis, .github/skills/status-analysis and .opencode/skills/status-analysis in your project.

What does Status Analysis need to run?

Going by SKILL.md and its folder, Status Analysis needs Python for the scripts in its folder, the command-line tools its instructions call (gh, python3 and glab) and credentials named JIRA_API_TOKEN and GITHUB_TOKEN. Our summary lists: Python 3.

Does Status Analysis access the network?

SKILL.md names 3 domains. In commands or code: issues.redhat.com and github.com; the agent is likely to contact these when it follows the instructions. As links in the text: id.atlassian.com. This is read from the text; nothing was executed.

Is Status Analysis safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Status Analysis use?

Status Analysis is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Status Analysis use?

About 4.2k tokens (SKILL.md is roughly 17k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Status Analysis?

Skills that share tags, products or a category with Status Analysis: Management Talk (thananon/9arm-skills, 3.2k stars), YugabyteDB Issue Creator (yugabyte/yugabyte-db, 11k stars), Dynamo Jira Ticket (DynamoDS/Dynamo, 2k stars) and Code Review (croffasia/itsaplan, 903 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Status Analysis?

openshift-eng (a GitHub organization) maintains it in openshift-eng/ai-helpers, which has 120 GitHub stars. The repository holds 118 skills in this directory. The repository was last updated on October 6, 2026.

Source: openshift-eng/ai-helpers on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.