analytics-repo-pruning

Name: analytics-repo-pruning
Availability: InStock
Author: PatternFly

Classify PatternFly Analytics repositories as archived, stale, or active using git activity signals.

10|26|Updated Jul 8, 2025

Search Tags:#analytics #github #repository #gitlab #pruning #activity

Ready to run

npx skills add https://github.com/patternfly/ai-helpers --skill analytics-repo-pruning

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: analytics-repo-pruning
Source: https://github.com/patternfly/ai-helpers/tree/main/plugins/repo-management/skills/analytics-repo-pruning
Command: npx skills add https://github.com/patternfly/ai-helpers --skill analytics-repo-pruning

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires jq, gh, curl, and includes scripts (resource) and references (resource) components.

What problem does it solve?

Keep PatternFly Analytics from tracking archived repositories and repos with no meaningful code activity past a configurable threshold (default 730 days).

Core Features & Use Cases

Bucket repositories based on status (archived, stale, could not verify, active) using host signals such as pushed_at to guide analytics pruning.
Operate on repos.json inputs that contain a top-level repos array with git and name, determine the hosting provider, and rely on existing environment credentials for authenticated API access.
Produce a clear, structured report of per-repo classifications without modifying the input repos.json, suitable for auditing and cleanup.

Quick Start

Run the included analytics-repo-pruning script next to this skill with the path to repos.json to generate a report.

Frequently Asked Questions about analytics-repo-pruning

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I identify archived and stale GitHub repositories in a JSON list?▼

To identify archived and stale GitHub repositories, you can run a script that parses a repos.json file, authenticates to the host API, and checks the pushed_at activity signal to bucket each repo by status. This produces a structured report without modifying your input data.

What is the default inactivity threshold for flagging a stale repository?▼

The default inactivity threshold for flagging a stale repository is 730 days without meaningful code activity. Repositories exceeding this duration since their last pushed_at signal are bucketed as stale for analytics pruning.

Do I need authenticated API access to check GitLab or GitHub repository activity?▼

Yes, you need authenticated API access to check GitLab or GitHub repository activity. The tool relies on your existing environment credentials to fetch activity signals like pushed_at from the hosting provider to accurately verify repository status.

How do I audit repository status without modifying the original repos.json file?▼

You can audit repository status without modifying the original repos.json file by running a read-only pruning script. It classifies entries into archived, stale, could not verify, or active buckets and outputs a separate structured report for safe cleanup.

What happens if a repository cannot be verified during the pruning audit?▼

If a repository cannot be verified during the pruning audit, it is sorted into a dedicated 'could not verify' bucket. This happens when API access fails or the host cannot provide a valid pushed_at activity signal for the entry.

What format does the input repos.json need to be in for repository pruning?▼

The input repos.json format requires a top-level repos array containing objects with both git and name fields. The script determines the hosting provider from the git field to fetch the last activity signals needed for classification.