Gh Pr Checks Plan Fix

Overview

Use gh to locate failing PR checks, fetch GitHub Actions logs for actionable failures, summarize the failure snippet, then propose a fix plan and implement after explicit approval.

• If a plan-oriented skill (for example create-plan) is available, use it; otherwise draft a concise plan inline and request approval before implementing.

Prereq: authenticate with the standard GitHub CLI once (for example, run gh auth login), then confirm with gh auth status (repo + workflow scopes are typically required).

Inputs

• repo: path inside the repo (default .)
• pr: PR number or URL (optional; defaults to current branch PR)
• gh authentication for the repo host

Quick start

• python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "<number-or-url>"
• Add --json if you want machine-friendly output for summarization.

Workflow

1. Verify gh authentication.
   • Run gh auth status in the repo.
   • If unauthenticated, ask the user to run gh auth login (ensuring repo + workflow scopes) before proceeding.
2. Resolve the PR.
   • Prefer the current branch PR: gh pr view --json number,url.
   • If the user provides a PR number or URL, use that directly.
3. Inspect failing checks (GitHub Actions only).
   • Preferred: run the bundled script (handles gh field drift and job-log fallbacks):
     • python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "<number-or-url>"
     • Add --json for machine-friendly output.
   • Manual fallback:
     • gh pr checks <pr> --json name,state,bucket,link,startedAt,completedAt,workflow
       • If a field is rejected, rerun with the available fields reported by gh.
     • For each failing check, extract the run id from detailsUrl and run:
       • gh run view <run_id> --json name,workflowName,conclusion,status,url,event,headBranch,headSha
       • gh run view <run_id> --log
     • If the run log says it is still in progress, fetch job logs directly:
       • gh api "/repos/<owner>/<repo>/actions/jobs/<job_id>/logs" > "<path>"
4. Scope non-GitHub Actions checks.
   • If detailsUrl is not a GitHub Actions run, label it as external and only report the URL.
   • Do not attempt Buildkite or other providers; keep the workflow lean.
5. Summarize failures for the user.
   • Provide the failing check name, run URL (if any), and a concise log snippet.
   • Call out missing logs explicitly.
6. Create a plan.
   • Use the create-plan skill to draft a concise plan and request approval.
7. Implement after approval.
   • Apply the approved plan, summarize diffs/tests, and ask about opening a PR.
8. Recheck status.
   • After changes, suggest re-running the relevant tests and gh pr checks to confirm.

Bundled Resources

scripts/inspect_pr_checks.py

Fetch failing PR checks, pull GitHub Actions logs, and extract a failure snippet. Exits non-zero when failures remain so it can be used in automation.

Usage examples:

• python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "123"
• python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "https://github.com/org/repo/pull/123" --json
• python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --max-lines 200 --context 40

Audio Transcribe

Transcribe audio using OpenAI, with optional speaker diarization when requested. Prefer the bundled CLI for deterministic, repeatable runs.

Workflow

1. Collect inputs: audio file path(s), desired response format (text/json/diarized_json), optional language hint, and any known speaker references.
2. Verify OPENAI_API_KEY is set. If missing, ask the user to set it locally (do not ask them to paste the key).
3. Run the bundled transcribe_diarize.py CLI with sensible defaults (fast text transcription).
4. Validate the output: transcription quality, speaker labels, and segment boundaries; iterate with a single targeted change if needed.
5. Save outputs under output/transcribe/ when working in this repo.

Decision rules

• Default to gpt-4o-mini-transcribe with --response-format text for fast transcription.
• If the user wants speaker labels or diarization, use --model gpt-4o-transcribe-diarize --response-format diarized_json.
• If audio is longer than ~30 seconds, keep --chunking-strategy auto.
• Prompting is not supported for gpt-4o-transcribe-diarize.

Output conventions

• Use output/transcribe/<job-id>/ for evaluation runs.
• Use --out-dir for multiple files to avoid overwriting.

Dependencies (install if missing)

Prefer uv for dependency management.

uv pip install openai

If uv is unavailable:

python3 -m pip install openai

Environment

• OPENAI_API_KEY must be set for live API calls.
• If the key is missing, instruct the user to create one in the OpenAI platform UI and export it in their shell.
• Never ask the user to paste the full key in chat.

Skill path (set once)

export CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
export TRANSCRIBE_CLI="$CODEX_HOME/skills/transcribe/scripts/transcribe_diarize.py"

User-scoped skills install under $CODEX_HOME/skills (default: ~/.codex/skills).

CLI quick start

Single file (fast text default):

python3 "$TRANSCRIBE_CLI" \
  path/to/audio.wav \
  --out transcript.txt

Diarization with known speakers (up to 4):

python3 "$TRANSCRIBE_CLI" \
  meeting.m4a \
  --model gpt-4o-transcribe-diarize \
  --known-speaker "Alice=refs/alice.wav" \
  --known-speaker "Bob=refs/bob.wav" \
  --response-format diarized_json \
  --out-dir output/transcribe/meeting

Plain text output (explicit):

python3 "$TRANSCRIBE_CLI" \
  interview.mp3 \
  --response-format text \
  --out interview.txt

Reference map

• references/api.md: supported formats, limits, response formats, and known-speaker notes.