Menu
Fix a failing PR by analyzing CI logs and fixing errors. Autonomous workflow that identifies failures, rebases, fixes issues, and pushes.
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.
Based on SOC occupation classification
Spot-check the health of a live Aztec network deployment by sweeping recent GCP logs for warn/error messages, mapping each to the deployed code, classifying expected vs unexpected, and verifying the hard invariants (no slashing, no attestation timeouts, no unexplained prunes/conflicts). Use when asked to "spot-check", "review logs", or "health check" a network (staging, testnet, devnet, ...) over a recent window.
Reference for merge-train automation internals -- workflows, scripts, CI integration, and configuration. Use when modifying or debugging merge-train infrastructure.
Build and update the developer documentation site for a new release
Guide for working with merge-train branches -- creating PRs, choosing the right base branch, understanding labels, handling failures, and bypassing checks.
Create a well-formed Linear issue — with complete context for a fresh agent, a point estimate (1/2/3/5), and acceptance criteria. Works standalone or as part of planning a project with multiple issues. Use when asked to file/create/open a Linear issue, "make a ticket", or when breaking a plan into tracked work.
Build or adjust a Linear cycle — for a whole team or just yourself. Size capacity from last-3-cycle velocity, fill with backlog bugs/high-priority items first and project work after (in your chosen project focus order), with no unassigned issues. Use when planning/prepping a cycle for a team, or when one member wants to fill/rebalance their own cycle work.
| name | fix-pr |
| description | Fix a failing PR by analyzing CI logs and fixing errors. Autonomous workflow that identifies failures, rebases, fixes issues, and pushes. |
| argument-hint | <PR number> |
Autonomous workflow to fix CI failures for a PR. Delegates failure identification to subagent, then applies fixes.
/fix-pr 19882
Before doing anything, verify the PR is valid:
gh pr view <PR> --repo AztecProtocol/aztec-packages --json state,baseRefName,headRefName
Abort if:
state is not OPEN → "PR #<N> is <state>, nothing to fix."Spawn the identify-ci-failures subagent:
Use Task tool with subagent_type: "identify-ci-failures"
Prompt: "Identify CI failures for PR <number>"
This returns:
If the subagent cannot find CI logs, ask the user for:
gh pr checkout <PR>
git fetch origin <base-branch>
git rebase origin/<base-branch>
If there are conflicts:
git add <resolved-files>git rebase --continueImportant: Always REBASE, never merge.
Check if changes exist outside yarn-project:
git diff origin/<base-branch>...HEAD --name-only | grep -v '^yarn-project/'
If yes, run bootstrap:
(cd $(git rev-parse --show-toplevel) && ./bootstrap.sh build yarn-project)
Run from yarn-project directory.
| Failure Type | Fix Action |
|---|---|
| FORMAT | yarn format |
| LINT | yarn lint |
| BUILD | yarn build, fix TypeScript errors, repeat |
| UNIT TEST | yarn workspace @aztec/<package> test <file>, fix, repeat |
| E2E TEST | For simple failures, fix. For complex failures, suggest /debug-e2e |
Before committing, run from yarn-project:
yarn build
yarn format
yarn lint
Run tests for modified files:
yarn workspace @aztec/<package> test <file>.test.ts
If the PR targets next, amend to keep it as a single commit:
git add .
git commit --amend --no-edit
git push --force-with-lease
Otherwise, create a normal commit:
git add .
git commit -m "fix: <description of fix>"
git push
identify-ci-failures subagent, don't analyze logs directlynext: Other PRs use normal commits/debug-e2eCLAUDE.md for project conventions/debug-e2e skill for complex e2e failure analysis