New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Jira Validate Blockers

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

Detailed implementation guide for validating proposed release blockers

Apache-2.0Auto-check passed

Install Jira Validate Blockers

skills CLI
$ npx skills add openshift-eng/ai-helpers --skill jira-validate-blockers -a claude-code

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

GitHub CLI
$ gh skill install openshift-eng/ai-helpers jira-validate-blockers --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/jira-validate-blockers .claude/skills/jira-validate-blockers && 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
jira-validate-blockers
GitHub stars
120
Token cost
~3.5k tokens
SKILL.md length
1,314 words
Files
1
Skills in repo
118
Repo updated
First seen
Licence
Apache-2.0

At a glance

Detailed implementation guide for validating proposed release blockers

  • Works in 6 steps: Parse Arguments → Build JQL Query for Proposed Blockers → Query Proposed Blockers → …
  • SKILL.md covers When to Use This Skill, Prerequisites, Detailed Implementation Steps and Performance Considerations, plus 2 more sections
  • Reaches redhat.atlassian.net

What it does

Jira Validate Blockers is an agent skill from openshift-eng/ai-helpers. Detailed implementation guide for validating proposed release blockers

Its SKILL.md is about 3.5k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

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

Example prompts

  • “/jira-validate-blockers”

Workflow steps

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

  1. Parse Arguments
  2. Build JQL Query for Proposed Blockers
  3. Query Proposed Blockers
  4. Analyze Each Proposed Blocker
  5. Generate Validation Report
  6. Error Handling

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

    No scripts in the folder and no shell commands in SKILL.md (its code samples are jql and markdown).

    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:

    • redhat.atlassian.net

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

  • Credentials

    Names no API keys, tokens, secrets or passwords.

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

Context cost

Jira Validate Blockers loads about 3.5k tokens when it runs. Until then it costs about 23 tokens; SKILL.md has 1,314 words of instructions outside code blocks.

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

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); files beside SKILL.md 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,314 words, ~3,469 tokens.

