gh

Name: gh
Availability: InStock
Author: Tsuga

Correlate GitHub incident time windows with PRs, workflow runs, releases, and deployments.

2|Updated May 28, 2026

Search Tags:#github #pull requests #deployment verification #workflow runs #release tracking #incident triage #commit investigation

Ready to run

npx skills add https://github.com/tsuga-dev/agent-plugins --skill gh-tsuga-dev

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: gh
Source: https://github.com/tsuga-dev/agent-plugins/tree/main/plugins/tsuga/skills/gh
Command: npx skills add https://github.com/tsuga-dev/agent-plugins --skill gh-tsuga-dev

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you determine what changed and what actually shipped during an incident window by inspecting GitHub workflow runs, PRs, releases, and deployments.

Core Features & Use Cases

Incident window correlation: Tie a time range to merged PRs, workflow executions, release tags, commit SHAs, and deployment status.
Evidence-first investigation: Use read-only checks to distinguish merged code from deployed outcomes and produce citations like run URL, PR number, tag, or SHA.
Common investigation workflows: Identify the PRs merged in a timeframe, review what a specific commit touched, and verify whether the expected deploy occurred per environment.

Quick Start

Ask the AI to correlate your incident time window (start/end) with the GitHub repo’s merged PRs and the deployed workflow runs for the affected environments using gh.

Frequently Asked Questions about gh

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

FAQPage Schema

How do I correlate an incident time window with GitHub deployments and merged pull requests?▼

Incident triage with GitHub involves inspecting merged PRs, workflow runs, releases, and deployment statuses within a specific time window to determine what changed. It distinguishes merged code from actual production deployments using read-only GitHub CLI commands.

Why does a merged GitHub pull request not always correspond to a production deploy?▼

A merged GitHub pull request may not reach production if the workflow run failed or the deployment status per environment remains pending. Deployment verification requires checking workflow run outcomes and environment-specific deployment statuses rather than relying on CI pass or fail colors alone.

How do I verify deployment status per environment during a GitHub incident investigation?▼

Verify deployment status per environment by executing read-only GitHub CLI inspection commands to validate workflow runs and deployment outcomes for the affected environments. This provides citations like run URLs and commit SHAs to confirm whether the expected deploy actually occurred.

Do I need GH_TOKEN to investigate GitHub workflow runs and release tracking?▼

Yes, investigating GitHub workflow runs and release tracking requires an authenticated GH_TOKEN environment variable. The GitHub CLI uses this token to execute read-only inspection commands for PRs, workflow runs, and deployment statuses.

What is the best way to perform commit-level impact analysis for incident forensics in GitHub?▼

The best way to perform commit-level impact analysis is to correlate a specific commit SHA with merged PRs, workflow executions, and deployment outcomes during the incident window. This evidence-first approach provides verifiable citations like run URLs and release tags.

Can I use this approach for release verification across multiple environments?▼

Yes, this approach supports release verification across multiple environments by validating per-environment deployment and workflow run statuses. It tracks release tags and run outcomes to confirm delivery in repositories where deployments are managed independently.