[shauryagangrade]

What this adds

A skill for the question every red build raises first: is this failure mine?

It pulls the failing job's real log with gh run view --log-failed, reads the
first error in the failing step rather than the tail, and classifies the failure
as bug / flaky / environment / pipeline with the evidence for that class. It
then compares against the base branch and recent runs before claiming ownership,
reproduces with the versions CI actually used, and recommends exactly one
action: retry, fix the code, or fix the pipeline. For a flaky test it records a
repeated-run tally and requires an owner and removal date instead of another
blind re-run.

Why it is not a duplicate

• github-actions-efficiency cuts CI cost and runtime; this one triages a
  specific failure.
• cypress-flake-fixer is specific to Cypress; this is stack-agnostic triage
  that can hand off to a domain skill.
• verify-agent-action reviews a proposed agent action; this reviews a finished
  CI result.
• Nothing in skills/ currently answers whether a failure was introduced by the
  current change, which is the first question on a failing PR check.

Checks

• npm run skill:validate passes (456 skills valid)
• npm run build run, docs/README.skills.md regenerated with one added row
• No bundled assets, no scripts, no new dependencies
• No em dashes in the added content

Happy to trim the scope or split the flaky-test guidance into a separate skill
if that fits the review better.

[github-actions]

🚦 Submission status: 🛠️ Requires submitter fixes

Risk tier: merge-risk:high — Privileged execution, automation, or review-policy change
Required to merge: passing submission-gate checks plus 1 approval from reviewers with write access, including a maintainer with admin or maintain permission.

Why this tier

• Label needs-review:HIGH flags a high contributor-risk signal

Automated checks

Check	Status	Details
Line endings	✅ Passed	Passed · logs
Spelling	✅ Passed	Passed · logs
Generated README consistency	✅ Passed	Passed · logs
Skill validation	✅ Passed	Passed · logs
Skill lint (vally)	✅ Passed	Passed · logs
Risk scan	✅ Passed	Passed · logs
Contributor reputation	✅ Passed	Passed · logs
Duplicate resource scan	✅ Passed	Passed · logs
PR quality signal	⏭️ Skipped	Skipped by its workflow · logs

Action needed

• Address the changes requested by aaronpowell, then push an update.

Review

• Approvals: 0/1
• Assigned reviewer: not assigned yet — comment /request-review to ask for one
• Review target date: not set
• Still needed: 1 more approval(s); an approval from a maintainer with admin or maintain permission; resolution of changes requested by aaronpowell
• The core-maintainers pool is not staffed yet; an approver with admin or maintain permission is required instead.

Commands

Command	Who	What it does
/rerun-checks	PR author, maintainers	Re-runs failed or incomplete checks and re-evaluates this gate
/request-review	PR author, maintainers	Asks the review rotation to assign a reviewer (adds needs-reviewer)

_{Updated for b75bd8c · gate run · This comment is maintained automatically — see submission gate docs.}

[github-actions]

🔒 PR Risk Scan Results

Scanned 2 changed file(s).

Severity	Count
🔴 High	0
🟠 Medium	0
ℹ️ Info	0

✅ No matching risk patterns were detected in changed files.

This is an automated soft-gate report. Findings indicate review targets and do not block merge by themselves.

[github-actions]

🔴 Contributor Reputation Check: HIGH risk

Check	Risk
Profile	HIGH
Credential audit	NONE

Maintainers: please review this contributor before merging.
See the workflow run for full details.
Automated check powered by AGT.

[github-actions]

🔍 Vally Lint Results

✅ All checks passed

Scope	Checked
Skills	1
Agents	0
Total	1

Severity	Count
❌ Errors	0
⚠️ Warnings	0
ℹ️ Advisories	0

Summary

Level	Finding
ℹ️	✅ diagnose-ci-gate (2/2 checks passed)
ℹ️	✓ [spec-compliance] All 1 skill(s) are spec-compliant.
ℹ️	✓ spec-compliance: All spec checks passed.
ℹ️	✓ [valid-refs] All file references across 1 skill(s) are valid.
ℹ️	✓ valid-refs: All file references resolve to existing files within the skill directory.
ℹ️	1 skill(s) linted, 1 passed

