Run any Skill in Manus with one click

wait-for-pr-checks

Stars6

Forks0

UpdatedMay 18, 2026 at 06:27

Poll a GitHub PR's checks until they all pass, any one fails, or a timeout is hit. Returns a structured outcome the caller can gate on. TRIGGER when the user says "wait for CI", "wait for the PR checks", "watch the PR", "is CI green yet", "babysit this PR's checks", "block until checks pass", "/nyann:wait-for-pr-checks". Do NOT trigger on "what's the PR status" (that's a one-off `gh pr view` — no polling). Do NOT trigger on "merge this PR" — that's the action AFTER waiting; consider `/nyann:ship` instead, which combines wait + merge.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

thettwe

thettwe/nyann

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Network and Computer Systems AdministratorsComputer and Mathematical Occupations·SOC 15-1244

SKILL.md

readonly

name

wait-for-pr-checks

description

wait-for-pr-checks

Wraps bin/wait-for-pr-checks.sh. Poll-based; uses gh pr checks <num> under the hood. The script is the same one release.sh will uses to gate the tag step (when --wait-for-checks is passed), so the contract is shared.

1. Resolve the PR number

The script auto-resolves from the current branch via gh pr view, so the most common invocation is:

bin/wait-for-pr-checks.sh --target <cwd>

Pass --pr <number> when watching a PR you don't have checked out.

2. Tune timeout and cadence

Defaults:

--timeout 1800 (30 minutes)
--interval 30 (poll every 30 seconds)

Bump timeout for slow CI matrices ("integration tests take 90 min" → --timeout 7200). Drop interval for snappy local CI ("we Just hit go" → --interval 10). Don't go below 10 seconds — gh API rate limits start to bite.

3. Interpret the outcome

The script emits a PRChecksResult JSON. Branch on .outcome:

Outcome	Meaning	What the user should do
`pass`	every check completed with a passing conclusion	proceed with the gated action (merge, tag, deploy)
`no-checks`	PR has no checks attached	proceed; treat as pass
`fail`	at least one check failed (loop bailed early)	open the linked workflow; don't proceed
`timeout`	deadline reached, some still in_progress	retry with a longer timeout, or investigate slow runners
`skipped`	gh missing/unauthenticated, or PR couldn't be resolved	tell the user; can't proceed

Exit code mirrors the outcome: 0 for pass / no-checks / skipped, 3 for fail / timeout — caller scripts can gate on $?.

4. Combining with merge

This skill only waits. To wait-then-merge in one step, use /nyann:ship — it opens a PR and merges it in one flow (either via GitHub auto-merge or by polling CI client-side). Reserve this skill for cases where the user wants the wait surfaced explicitly (release runs, manual gating).

When to hand off

"Merge it for me when CI passes" → /nyann:ship (opens a PR and merges it, waiting for CI as needed).
"I just want the current status, don't wait" → gh pr checks directly; no polling needed.
"Why did check X fail?" → gh run view <run-id> --log-failed; this skill only reports outcomes, not log contents.

More from this repository

same repository

doctor

thettwe/nyann