Download SKILL.mdSave it as .claude/skills/jira-validate-blockers/SKILL.md (or your agent's skills folder).
name
jira-validate-blockers
description
Detailed implementation guide for validating proposed release blockers
command
/jira:validate-blockers

JIRA Release Blocker Validator - Implementation Guide

This skill provides detailed implementation guidance for the /jira:validate-blockers command, which helps release managers make data-driven blocker approval/rejection decisions.

When to Use This Skill

This skill is invoked automatically when the /jira:validate-blockers command is executed. It provides step-by-step implementation details for:

  • Querying JIRA for proposed release blockers (Release Blocker = Proposed)
  • Scoring blockers against Red Hat OpenShift release blocker criteria
  • Generating APPROVE/REJECT/DISCUSS recommendations

Prerequisites

  • Jira MCP server must be configured (see plugin README)
  • MCP Jira tools available (Atlassian Rovo MCP)
  • Read-only access to JIRA APIs (no credentials required for public Red Hat JIRA issues)
  • For single bug mode: bug must be accessible and exist

Detailed Implementation Steps

Phase 1: Parse Arguments

Parse command-line arguments:

  • Extract target version from $1 (optional, format: X.Y like "4.21")
  • Extract component filter from $2 (optional, supports comma-separated values)
  • Extract --bug flag value (optional, for single bug validation mode)

Project:

  • Hardcoded to "OCPBUGS" project

Validate inputs:

  • If neither --bug nor target-version is provided, error out with message: "Error: Either target-version or --bug must be provided. Usage: /jira:validate-blockers [target-version] [component-filter] [--bug issue-key]"
  • If target version provided, verify it matches pattern X.Y (e.g., "4.21", "4.22")
  • If component filter provided without target version and without --bug, error out
Phase 2: Build JQL Query for Proposed Blockers

Determine query mode:

  1. Single bug mode (if --bug is provided):

    • Skip JQL query construction
    • Use getJiraIssue to fetch the single bug
    • Target version and component filter are ignored in this mode
    • Proceed to analysis with single bug only

  2. Version + component mode (if both target version and component are provided):

    • Build JQL query for proposed blockers matching target version and component filter
    • Continue with query construction below

  3. Version only mode (if only target version provided):

    • Build JQL query for all proposed blockers for the target version
    • Continue with query construction below

Base JQL for proposed blockers:

jql
project = OCPBUGS AND type = Bug AND "Release Blocker" = Proposed

IMPORTANT: Use "Release Blocker" = Proposed NOT cf[12319743]. The field ID customfield_10847 is the Release Blocker field, but in JQL use the field name.

Version filter construction:

When target version is provided (e.g., "4.21"), expand to search for both X.Y and X.Y.0:

jql
AND ("Target Version" in (4.21, 4.21.0) OR "Target Backport Versions" in (4.21, 4.21.0) OR affectedVersion in (4.21, 4.21.0))

Status exclusion filter:

Always exclude already-fixed bugs:

jql
AND status not in (Closed, "Release Pending", Verified, ON_QA)

Component filter construction:

No component specified:

  • Query all components (no component filter in JQL)

Single component:

jql
AND component = "{COMPONENT}"

Multiple components (comma-separated):

jql
AND component IN ({COMPONENT_LIST})

Final JQL examples:

Version only (4.21):

jql
project = OCPBUGS AND type = Bug AND "Release Blocker" = Proposed AND ("Target Version" in (4.21, 4.21.0) OR "Target Backport Versions" in (4.21, 4.21.0) OR affectedVersion in (4.21, 4.21.0)) AND status not in (Closed, "Release Pending", Verified, ON_QA)

Version + component (4.21, "Hypershift"):

jql
project = OCPBUGS AND type = Bug AND "Release Blocker" = Proposed AND ("Target Version" in (4.21, 4.21.0) OR "Target Backport Versions" in (4.21, 4.21.0) OR affectedVersion in (4.21, 4.21.0)) AND status not in (Closed, "Release Pending", Verified, ON_QA) AND component = "Hypershift"

Version + multiple components (4.21, "Hypershift,CVO"):

jql
project = OCPBUGS AND type = Bug AND "Release Blocker" = Proposed AND ("Target Version" in (4.21, 4.21.0) OR "Target Backport Versions" in (4.21, 4.21.0) OR affectedVersion in (4.21, 4.21.0)) AND status not in (Closed, "Release Pending", Verified, ON_QA) AND component IN ("Hypershift", "Cluster Version Operator")
Phase 3: Query Proposed Blockers

Use MCP tools to fetch proposed blockers:

For version/component mode, use searchJiraIssuesUsingJql:

  • jql: The constructed JQL query from Phase 2
  • fields: ["key", "summary", "priority", "severity", "status", "assignee", "created", "updated", "labels", "components", "description", "reporter", "customfield_10847", "customfield_10855"]
  • maxResults: 100 (maximum per page; use nextPageToken to paginate if more results exist)

Parse the response to extract:

  • Total count of proposed blockers
  • List of bug objects with all required fields

Custom fields to include:

  • customfield_10847 - Release Blocker status (should be "Proposed")
  • customfield_10855 - Target Version

For single bug mode (--bug flag), fetch the bug by key via getJiraIssue:

  • issueIdOrKey: The bug key provided by user
  • expand: "renderedFields"

Handle query results:

  • If total is 0, display message: "✅ No proposed blockers found" with filter summary
  • If total > 20, show progress indicator
  • Cache all bug data for analysis (avoid re-querying)
Phase 4: Analyze Each Proposed Blocker

Analyze each proposed blocker using Red Hat OpenShift release blocker criteria.

Red Hat OpenShift Release Blocker Criteria:

Based on the official OpenShift blocker definition, bugs should be approved as release blockers when they meet these criteria:

Automatic/Strong Blockers (Recommend APPROVE):

  • Component Readiness regressions (label: ComponentReadinessRegression) - even tech-preview jobs, unless covered by approved exceptions
  • Service Delivery blockers (label: ServiceDeliveryBlocker) - most bugs with this label are blockers
  • Data loss, service unavailability, or data corruption - most bugs in this category are blockers
  • Install/upgrade failures - may be blockers based on scope (all platforms vs specific form-factor)
  • Perception of failed upgrade - bugs that appear as upgrade failures to users
  • Regressions from previous release - most regressions are blockers (e.g., from Layered Product Testing)
  • Bugs severely impacting Service Delivery - regressions/bugs in default ROSA/OSD/ARO fleet features without acceptable workaround

Never Blockers (Recommend REJECT):

  • Severity below Important - no bugs with Low/Medium severity are blockers
  • New features without regressions - most new feature bugs are NOT blockers unless they regress existing functionality
  • CI-only issues - bugs that only affect CI infrastructure/jobs and don't impact product functionality are NOT release blockers
    • Look for labels: ci-fail, ci-only, test-flake
    • Check summary/description for keywords: "CI job", "test failure", "rehearsal", "periodic job", "e2e test"
    • Check comments for explicit statements like "Won't affect the product", "CI-only", "infrastructure issue"
    • Even if the bug describes install/upgrade failures, if it only manifests in CI environments, recommend REJECT

Workaround Assessment (may affect recommendation):

An acceptable workaround must meet ALL three criteria:

  1. Idempotent - can be applied repeatedly without resulting change
  2. Safe at scale - can be safely deployed to 1000's of clusters without material risk via automation
  3. Timely - SD can implement before release is pushed to more Cincinnati channels (candidate, fast, stable)
Show full SKILL.md (498 more words)Show less

If a workaround doesn't meet all three criteria, it's NOT an acceptable workaround.

For each proposed blocker:

  1. Fetch bug details including summary, description, labels, priority, severity, comments
  2. Check for CI-only indicators (REJECT criteria):
    • Check labels: ci-fail, ci-only, test-flake
    • Check summary/description for CI-specific keywords:
      • "CI job", "test failure", "rehearsal", "periodic job", "e2e test", "periodic-ci-"
    • Check comments for explicit CI-only statements:
      • "Won't affect the product"
      • "CI-only"
      • "infrastructure issue"
      • "only affects CI"
    • If CI-only indicators found, recommend REJECT regardless of severity or failure type
  3. Analyze blocker criteria (if not CI-only):
    • Check labels: ComponentReadinessRegression, ServiceDeliveryBlocker, UpgradeBlocker
    • Check severity: Must be Important or higher (Critical/Urgent)
    • Analyze summary/description for keywords:
      • Data loss, corruption, service unavailable
      • Install failure, upgrade failure
      • Regression
    • Identify scope: All platforms vs specific form-factor/configuration
  4. Check for acceptable workarounds:
    • Use expand="renderedFields" to get comment text
    • Search for keywords: "workaround", "work around", "alternative", "bypass"
    • Assess if workaround meets all 3 criteria (idempotent, safe at scale, timely)
  5. Generate recommendation:
    • ✅ APPROVE - Meets automatic/strong blocker criteria, no acceptable workaround
    • ❌ REJECT - CI-only issue, OR severity below Important, OR new feature without regression, OR has acceptable workaround
    • ⚠️ DISCUSS - Edge cases requiring team discussion

Use MCP tools:

  • getJiraIssue with expand="renderedFields" to get comments
  • Analyze comment text for workaround mentions
Phase 5: Generate Validation Report

Create comprehensive Markdown report with all blocker validation results.

Report Structure:

markdown
# 🚫 Release Blocker Validation Report
**Components**: {component list or "All"} | **Project**: OCPBUGS | **Proposed Blockers**: {count} | **Generated**: {timestamp}

## Summary
- ✅ **Recommend APPROVE**: X
- ❌ **Recommend REJECT**: Y
- ⚠️ **Needs DISCUSSION**: Z

---

## Blocker Analysis

### {BUG-KEY}: {Summary} {VERDICT}

**Recommendation**: {APPROVE/REJECT/DISCUSS} - {One-line justification}

**Criteria Matched**:
- {✅/❌} {Criterion name}
- {✅/❌} {Criterion name}
- ...

**Justification**:
{Detailed explanation of why this bug should or shouldn't be a blocker}

**Suggested Action**: {What to do next}

---

[Repeat for each proposed blocker]

---

## Next Steps
1. Review APPROVE recommendations - add to blocker list
2. Review REJECT recommendations - remove blocker status
3. Discuss unclear cases in triage meeting

Special case for single bug mode:

When --bug flag is used, adapt the report to focus on a single bug:

  • Summary shows single bug details (key, summary, verdict)
  • Analysis section shows detailed criteria analysis for this specific bug
  • Next Steps adapted for single bug action
Phase 6: Error Handling

Invalid issue ID (single bug mode):

  • Display error: "Could not find issue {issue-id}"
  • Verify issue ID is correct format
  • Check user has access to the issue

Invalid arguments:

  • Invalid component name: Warn but continue (JIRA will return no results)

No proposed blockers found:

  • Display success message: "✅ No proposed blockers found"
  • Show filter summary (components, project: OCPBUGS)
  • Confirm no blocker decisions needed

MCP tool errors:

  • If searchJiraIssuesUsingJql fails, display JQL query and error message
  • If getJiraIssue fails:
    1. Fallback to WebFetch: Try fetching via https://redhat.atlassian.net/browse/{issue-key}
    2. If WebFetch succeeds: Parse the web page to extract bug details (summary, severity, description) and continue with validation
    3. If WebFetch also fails: Display clear error indicating bug doesn't exist or isn't accessible
  • Provide troubleshooting guidance (check MCP server, verify credentials)

Large result sets (>50 blockers):

  • Show progress indicators during analysis
  • Consider warning user: "Found {count} proposed blockers. This may take a moment to analyze."

Performance Considerations

  • Query optimization: Only fetch proposed blockers (cf[12319940] = "Proposed")
  • Component scoping: Use component filters to reduce result set size
  • Batch operations: Use searchJiraIssuesUsingJql with appropriate maxResults (avoid pagination when possible)
  • Caching: Store bug data in memory during execution to avoid re-querying JIRA

JQL Query Examples

Version only (4.21):

jql
project = OCPBUGS AND type = Bug AND "Release Blocker" = Proposed AND ("Target Version" in (4.21, 4.21.0) OR "Target Backport Versions" in (4.21, 4.21.0) OR affectedVersion in (4.21, 4.21.0)) AND status not in (Closed, "Release Pending", Verified, ON_QA)

Version + single component (4.21, "Hypershift"):

jql
project = OCPBUGS AND type = Bug AND "Release Blocker" = Proposed AND ("Target Version" in (4.21, 4.21.0) OR "Target Backport Versions" in (4.21, 4.21.0) OR affectedVersion in (4.21, 4.21.0)) AND status not in (Closed, "Release Pending", Verified, ON_QA) AND component = "Hypershift"

Version + multiple components (4.21, multiple):

jql
project = OCPBUGS AND type = Bug AND "Release Blocker" = Proposed AND ("Target Version" in (4.21, 4.21.0) OR "Target Backport Versions" in (4.21, 4.21.0) OR affectedVersion in (4.21, 4.21.0)) AND status not in (Closed, "Release Pending", Verified, ON_QA) AND component IN ("Hypershift", "Cluster Version Operator")

Custom Fields

Field NameField IDJQL NameType
Release Blockercustomfield_10847"Release Blocker"String
Target Versioncustomfield_10855"Target Version"String

© 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

Just SKILL.md in plugins/jira/skills/jira-validate-blockers of openshift-eng/ai-helpers.

Open the folder on GitHubat commit a627176

Compare with similar skills

Jira Validate Blockers 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.

Jira Validate Blockers compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Jira Validate Blockers this skillopenshift-eng/ai-helpers120—~3.5kAutomated safety check: PassApache-2.0
Link Ticket To SessionJayantDevkar/claude-code-karma329—~1.8kAutomated safety check: NotesApache-2.0
Jira Natural Language Interfacejjmartres/opencode1333 repos~1.7kAutomated safety check: PassMIT
Issue Triage Loopcobusgreyling/loop-engineering11k—~522Automated safety check: PassMIT
Create Epic RecapDataDog/datadog-agent3.8k—~5kAutomated safety check: NotesApache-2.0
Pilot Updatequay/quay2.8k—~3.5kAutomated safety check: PassApache-2.0

Similar skills

  • Link Ticket To Session

    JayantDevkar/claude-code-karma

    Link the current Claude Code session to a ticket (Linear, Jira, GitHub Issues, or GitHub Pull Requests) and cache its title/status in karma.

    329 GitHub stars~1.8k tokensUpdated 11 days ago
    DevelopmentAuto-check: notes

  • Jira Natural Language Interface

    jjmartres/opencode

    Lets an agent view, create, update and transition Jira issues in natural language, automatically choosing between the jira CLI and Atlassian MCP tools.

    133 GitHub starsUsed in 3 repos~1.7k tokens
    Product & Project ManagementAuto-check passed

  • Issue Triage Loop

    cobusgreyling/loop-engineering

    Scans open GitHub issues and discussions, flags duplicates, scores priority and proposes labels into issue-triage-state.md without ever labeling or closing.

    11k GitHub stars~522 tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Create Epic Recap

    DataDog/datadog-agent

    Official

    A skill your agent uses when an engineer or manager asks to recap, summarize, or post an update on a Jira Epic — a progress update for an in-progress Epic (how far along it is, what's shipped so…

    3.8k GitHub stars~5k tokensUpdated today
    DevelopmentAuto-check: notes

  • Pilot Update

    quay/quay

    Post a biweekly Agentic SDLC pilot update comment to PROJQUAY-11352.

    2.8k GitHub stars~3.5k tokensUpdated today
    Testing & QAAuto-check passed

  • Akb Ingest

    dnotitia/akb

    Ingest whatever you point at into an AKB vault — a local file, a web URL, a GitHub PR/release/commit, a Confluence page, or a Jira issue.

    162 GitHub stars~2k tokensUpdated yesterday
    Agent WorkflowsAuto-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 3 days ago
    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 3 days ago
    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 3 days ago
    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 3 days ago
    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 3 days ago
    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 3 days ago
    Auto-check passed

Works with

Questions about Jira Validate Blockers

What does Jira Validate Blockers do?

Detailed implementation guide for validating proposed release blockers. Jira Validate Blockers is an agent skill from openshift-eng/ai-helpers.

How do I install Jira Validate Blockers in Claude Code?

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

How do I install Jira Validate Blockers in Codex?

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

Can I use Jira Validate Blockers 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 jira-validate-blockers -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/jira-validate-blockers, .gemini/skills/jira-validate-blockers, .github/skills/jira-validate-blockers and .opencode/skills/jira-validate-blockers in your project.

What does Jira Validate Blockers need to run?

SKILL.md names no scripts, command-line tools or credentials: Jira Validate Blockers is instructions for the agent only.

Does Jira Validate Blockers access the network?

SKILL.md names 1 domain. In commands or code: redhat.atlassian.net; the agent is likely to contact it when it follows the instructions. This is read from the text; nothing was executed.

Is Jira Validate Blockers 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. Review the folder before installing.

What licence does Jira Validate Blockers use?

Jira Validate Blockers 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 Jira Validate Blockers use?

About 3.5k tokens (SKILL.md is roughly 14k 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 Jira Validate Blockers?

Skills that share tags, products or a category with Jira Validate Blockers: Link Ticket To Session (JayantDevkar/claude-code-karma, 329 stars), Jira Natural Language Interface (jjmartres/opencode, 133 stars), Issue Triage Loop (cobusgreyling/loop-engineering, 11k stars) and Create Epic Recap (DataDog/datadog-agent, 3.8k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Jira Validate Blockers?

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.