post-push-loop

Post-Push Loop

Autonomously iterate through the CI/review cycle after a push. Loop exits only when external signals clear (CI green + no unresolved bot findings), or when a finding requires a human decision.

Invoke

/post-push-loop [pr-number]

If pr-number is omitted, auto-detect from gh pr view --json number -q .number.

---

Dependencies

This skill requires ~/.claude/scripts/post-push-status.sh (from the claude-config repo). Before starting, verify it exists and is executable. If missing, escalate immediately — do not attempt to create or substitute it.

Additional requirements: gh (authenticated), jq, python3, and a pre-push git hook with POSTPUSH_LOOP bypass support.

---

Protocol

Before Starting

1. Verify ~/.claude/scripts/post-push-status.sh exists and is executable
2. Confirm current branch: git branch --show-current — must NOT be main
3. Confirm PR number: gh pr view --json number -q .number
4. Confirm POSTPUSH_LOOP will be set for all git push calls in this session

The Loop

Repeat until Exit: Success or Exit: Escalate:

---

Phase 1 — WAIT for CI to complete

Poll every 30 seconds:

bash ~/.claude/scripts/post-push-status.sh <PR_NUMBER>

Continue polling while CI_STATE=PENDING, CI_STATE=EXPECTED, or CI_STATE=UNKNOWN.

CI_STATE=UNKNOWN indicates a transient error (network failure or no CI checks registered yet) — treat it as pending and continue polling. It counts against the 15-minute timeout.

Timeout: if CI_STATE has not resolved after 15 minutes, escalate with reason "CI did not complete within timeout — check for stuck jobs."

---

Phase 2 — EVALUATE termination

Parse script output using this exact decision table — evaluate in order:

CI_STATE	FINDING lines present?	Action
SUCCESS	No	Exit: Success
SUCCESS	Yes	Proceed to Phase 3
FAILURE	Either	Proceed to Phase 3
ERROR	Either	Proceed to Phase 3
UNKNOWN	Either	Return to Phase 1 (transient — treat as pending)

CI_STATE=SUCCESS alone is NOT sufficient to exit — zero FINDING lines are also required.

---

Phase 3 — CLASSIFY findings

FINDING lines have the format:

FINDING source=<bot> file="<path>" line=<line> comment=<text>

The file= value is always double-quoted (strip the outer quotes when reading it). This handles file paths that contain spaces.

Note on issues/comments staleness: Findings from the PR conversation thread (issues/comments) cannot be filtered by commit — that API provides no original_commit_id field. These findings may include bot comments from previous commits. Treat an issues/comments finding with an empty file= and line= as a potential staleness indicator; apply extra scrutiny before classifying as CONFIDENT_FIX.

For each FINDING line, classify as CONFIDENT_FIX or ESCALATE:

CONFIDENT_FIX (all of the following must be true):

• Finding has a specific file= and line= reference
• Fix is local to that file — explicitly verify before classifying: (1) no other files import or call the changed symbol, (2) no tests outside this file reference it, (3) the change does not affect a shared interface or type
• Finding falls into a known pattern:
  • Lint or style error
  • Type error or missing type annotation
  • Missing null/undefined check
  • Unused import or variable
  • Test assertion mismatch with clear expected value

ESCALATE (any of the following):

• Finding is architectural ("this approach should be reconsidered")
• Finding touches a security-critical path:
  • Files matching: **/auth/**, **/jwt/**, **/password/**, **/session/**, **/payment/**, **/billing/**, **/db/**, **/migrations/**, **/crypto/**, **/secrets/**
• Finding references behavior not introduced by this branch
• Root cause is ambiguous (no specific file/line, or conflicting signals)
• Two findings appear to conflict with each other
• CI_STATE=ERROR (infrastructure failure, not code failure)

If ANY finding is ESCALATE: stop. Do NOT apply any fixes. Go to Exit: Escalate.

If ALL findings are CONFIDENT_FIX: proceed to Phase 4.

---

Phase 4 — FIX

Apply edits for each confident finding. Keep changes minimal — fix exactly what the finding describes, nothing more.

After all edits:

git diff HEAD

Review the diff briefly. If the diff is larger than expected or touches files not referenced in findings, treat as ESCALATE.

---

Phase 5 — COMMIT

git add <only the files you changed>
git commit -m "fix: address <summary of findings>

Post-push loop iteration N: <list of findings addressed>"

Note: the pre-commit hook will run automatically. If it blocks the commit, treat as Exit: Escalate — surface both the hook finding and the remote finding.

Environment for push: set POSTPUSH_LOOP=1 to bypass the Protocol 4 interactive prompt.

---

Phase 6 — PUSH

POSTPUSH_LOOP=1 git push

Return to Phase 1.

---

Exit: Success

✅ POST-PUSH LOOP COMPLETE

PR #NNN | N iterations
CI state: SUCCESS
Unresolved bot findings: 0

Commits pushed:
  <list of commit hashes + messages>

Exit: Escalate

⚠️  LOOP PAUSED — Human decision required

PR #NNN | Iteration N | CI: <state>

FINDING(S) requiring your input:
  [For each finding]
  Source: <bot>
  File:   <path>:<line>
  Comment: <text>
  Reason escalated: <reason>

CONTEXT:
  Fixes applied this session: <list or "none">
  Local review at last commit: passed / blocked
  Current CI state: <state>

OPTIONS:
  1. Provide direction here → I resume with your guidance
  2. Take over manually → type "take over" to exit loop
  3. Abandon → type "abandon" to exit, leave branch as-is

Await human response. Do not proceed autonomously.

---

Hard Constraints

• Never exit with "clean" status based on your own assertion — only based on CI_STATE=SUCCESS AND no FINDING lines from the status script.
• Never apply fixes when any finding is classified ESCALATE.
• Never use --no-verify on any git command.
• Never push to main.
• Set POSTPUSH_LOOP=1 on every git push call within this skill.
• Never exceed 5 push iterations in a single loop session. After 5 iterations, escalate with reason "Iteration limit reached — autonomous loop terminated to prevent unbounded cost."