Run a read-only hygiene + documentation audit on the current repo. TRIGGER when the user says "is this repo healthy", "check hygiene", "audit this repo" (when they mean inspect, not remediate), "what's drifted", "run doctor", "run a health check", "audit docs", "check for doc drift", "what's broken in this project", "are the hooks still installed", "/nyann:doctor". Do NOT trigger on "fix this repo" / "remediate" / "bring it into compliance" — those are retrofit (audit + fix). doctor reports, never writes. Do NOT trigger on "what does this repo do" (that's a docs pointer, not a hygiene audit).

2026-06-296

iac-apply

thettwe/nyann

Actually APPLY an Infrastructure-as-Code change — the highest-stakes mutator in nyann; it can mutate real cloud infrastructure. Re-runs the plan, shows it, confirms with the user, then invokes `bin/iac-apply.sh --apply` (adding `--confirm-destroy` only when the user explicitly confirms a destructive change). UNMISTAKABLY opt-in: apply is never the default, destructive applies need a second explicit confirmation. TRIGGER when the user says "terraform apply", "apply the infra change", "deploy this infrastructure", "tofu apply", "cdk deploy", "pulumi up", "helm upgrade", "kubectl apply", "apply the plan", "run the apply now", "yes apply it" (in an IaC context), "ship the infra change", "provision this", "/nyann:apply". DISAMBIGUATION — fire ONLY for IaC apply intent on a detected infra repo. Do NOT trigger on the generic word "apply": NOT "apply this code patch", NOT "apply the suggestion", NOT "apply formatting", NOT "apply a migration" (DB migrations are out of scope), NOT "apply for X". An infra signal is REQ

2026-06-296

iac-plan

thettwe/nyann

Preview an Infrastructure-as-Code change WITHOUT applying it. Runs `bin/iac-plan.sh`, which detects the repo's IaC tool (terraform, opentofu, aws-cdk, pulumi, helm, kubernetes, kustomize, ansible), shells out to the user's already-authenticated CLI, and renders a normalized add/change/destroy summary. READ-ONLY — it never mutates infrastructure. TRIGGER when the user says "terraform plan", "preview my infra change", "what will this deploy", "cdk diff", "pulumi preview", "show me the terraform diff", "dry-run the infra change", "what would terraform/tofu/cdk/pulumi do", "plan the infrastructure", "kubectl diff", "helm diff", "what does this deploy change", "/nyann:plan". DISAMBIGUATION — fire ONLY for IaC plan intent on a detected infra repo. Do NOT trigger on the bare word "plan": this is NOT project planning, NOT sprint/roadmap planning, NOT `sc:*` task planning, NOT Claude's ExitPlanMode / "make a plan" for code work. "plan a feature", "plan my week", "let's plan the refactor" → ignore. Require an infra sig

2026-06-296

thettwe/nyann

Open a GitHub pull request from the current branch, with a Conventional-Commits-style title and a body summarizing the commit range. TRIGGER when the user says "open a PR", "create a pull request", "push and PR", "submit this for review", "ship this PR", "open a draft PR", "file a PR for this branch", "/nyann:pr". Do NOT trigger on "merge the PR" / "approve the PR" / "review PR #N" — those are GitHub actions outside nyann's wedge. Do NOT trigger on "rebase" / "sync with main" / "update my branch" — that's the `sync` skill. Do NOT trigger when the user is on `main` or `master` (no PR to open); if detected, tell them to create a branch first and route to `new-branch`.

2026-06-296

settings

thettwe/nyann

Interactive settings menu for nyann preferences. View current values in a table, then pick one setting to change at a time via AskUserQuestion. Re-runnable anytime — does not require a full setup wizard. TRIGGER when the user says "change nyann settings", "nyann preferences", "configure nyann settings", "update my preferences", "toggle triage", "disable sentinel", "enable session triage", "/nyann:settings", "show nyann settings", "nyann config". ALSO trigger on direct shortcut: "/nyann:settings <key> <value>" — skip the menu and write the value directly. Do NOT trigger on "/nyann:setup" — that is the first-run wizard. Do NOT trigger on "/nyann:check-prereqs" — that inspects host tools, not nyann config.

2026-06-296

ship

thettwe/nyann

Open a PR and merge it in one step — combines `bin/pr.sh` create with `bin/wait-for-pr-checks.sh` polling and `gh pr merge`. Default mode enables GitHub's native auto-merge so the terminal returns immediately; `--client-side` polls in the foreground and merges when CI goes green. TRIGGER when the user says "ship this PR", "ship it", "open and merge", "PR and merge", "create PR and auto-merge it", "wait for CI then merge", "block until merged", "/nyann:ship". Do NOT trigger on "open a PR" alone (no merge intent) — that's the `pr` skill. Do NOT trigger on "merge this existing PR #N" — ship is PR-creation + merge, not standalone merge of an already-open PR. Do NOT trigger on "release X.Y.Z" — that's the `release` skill, which tags a merged commit rather than creating one.

2026-06-296

name

wait-for-pr-checks

description

wait-for-pr-checks

1. Resolve the PR number

The script auto-resolves from the current branch via gh pr view, so the most common invocation is:

bin/wait-for-pr-checks.sh --target <cwd>

Pass --pr <number> when watching a PR you don't have checked out.

2. Tune timeout and cadence

Defaults:

--timeout 1800 (30 minutes)
--interval 30 (poll every 30 seconds)

3. Interpret the outcome

The script emits a PRChecksResult JSON. Branch on .outcome:

Outcome	Meaning	What the user should do
`pass`	every check completed with a passing conclusion	proceed with the gated action (merge, tag, deploy)
`no-checks`	PR has no checks attached	proceed; treat as pass
`fail`	at least one check failed (loop bailed early)	open the linked workflow; don't proceed
`timeout`	deadline reached, some still in_progress	retry with a longer timeout, or investigate slow runners
`skipped`	gh missing/unauthenticated, or PR couldn't be resolved	tell the user; can't proceed

Exit code mirrors the outcome: 0 for pass / no-checks / skipped, 3 for fail / timeout — caller scripts can gate on $?.

4. Combining with merge

When to hand off

"Merge it for me when CI passes" → /nyann:ship (opens a PR and merges it, waiting for CI as needed).
"I just want the current status, don't wait" → gh pr checks directly; no polling needed.
"Why did check X fail?" → gh run view <run-id> --log-failed; this skill only reports outcomes, not log contents.