with one click
watch-ci
// Watch GitHub Actions CI status for the current commit until completion. Use after pushing changes to monitor build results.
// Watch GitHub Actions CI status for the current commit until completion. Use after pushing changes to monitor build results.
The end-to-end spec-issue-driven dev loop for lean-spec — spec → branch → implement → PR → merge → closure. Use when asked "how do I start work", "what's the process", "SDD loop", "spec-driven development", "how do we ship a change on lean-spec", "from scratch what do I do", or when you're about to begin a non-trivial change on `codervisor/leanspec` and haven't yet decided how to split spec/PR. Delegates to `issue-spec` (spec writing), `leanspec-pre-push` (pre-push checks), `leanspec-pr-lifecycle` (post-push), and `leanspec-development` (commands, CI, publishing, i18n).
Manage a lean-spec PR after it's been pushed — spec-issue linking, CI triage, review-comment discipline, merge-conflict recovery on open PRs, webhook subscription, and CHANGELOG follow-through on merge. Triggers include "CI is failing", "check is red", "link this issue", "Closes vs Part of", "respond to review", "subscribe to PR", "triage PR", "the PR is ready", "PR has conflicts", "branch has conflicts with main", "merge conflict on the PR", or when a github-webhook-activity event arrives on a lean-spec PR. Paired with `leanspec-dev-process` (overall loop), `issue-spec` (spec creation), and `leanspec-pre-push` (which owns the pre-push conflict walkthrough).
Run before pushing code to the lean-spec repo to catch what reviewers and CI will catch later, and confirm the branch has a linked spec issue in a valid state. Reproduces the merge-preview environment, walks through this repo's common merge-conflict patterns, and runs the project's typecheck / clippy / test gates. Triggers include "before push", "ready to push", "pre-push check", "push readiness", "prep for PR", "resolve merge conflict", "merge conflict", "branch has conflicts", "sync with main", or proactively before any git push on a lean-spec branch.
Development workflows, commands, publishing, CI/CD, changelog management, and contribution guidelines for LeanSpec. Use when contributing code, fixing bugs, setting up dev environment, running tests or linting, working with the monorepo structure, looking up build/dev/test/publish/format/lint commands, preparing releases, publishing to npm, bumping versions, syncing package versions, testing dev builds, troubleshooting npm distribution, updating changelogs, triggering CI/CD workflows, monitoring build status, debugging failed runs, managing artifacts, checking CI before releases, or researching AI agent runners. Triggers include any development, scripting, publishing, CI/CD, changelog, or runner research task in this project.
The spec-coding methodology for AI-assisted development. Use when planning features, creating/refining/implementing/verifying specs, or organising a project. Works with whatever spec backend your team already uses — local markdown, GitHub Issues, Azure DevOps, Jira — by delegating platform-specific details to a LeanSpec adapter.
| name | watch-ci |
| description | Watch GitHub Actions CI status for the current commit until completion. Use after pushing changes to monitor build results. |
| allowed-tools | Bash |
| metadata | {"internal":true} |
Poll the GitHub Actions CI pipeline for the current HEAD commit until all jobs finish.
The gh CLI is not available in the Claude VM. Use the GitHub REST API via curl.
The repo is codervisor/leanspec.
Get the current commit SHA and branch:
SHA=$(git rev-parse HEAD)
BRANCH=$(git branch --show-current)
echo "Watching CI for commit $SHA on branch $BRANCH"
Find the workflow run matching our exact commit. The API returns runs newest-first; filter by head_sha. If the run hasn't appeared yet (GitHub can take a few seconds), retry up to 5 times with 10s waits:
curl -sH "Accept: application/vnd.github+json" \
"https://api.github.com/repos/codervisor/lean-spec/actions/runs?branch=$BRANCH&head_sha=$SHA&per_page=1" \
| python3 -c "
import json, sys
data = json.load(sys.stdin)
runs = data.get('workflow_runs', [])
if not runs:
print('NO_RUNS'); sys.exit()
r = runs[0]
print(f'RUN_ID={r[\"id\"]}')
print(f'Status: {r[\"status\"]} Conclusion: {r.get(\"conclusion\") or \"pending\"} Commit: {r[\"head_sha\"][:8]}')"
Poll jobs until all complete (every 60s for Rust builds which take ~8-10 min):
curl -sH "Accept: application/vnd.github+json" \
"https://api.github.com/repos/codervisor/lean-spec/actions/runs/$RUN_ID/jobs" \
| python3 -c "
import json, sys
data = json.load(sys.stdin)
for j in data.get('jobs', []):
steps = [s for s in j.get('steps', []) if s['status'] == 'in_progress']
step_info = f' -> {steps[0][\"name\"]}' if steps else ''
print(f'{j[\"name\"]:40} {j[\"status\"]:12} {j.get(\"conclusion\") or \"\"}{step_info}')"
On failure, fetch the failed job logs to diagnose:
curl -sH "Accept: application/vnd.github+json" \
"https://api.github.com/repos/codervisor/lean-spec/actions/runs/$RUN_ID/jobs" \
| python3 -c "
import json, sys
data = json.load(sys.stdin)
for j in data.get('jobs', []):
if j.get('conclusion') == 'failure':
print(f'FAILED: {j[\"name\"]} (id: {j[\"id\"]})')
for s in j.get('steps', []):
if s.get('conclusion') == 'failure':
print(f' Step: {s[\"name\"]}')"
Give the user a brief status update each poll cycle. On completion, summarize: