メニュー
Isolate the first actionable failure in an already-red GitHub Actions or GitLab CI run. Use when a concrete PR, MR, workflow, job, or pipeline is failing; do not use for general repo preflight, local test selection, or healthy deploy verification.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Autonomously audit native local Codex session JSONL for workflow quality, latency, cost shape, tool use, recurring failures, and eval candidates. Use when the user wants scheduled harness observability or evidence-driven harness improvement; do not use for ordinary task execution, application telemetry, or full transcript export.
Verify an existing build artifact itself: metadata, complete download, checksum or size, archive integrity, unpacked contents, and source or lock provenance. Use when artifact contents or completeness must be proven; do not use to trigger builds, releases, deploys, or health checks.
Diagnose the live remote-access layer: SSH resolution, reachability, Tailscale, login-shell PATH, service state, package-manager locks, and remote CLI auth. Use when a named remote host or service is unreachable or unhealthy; do not use for deploy planning or ordinary local repo work.
Establish the current repo, instruction, branch, dirty-worktree, and linked live-object facts before non-trivial work. Use once at the start of repo work when current state or scope is unclear; do not stack it onto every later workflow phase.
Carry already-scoped code changes through verification, commit, push, PR/MR, authorized merge, and authorized cleanup. Use when the requested outcome includes delivery actions; do not use for review-only work, initial repo discovery, CI diagnosis, or deploy execution.
GitLab CLI workflows with `glab` for issues, merge requests, CI/CD, and GitLab API operations. Use when the user needs GitLab command-line automation, issue or MR triage, pipeline checks, API queries, threaded discussion replies, release checks, or work item conversion and hierarchy updates. Prefer `glab api` for reliable scripted flows, while keeping direct CLI commands and local helper scripts available for common MR and pipeline tasks.
| name | ci-first-failure |
| description | Isolate the first actionable failure in an already-red GitHub Actions or GitLab CI run. Use when a concrete PR, MR, workflow, job, or pipeline is failing; do not use for general repo preflight, local test selection, or healthy deploy verification. |
| argument-hint | [run url, pipeline url, branch, sha, or repo] |
Find the failing job before editing code.
gh run list --limit 10
gh run view <run-id> --json status,conclusion,headSha,url,jobs
gh run view <run-id> --log-failed
Extract:
Inspect the run's actual workflow revision when it may differ from the current default branch.
Prefer glab api or bounded glab ci calls:
glab ci list --ref <branch> --per-page 10
glab ci view <pipeline-id>
glab api "projects/<project>/pipelines/<pipeline-id>/jobs" | jq '.[] | {id,name,status,web_url}'
glab api "projects/<project>/jobs/<job-id>/trace" | tail -n 120
Lead with:
Do not edit from local assumptions until the failing job, step, exact SHA, and first useful error are identified. Later failures may be fallout; inspect them only if the first failure does not explain the run.