Full linter output

### Linting skills/diagnose-ci-gate
✅ diagnose-ci-gate (2/2 checks passed)
    ✓ [spec-compliance] All 1 skill(s) are spec-compliant.
        ✓ spec-compliance: All spec checks passed.
    ✓ [valid-refs] All file references across 1 skill(s) are valid.
        ✓ valid-refs: All file references resolve to existing files within the skill directory.

1 skill(s) linted, 1 passed

[aaronpowell]

Thanks for adding this focused CI-triage skill. The PR reports npm run skill:validate and npm run build, but it does not show the skill exercised in GitHub Copilot on a realistic failed check. Please add a concise validation scenario with the check/log, diagnosis, and recommended action. Also, Step 4 hardcodes /tmp/ci-base for the worktree example; please make that path and cleanup procedure portable and collision-safe, or explicitly scope the example to POSIX shells.

[shauryagangrade]

Both points are addressed in 059b0a2, thanks for the specific review.

1. Validation scenario

Added references/validation.md, linked from the skill's ## Validation section. It records the skill applied to a real failed check in a public repo:

• Check: New external links (PR only), run 40091680340, head 5ea9cff6
• Log: 18 added URLs checked, one returns 404, 17 of 18 links healthy, exit 1
• Diagnosis: classified as pipeline, not a bad link. The page was generated correctly in the PR (it exists in 5ea9cff6), but the URL host is the production deployment, which serves main, and the page only reached main 66 minutes after the run. No retry or link edit can make that green, so the action is to fix the check's target, not the source.
• Reproduction: the 404 cannot be reproduced now because the page has since deployed; the doc states that and gives the deterministic evidence (present in the PR, absent from main before c283b32, URL returns 200 today).

One thing to be explicit about: I do not have Copilot CLI or Copilot Chat access in the environment where I prepared this, so I did not invent a Copilot transcript. This is a recorded application of the skill's own checklist against a real public run, with every run ID and SHA checkable. If the gate specifically needs a transcript from inside Copilot, that needs a run from an environment with Copilot access.

2. Portable worktree

Step 4 no longer hardcodes /tmp/ci-base:

base_dir="$(mktemp -d)"
git worktree add "$base_dir" "$(git merge-base HEAD origin/main)"
( cd "$base_dir" && <failing command> )
git worktree remove --force "$base_dir"

mktemp -d makes the path collision-safe, --force is explained as safe only because the worktree is disposable and the failing command may write build output into it, and the cleanup explains using git worktree remove rather than rm -rf, with git worktree prune if the directory was already deleted. The section is labelled POSIX shell and includes a PowerShell equivalent for Windows.

Also updated

• The pipeline row in the classification table now includes checks that assert a target a pull request cannot produce, which is the class the scenario lands in.
• Step 4 now says that a job which only runs on pull_request has no base-branch run, so the diff is the ownership evidence instead of an implied comparison. The scenario surfaced that gap.

npm run skill:validate passes (456 skills) and npm run build regenerated the table with references/validation.md in the assets column.

Ready for another look.

[shauryagangrade]

The Copilot CLI transcript is in, at 9e9d072. references/validation.md now leads with it.

Setup

I installed Copilot CLI (@github/copilot 1.0.105) in an isolated npm prefix, authenticated it headlessly with the existing GH_TOKEN, and ran it in a throwaway worktree of the failing commit 3ba8bf96. The skill was the only input besides the job log:

A CI check is failing on this repository and I need to know whether my change caused it.

The failed job log is in ./ci-log.txt. Use the diagnose-ci-gate skill in .github/skills/diagnose-ci-gate/SKILL.md and follow it.

Give me the skill's report, in its format. Do not change any files: I want the diagnosis, not a fix.

