// Run local CI checks and verify GitHub Actions status. Use before committing, after pushing, or when asked to check/fix CI.
| name | ci-check |
| description | Run local CI checks and verify GitHub Actions status. Use before committing, after pushing, or when asked to check/fix CI. |
Run CI checks locally first, then verify GitHub Actions if the branch has been pushed.
Run ./scripts/ci-local.sh to execute the same checks as GitHub Actions: install, build, typecheck, and docker build. If any step fails, fix it before proceeding.
Use ./scripts/ci-local.sh --quick to skip the docker build when iterating on TypeScript fixes.
Run gh run list --branch $(git branch --show-current) --limit 1 to find the most recent CI run for this branch. If no runs exist, the branch hasn't been pushed yet — tell the user.
If the run status is completed and conclusion is success, report that CI is green and stop.
If the run is in_progress, run gh run watch <run-id> to wait for completion. Then re-check.
If the run failed, proceed to Step 3.
Run gh run view <run-id> --log-failed to get only the log lines from failed steps. This is more focused than --log which dumps everything.
Identify which step failed:
pnpm install --frozen-lockfile — lockfile out of syncpnpm turbo build — TypeScript compilation errorpnpm turbo typecheck — type errors without builddocker build — Dockerfile issueBased on the failure:
Lockfile drift: Run pnpm install locally and commit the updated pnpm-lock.yaml.
Build/typecheck failure: Read the error, find the file and line, fix the issue. Run ./scripts/ci-local.sh --quick to verify before pushing.
Docker build failure: Read the error. Common causes: missing COPY for a new config file, changed package name, missing dependency. Run ./scripts/ci-local.sh (full) to verify.
After fixing, push the branch and run Step 2 again. Repeat until CI is green.
| Command | Purpose |
|---|---|
./scripts/ci-local.sh | Full local CI (install, build, typecheck, docker) |
./scripts/ci-local.sh --quick | Local CI without docker build |
gh run list --branch <branch> --limit 5 | List recent runs for a branch |
gh run view <id> | Summary of a specific run |
gh run view <id> --log-failed | Only failed step logs |
gh run watch <id> | Wait for an in-progress run |
Discover any website's API and create domain plugins with proxy routes. Use when the user wants to create an API for a website, discover a web service's data transport, add a new domain, capture browser traffic, build typed API clients, or integrate with a third-party site. Also use when the user mentions a website name and wants to interact with it programmatically.
Build a complete application from a short description. Asks the developer clarifying questions, generates data requirements, launches discovery agents, and builds a dashboard. Use when the developer describes what they want to build in plain language — "compare tickets", "track prices", "search jobs across sites".
Deploy to EC2 production server. Use when deploying new code, rebuilding Docker images, wiping and reseeding the database, checking container health, or managing the EC2 instance via AWS CLI.
Build Next.js dashboard pages that consume domain proxy APIs. Use when the user wants to create a dashboard, build a UI page, add a search interface, display data from captured APIs, create comparison views, or build any frontend that calls /api/<domain>/ endpoints.
Iterative debugging with targeted logs. Use when browser connections fail, traffic capture returns empty, proxy routes return errors, WebSocket issues, or any problem that can't be solved on the first attempt. Add logs, read output, narrow the search, repeat until fixed, then clean up.
Use sub-agents to iteratively improve dashboard-building instructions. Three-phase pipeline — discover APIs, build dashboard matching a wireframe, review code + UI with a SOTA reviewer agent. The dashboards are throwaway; instruction improvements and framework code fixes are the product.