The watch-ci skill (agents/.config/ai-skills/skills/watch-ci/SKILL.md) documents two
provider recipes. The GitLab one was written
from the API shape without ever being run — glab is not installed on the machine where
the skill was authored, so nothing in it has been confirmed.
Verifying it needs a machine with glab installed and authenticated against a real
GitLab instance, ideally a self-hosted one, since that is the case the provider detection
is meant to handle.
The GitHub recipe is exercised, but not defect-free — see the defect below, found in
use. Fixing that is worth doing whether or not the GitLab verification ever happens.
A defect in the GitHub recipe
The run-selection line is:
gh run list --commit "$sha" --limit 1 --json databaseId --jq '.[0].databaseId'
On a repo that runs more than one workflow per push, that picks whichever run the API
lists first, which is not necessarily the one worth watching. In practice it selected a
Dependency Graph run and reported success while the CI workflow was still in progress —
the same class of misidentification the skill's own "identify the run by commit SHA, not
by branch" rule exists to prevent.
The skill mentions --workflow <name> as an aside further down. It belongs in the recipe
itself, or the recipe should select among the returned runs rather than taking the first.
What to check on GitLab
glab api "projects/:id/pipelines?sha=$sha" resolves the :id placeholder from the
repo's remote. This is the likeliest thing to be wrong; glab may want :fullpath, or
an explicit project ID.- The status polling loop terminates on every terminal status, and does not spin forever
on a status the regex does not list.
- The failed-job commands return what is expected:
glab api "projects/:id/pipelines/$id/jobs" --jq '.[] | select(.status=="failed")'
and glab ci trace <job-id>.
- Detection picks GitLab from
.gitlab-ci.yml on a host whose name does not contain
"gitlab".
- A transient API failure retries rather than reporting the pipeline as failed, matching
the GitHub path's behaviour.
Correct the recipe in place with whatever the real output shows, and drop the caveat in
the skill's commit history once it holds.
The
watch-ciskill (agents/.config/ai-skills/skills/watch-ci/SKILL.md) documents twoprovider recipes. The GitLab one was written
from the API shape without ever being run —
glabis not installed on the machine wherethe skill was authored, so nothing in it has been confirmed.
Verifying it needs a machine with
glabinstalled and authenticated against a realGitLab instance, ideally a self-hosted one, since that is the case the provider detection
is meant to handle.
The GitHub recipe is exercised, but not defect-free — see the defect below, found in
use. Fixing that is worth doing whether or not the GitLab verification ever happens.
A defect in the GitHub recipe
The run-selection line is:
On a repo that runs more than one workflow per push, that picks whichever run the API
lists first, which is not necessarily the one worth watching. In practice it selected a
Dependency Graph run and reported success while the CI workflow was still in progress —
the same class of misidentification the skill's own "identify the run by commit SHA, not
by branch" rule exists to prevent.
The skill mentions
--workflow <name>as an aside further down. It belongs in the recipeitself, or the recipe should select among the returned runs rather than taking the first.
What to check on GitLab
glab api "projects/:id/pipelines?sha=$sha"resolves the:idplaceholder from therepo's remote. This is the likeliest thing to be wrong;
glabmay want:fullpath, oran explicit project ID.
on a status the regex does not list.
glab api "projects/:id/pipelines/$id/jobs" --jq '.[] | select(.status=="failed")'and
glab ci trace <job-id>..gitlab-ci.ymlon a host whose name does not contain"gitlab".
the GitHub path's behaviour.
Correct the recipe in place with whatever the real output shows, and drop the caveat in
the skill's commit history once it holds.