Check: Docs structure + em dashes, run 40202831763, head 3ba8bf96. Model gpt-6-luna (the CLI's default), 8 model requests.

The worktree was a full clone, so python3 scripts/build-all.py --check passed locally before the run started. That was deliberate: it is the case where a shallow diagnosis gives up and calls the failure flaky.

Reply, verbatim

I’ll use the supplied job log first, then compare its SHA and failure against the base branch and recent CI evidence.

The run is a `main` push at the checked-out SHA, not a PR check; I’m checking the exact job log and nearby `main` runs now, including whether the generated sitemap was already stale before this commit.

```text
Check:       Docs structure + em dashes on 3ba8bf965671e6db8cb05ed089fe3127de9007ad
First error: FAIL stale: website/sitemap.xml (Build all-prompts page, `python3 scripts/build-all.py --check`)
Class:       pipeline — the generator reads Git history for sitemap dates, but CI’s default checkout is shallow.
Ownership:   pre-existing to 3ba8: the same failure occurred on main at 1c981e9 ([run](https://github.com/shauryagangrade/awesome-ai-prompts/actions/runs/40202231365)); that commit introduced the Git-history dependency in `scripts/build-all.py:753-768`. 3ba8 changed only `.markdownlint-cli2.jsonc`.
Reproduced:  no — it passes locally on macOS with Python 3.14.7 and full Git history; CI used Ubuntu 24.04, and its Python version is not in the log.
Action:      fix pipeline — fetch the history the generator requires. The later revert at 64aae52 removed that dependency.
Result:      the check passed on the subsequent main run ([40203292949](https://github.com/shauryagangrade/awesome-ai-prompts/actions/runs/40203292949)); no files changed.

The document has the full text including the two preamble lines, unaltered.

## Verified after the fact

- `get_git_lastmod()` is added in `1c981e9` and removed in `64aae52`; `3ba8bf96` changes only `.markdownlint-cli2.jsonc`.
- The parent commit `1c981e9` failed the same job, run [40202231365](https://github.com/shauryagangrade/awesome-ai-prompts/actions/runs/40202231365). Ownership is pre-existing, as it said.
- A full clone passes. A `git fetch --depth 1` of the same commit fails with `FAIL stale: website/sitemap.xml`, which is what CI's default checkout does. That is the pipeline cause it named.
- Run [40203292949](https://github.com/shauryagangrade/awesome-ai-prompts/actions/runs/40203292949) at `64aae52` passed.

The second scenario is still there, condensed to the parts that justify the `pull_request`-only caveat in Step 4.

`npm run skill:validate` passes and `npm run build` leaves the generated table unchanged.

[shauryagangrade]

@aaronpowell please review

[shauryagangrade]

One clarification now on the record in b75bd8c, since the reviewer should not have to infer it: the seven steps, four failure classes, checklist, and rules are a copy-paste prompt I published on 2026-10-24, before this skill existed. references/validation.md links it.

The skill is the packaging, not a new methodology: a fixed report block, the base-branch worktree recipe, the pull_request-only caveat, and the validation above. The prompt has no output format, which is why agents using it reported "looks unrelated" with nothing to check.

[shauryagangrade]

@aaronpowell, this is ready for another look when you have a moment.

Both items from your review are in:

• Validation: references/validation.md now leads with a genuine GitHub Copilot CLI run (1.0.105) against a real failed job, prompted only with the job log. It classified the failure as pipeline, attributed it to the parent commit, and both findings were confirmed afterwards. The log, the prompt, the verbatim reply, and the checks I ran on it are all in the doc.
• Portable worktree: Step 4 uses mktemp -d, git worktree remove --force, and a PowerShell variant, with the cleanup rules spelled out.

Two things changed as a result of exercising it: the pipeline class now covers checks that assert a target a PR cannot produce, and Step 4 handles PR-only jobs where no base-branch run exists.

One thing on the record rather than left implied: the seven steps and four classes are a prompt I published on 2026-10-24, before this skill existed, and references/validation.md links it. The skill is the packaging plus the report format and the validation.

All content checks on b75bd8c are green (build, pr-check, skill-check, validate-skills, codespell, check-line-endings). The gate is blocked only on your re-review clearing CHANGES_REQUESTED, which I cannot trigger from a fork.