fix.md

description	Fix-iteration agent. When review.md flags a pull request with the 'agent/fixme' label, this agent reads the reviewer's feedback and pushes follow-up commits to the same branch, closing the code -> review -> fix loop.
true	pull_request bots types labeled ${{ vars.GH_AW_APP_BOT_SLUG }}
if	github.event.label.name == 'agent/fixme'
concurrency	group cancel-in-progress gh-aw-${{ github.workflow }}-${{ github.event.pull_request.number || github.ref || github.run_id }}-${{ github.event.label.name || github.run_id }} true
permissions	contents issues pull-requests read read read
runs-on	ubuntu-26.04
imports	shared/defaults.md shared/workflow-tools.md
tools	bash github * toolsets default
safe-outputs	threat-detection github-app add-comment remove-labels push-to-pull-request-branch runs-on ubuntu-26.04 client-id private-key permissions ${{ vars.GH_AW_APP_CLIENT_ID }} ${{ secrets.GH_AW_APP_PRIVATE_KEY }} workflows write max 1 max allowed 1 agent/fixme max protected-files 1 policy ${{ case(contains(github.event.pull_request.labels.*.name, 'agent/workflow-edits-allowed'), 'allowed', 'request_review') }}
jobs	add_working_label remove_working_label needs if runs-on permissions steps pre_activation needs.pre_activation.outputs.activated == 'true' ubuntu-26.04 pull-requests write name id uses with Generate App token app-token actions/create-github-app-token@v3.2.0 client-id private-key ${{ vars.GH_AW_APP_CLIENT_ID }} ${{ secrets.GH_AW_APP_PRIVATE_KEY }} name env run Add agent/fix-working label GH_TOKEN PR_NUMBER REPO ${{ steps.app-token.outputs.token }} ${{ github.event.pull_request.number }} ${{ github.repository }} set -euo pipefail gh pr edit "$PR_NUMBER" --repo "$REPO" --add-label agent/fix-working || true needs if runs-on permissions steps pre_activation activation agent detection safe_outputs always() && needs.pre_activation.outputs.activated == 'true' ubuntu-26.04 pull-requests write name id uses with Generate App token app-token actions/create-github-app-token@v3.2.0 client-id private-key ${{ vars.GH_AW_APP_CLIENT_ID }} ${{ secrets.GH_AW_APP_PRIVATE_KEY }} name env run Remove agent/fix-working label (best-effort) GH_TOKEN PR_NUMBER REPO ${{ steps.app-token.outputs.token }} ${{ github.event.pull_request.number }} ${{ github.repository }} gh pr edit "$PR_NUMBER" --repo "$REPO" --remove-label agent/fix-working || true
timeout-minutes	15

PR Fix Agent

The agent/fixme label was applied to pull request #${{ github.event.pull_request.number }} by the review agent (review.md), meaning it found something that needs to change.

Note: this workflow uses a plain pull_request: types: [labeled] trigger rather than gh-aw's label_command: trigger to maintain manual label consumption and prevent duplicate re-triggers. The label must be consumed manually: this workflow removes agent/fixme itself via remove-labels (step 1 below) so it can't cause a duplicate re-trigger.

Your task

1. Remove the agent/fixme label from this PR via the remove-labels safe-output, so it's consumed and can't re-trigger this workflow.

2. Enforce the iteration cap. Run gh pr view ${{ github.event.pull_request.number }} --json commits --jq '.commits | length' to count the commits on this PR — comparing the count before and after a fix attempt is how to detect whether a new commit was actually pushed, via the GitHub API rather than a raw git fetch. Use gh/the API for this, not git fetch: in the sandboxed agent job, a raw git fetch against this (private) repo is not guaranteed to have working credentials, whereas gh/GH_TOKEN is always set up for you. If the count is already 3 or more, the cap has been reached:

   • Do not make any code changes and do not emit a push-to-pull-request-branch safe-output.
   • Emit an add-comment safe-output on this PR whose body says: the automated fix loop has reached its iteration limit (3) and automated fixing has stopped; a human needs to review the PR and either push a fix commit and apply agent/lgtm directly once satisfied, or close the PR. Explicitly note that re-applying agent/fixme will not give the loop another attempt: this cap is simply the total commit count on the branch, which only grows, so relabeling will immediately hit the same cap again without attempting a fix (the only way to actually continue the automated loop is to reduce the branch's commit count, e.g. by squashing, below 3 first).
   • Stop here. Do not proceed to the remaining steps.

   This caps the loop at 2 fix iterations, on the assumption that drafter.md pushes exactly one initial commit before this workflow ever runs. If a drafter ever pushes more than one initial commit, the cap will trip slightly earlier than 2 true fix iterations — an accepted trade-off for not depending on git fetch credentials that may not be present in the sandbox.

3. Otherwise (cap not reached), determine the PR's branch name by running gh pr view ${{ github.event.pull_request.number }} --json headRefName --jq .headRefName.

4. Read the reviewer's feedback: run gh pr view ${{ github.event.pull_request.number }} --json reviews (or gh api repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/reviews) and use the body of the most recent review to see what needs fixing.

5. Check out the PR branch and make the smallest change that addresses the feedback.

6. Validate your change using whatever the repo actually provides (tests, a lint command, or a small ad hoc check) — do not assume tooling that may not exist.

7. If your change edits any .github/workflows/*.md file, recompile the lockfiles: run just setup && just compile (this recompiles all workflows, not just the one you touched — every .lock.yml must stay in sync with its .md source). Include the resulting .lock.yml changes in your commit. just and the pinned gh-aw CLI are already installed; the sandbox can't install them itself.

8. Push your fix as a new commit on the same branch via the push-to-pull-request-branch safe-output. Do not open a new PR.

Constraints

• Only ever modify the existing PR branch via push-to-pull-request-branch — never push directly to main and never open a new PR.
• Always add a new commit; never git commit --amend an existing commit on this branch. push-to-pull-request-branch can only convey new file changes — an amend that only changes a commit message (no file diff) has nothing in it for that mechanism to push, and will silently look successful while the branch stays exactly as it was. (This should be rare in practice: see review.md, which doesn't request fixes purely over commit message wording, since messages don't survive the final squash merge anyway.)
• Respect the iteration cap in step 2 without exception.
• Always remove agent/fixme (step 1), even if the iteration cap causes you to stop before making any code changes.
• When the iteration cap is reached, never emit add-labels for agent/fixme or agent/lgtm — an unlabeled PR with the cap-reached comment is the intended "stuck, needs a human" signal. Only emit the add-comment safe-output described in step 2.