auto-continue-pr-loop

name

auto-continue-pr-loop

description

Advanced `auto-continue-pr` workflow for PRs started by `auto-create-pr-loop`. Claims the PR, re-enters an isolated worktree, resumes from the first non-done row in `.ai/runs/<date>-<slug>/PLAN.md`, executes lean per-step commits, batches verification into `checkpoint-<N>-checks.md` every 5 resumed steps (with focused integration tests + screenshots when UI was touched), runs the full validation gate plus full/standalone integration suites and ds-guardian at spec completion, and preserves the run-folder and label contract. Use the original `auto-continue-pr` for simple `auto-create-pr` runs.

Auto Continue PR (loop)

Resume an auto-create-pr run that did not finish in one go. Given a PR number, you re-enter the same worktree discipline, read HANDOFF.md for session context, parse the top-of-file ## Tasks table in PLAN.md (the authoritative Step-status source), pick up from the first row whose Status is not done, and drive the PR to complete status with lean per-Step commits and checkpoint-batched verification (checkpoint-<N>-checks.md every ~5 resumed Steps, with focused integration tests + screenshots when UI was touched), the same final validation gate plus full/standalone integration suites and a ds-guardian pass at spec completion, and the same label rules as auto-create-pr.

Arguments

• {prNumber} (required) — the PR number to resume (for example 1492).
• --force (optional) — bypass the in-progress concurrency check; use when intentionally taking over a PR that another auto-skill or human already claimed.
• --from <phase.step> (optional) — override the resume point (e.g. 2.1). Only honored when the ## Tasks table (and any legacy ## Progress fallback) cannot be parsed unambiguously.

Workflow

If this is a Simple run, follow the Simple-run contract in step 0a and skip everything from run-folder lookup through NOTIFY ceremony. If this is a Spec-implementation run, proceed with the full workflow below.

0. Claim the PR

Auto-skills MUST NOT clobber each other. Before doing anything else, decide whether you may claim this PR.

CURRENT_USER=$(gh api user --jq '.login')
gh pr view {prNumber} --json assignees,labels,number,title,body,headRefName,baseRefName,isCrossRepository,comments

A PR is considered already in progress when ANY of the following is true:

• It carries the in-progress label.
• It has at least one assignee whose login is not $CURRENT_USER.
• A claim comment newer than 30 minutes exists from another actor (look for the 🤖 start marker).

Decision tree:

State	--force set?	Action
Not in progress	—	Claim and proceed.
In progress, current user owns the lock	—	Treat as re-entry; proceed without re-claiming.
In progress, someone else owns the lock	no	STOP. Ask the user via AskUserQuestion: "PR #{prNumber} is in progress (owner: {owner}, signal: {label/assignee/comment}). Override and continue?" Only continue when the user explicitly says yes.
In progress, someone else owns the lock	yes	Post a force-override comment naming the previous owner, then claim and proceed.

Stale lock recovery:

• If the in-progress label is older than 60 minutes and the assignee did not push or comment in that window, treat it as expired. Still ask the user before overriding unless --force was set.

Claim the PR

gh pr edit {prNumber} --add-assignee "$CURRENT_USER"
gh pr edit {prNumber} --add-label "in-progress"
gh pr comment {prNumber} --body "🤖 \`auto-continue-pr\` started by @${CURRENT_USER} at $(date -u +%Y-%m-%dT%H:%M:%SZ). Other auto-skills will skip this PR until the lock is released."

The release step happens at the end of step 9 — the lock MUST be released even on failure. Use a trap/finally so a crash still clears the label and posts a completion comment.

0a. Classify the run before parsing PLAN.md

Now that you hold the lock, decide which mode this resume runs in. The rest of the workflow branches on this choice.

Simple run (default when unsure whether the PR looks simple):

• Bug fix (1–3 files, localized).
• Code-review follow-up (applying review feedback to an existing PR).
• Dependency bump.
• Typo, copy change, or docs tweak.
• Small refactor within one file.
• Linter, i18n, or test-only changes.
• Any PR the user explicitly flags as small ("just a quick fix", "CR follow-up", etc.).

Spec-implementation run:

• Work driven by a file under .ai/specs/ or .ai/specs/enterprise/.
• Multi-phase or multi-workstream tasks (≥3 commits expected).
• New module, new integration provider, new database entity + migration.
• UI surface + API + tests together.
• Anything the user describes with phases, workstreams, or deliverables.
• Any existing auto-create-pr run that already has a .ai/runs/<date>-<slug>/ folder.

Classification heuristic — evaluate in order, first match wins:

1. Is there a linked spec (.ai/specs/...) or an existing .ai/runs/<date>-<slug>/ folder referenced from the PR body? → Spec-implementation run.
2. Did the user describe the task in terms of phases / steps / deliverables? → Spec-implementation run.
3. Does the task clearly span >5 files or >1 package AND introduce new contract surface (new route, new entity, new event ID, new DI name, new ACL feature)? → Spec-implementation run.
4. Otherwise → Simple run.

When in doubt: default to Simple run. It is cheaper to promote a Simple run to a Spec-implementation run mid-flight (by drafting a plan then) than to over-engineer a typo fix.

Never demote a Spec-implementation run to a Simple run.

Simple-run contract

For Simple runs, skip the whole run-folder ceremony. Requirements:

• No run folder, no PLAN.md, no HANDOFF.md, no NOTIFY.md, no step-<X.Y>-checks.md.
• No Tasks table anywhere.
• One code commit pushed to the PR branch (may be amended pre-push; once pushed, create a new commit rather than amending).
• Unit tests for behavior changes (still mandatory for code; docs-only exempt).
• Targeted validation for the touched package(s) only (typecheck + unit tests; i18n if strings changed).
• Conventional-commit subject.
• Push the fix directly to the PR branch.
• PR body stays short — summary + test plan + rollback (no Tracking plan: line, no Status: field, no linked run folder). If the existing body already has these tracking fields from a prior promotion, leave them; otherwise do not add them.
• Still respect: three-signal in-progress lock (already claimed in step 0), label discipline (pipeline + category + meta), BC contract surfaces, code-review self-check, auto-review-pr pass.
• Final summary comment still posts, but compacted to: summary of changes, how to verify, what can go wrong. No "Verification phases" matrix, no "External references honored" section unless actually relevant.

A Simple run still uses an isolated worktree (skip straight to step 2 for worktree setup), still runs auto-review-pr in autofix mode, and still releases the lock per step 9.

Spec-implementation-run contract

Keep the full contract documented in the rest of this file: run-folder lookup, HANDOFF.md → Tasks table → NOTIFY tail orientation, per-Step step-<X.Y>-checks.md, 1:1 step-to-commit discipline, full validation gate before flipping to complete, auto-review-pr autofix pass, comprehensive summary comment with all headings.

Promotion path (Simple → Spec-implementation)

A Simple run MAY be promoted to a Spec-implementation run mid-flight if the resume discovers the remaining work is larger than it looked:

• Stop the simple flow.
• Draft the plan under .ai/runs/<date>-<slug>/PLAN.md (with Tasks table), HANDOFF.md, NOTIFY.md.
• Write a seed commit that adds these files.
• Update the PR body to add Tracking plan: and Status: in-progress lines.
• Continue under the full Spec-implementation contract from step 1 onwards.

1. Locate the run folder

Prefer the explicit Tracking plan: line in the PR body (written by auto-create-pr):

gh pr view {prNumber} --json body --jq '.body' | grep -E '^Tracking (plan|run folder):' | head -n1

Expected value (current format): Tracking plan: .ai/runs/<date>-<slug>/PLAN.md.

Fallbacks, in order:

1. Tracking run folder: .ai/runs/<date>-<slug>/ — derive PLAN_PATH as ${folder}/PLAN.md.
2. Legacy flat-file format: Tracking plan: .ai/runs/<date>-<slug>.md — still honored for PRs opened before the folder migration. In this case there is no run folder yet; create one at .ai/runs/<date>-<slug>/, move the flat plan into it as PLAN.md, and initialize HANDOFF.md and NOTIFY.md as part of this resume's first commit.
3. Legacy Tracking spec: line (older runs) — treat the same way as the legacy flat-file format.
4. Diff the PR against origin/develop and look for a new path under .ai/runs/ authored by this branch. If exactly one new plan exists (folder or flat file), use it.
5. Legacy fallback: if nothing under .ai/runs/ is found, look for a new file under .ai/specs/ or .ai/specs/enterprise/ (for PRs created before the .ai/runs/ migration). Migrate it into a new run folder as above.
6. If multiple candidates were found, stop and ask the user via AskUserQuestion which one to resume.
7. If no tracking plan can be resolved, stop with a clear error. Do NOT invent a plan path.

Record the resolved paths:

RUN_DIR=".ai/runs/<date>-<slug>"
PLAN_PATH="${RUN_DIR}/PLAN.md"
HANDOFF_PATH="${RUN_DIR}/HANDOFF.md"
NOTIFY_PATH="${RUN_DIR}/NOTIFY.md"
# Verification is checkpoint-based: ${RUN_DIR}/checkpoint-<N>-checks.md every ~5 Steps.
# Optional artifacts (Playwright, screenshots) live at ${RUN_DIR}/checkpoint-<N>-artifacts/.
# Final gate log lives at ${RUN_DIR}/final-gate-checks.md at spec completion.

2. Create an isolated worktree from the PR head

Never resume in the user's primary worktree.

REPO_ROOT=$(git rev-parse --show-toplevel)
GIT_DIR=$(git rev-parse --git-dir)
GIT_COMMON_DIR=$(git rev-parse --git-common-dir)
WORKTREE_PARENT="$REPO_ROOT/.ai/tmp/auto-continue-pr"
CREATED_WORKTREE=0

HEAD_REF=$(gh pr view {prNumber} --json headRefName --jq '.headRefName')
IS_CROSS=$(gh pr view {prNumber} --json isCrossRepository --jq '.isCrossRepository')

if [ "$GIT_DIR" != "$GIT_COMMON_DIR" ]; then
  WORKTREE_DIR="$PWD"
else
  WORKTREE_DIR="$WORKTREE_PARENT/pr-{prNumber}-$(date +%Y%m%d-%H%M%S)"
  mkdir -p "$WORKTREE_PARENT"
  if [ "$IS_CROSS" = "true" ]; then
    gh pr checkout {prNumber} --recurse-submodules=no
    git worktree add --detach "$WORKTREE_DIR" "HEAD"
  else
    git fetch origin "$HEAD_REF"
    git worktree add "$WORKTREE_DIR" "origin/$HEAD_REF"
  fi
  CREATED_WORKTREE=1
fi

cd "$WORKTREE_DIR"
yarn install --mode=skip-build

Rules:

• Reuse the current linked worktree when already inside one. Never nest worktrees.
• The main worktree must stay untouched.
• Always clean up the temporary worktree at the end, but only if you created it this run.

Cleanup (in a trap/finally):

cd "$REPO_ROOT"
if [ "$CREATED_WORKTREE" = "1" ]; then
  git worktree remove --force "$WORKTREE_DIR"
fi
git worktree prune

3. Orient via HANDOFF.md, then parse PLAN.md's Tasks table

Read HANDOFF.md first. It is the authoritative short-form snapshot of what the previous agent (or this agent's previous session) was doing. It tells you:

• The current phase/step.
• The last commit SHA and what it delivered.
• The next concrete action.
• Open blockers, environment caveats, and worktree details.

Then open PLAN.md and find the ## Tasks table at the top of the file. It is a markdown table with exactly these columns: Phase, Step, Title, Status, Commit. Example shape written by auto-create-pr:

## Tasks

> Authoritative status table. `Status` is one of `todo` or `done`. On landing a Step, flip `Status` to `done` and fill the `Commit` column with the short SHA. The first row whose `Status` is not `done` is the resume point for `auto-continue-pr`. Step ids are immutable once a Step has a commit.

| Phase | Step | Title | Status | Commit |
|-------|------|-------|--------|--------|
| 1 | 1.1 | {step title} | done | abc1234 |
| 1 | 1.2 | {step title} | done | def5678 |
| 2 | 2.1 | {step title} | todo | — |
| 2 | 2.2 | {step title} | todo | — |

Parse rules:

• The first row whose Status column is not done is the resume point. Status values are todo or done only.
• The Step id comes from the Step column (X.Y or X.Y-review-fix). That id drives the Step commit, the step-<X.Y>-checks.md filename, and any step-<X.Y>-artifacts/ folder.
• Title is informational and must match the Step title in the Implementation Plan section; if it drifts, trust the Implementation Plan title and fix the table.
• If HANDOFF.md names a different resume point than the table implies, trust HANDOFF.md and reconcile the table (a previous session may have crashed mid-Step). Log the reconciliation in NOTIFY.md.
• If the ## Tasks table is missing, fall back to a legacy ## Progress checkbox section (PRs opened before the table migration used checkboxes — first - [ ] is the resume point). When you hit a legacy Progress section, migrate it to a Tasks table as part of the resume's first commit.
• If neither the table nor a legacy Progress section can be parsed, stop and ask the user — unless --from <phase.step> was passed, in which case use that as the resume point and log a note in NOTIFY.md.
• Cross-check the most recent done row's Commit SHA against git log on the PR head. If the recorded SHA is not reachable, warn the user and ask whether to continue (or accept --force).
• Skim the tail of NOTIFY.md (e.g. last 30 entries) for recent blockers or decisions so you do not repeat or contradict prior work.

Append a NOTIFY entry announcing the resume:

## <UTC ISO-8601 timestamp> — auto-continue-pr resume
- Resumed by: @<current-user>
- Resume point: <phase.step> (source: HANDOFF.md / Tasks table / legacy Progress / --from)
- PR head SHA: <sha>

4. Resume execution — lean per-Step loop + checkpoint pass every 5 Steps

From the resume point forward, apply the same lean/checkpoint pattern documented in .ai/skills/auto-create-pr-loop/SKILL.md step 6.

4a. Per-Step loop (lean, no per-Step chatter)

One Step = one code commit. Nothing more.

1. Implement only the work described by the current Step.
2. Add or update tests for anything that changed behavior. Unit tests mandatory for code changes; escalate to integration tests for risky flows, permissions, tenant isolation, workflows, or multi-module behavior.
3. Run a quick scratch sanity check (typecheck + new test file) to confirm the Step compiles. Do NOT record this anywhere — checkpoints verify.
4. Re-read the diff to remove scope creep.
5. Grep changed non-test files for raw em.findOne( / em.find( and replace with findOneWithDecryption / findWithDecryption.
6. Flip the Tasks-table row in the same commit. In PLAN.md's ## Tasks table, flip the Step's Status cell from todo to done and fill the Commit column with the short SHA (amend the commit to capture the real SHA before pushing).
7. Commit with a conventional-commit message for that single Step. No separate docs-flip commit.
8. Push after the commit so the remote always has the latest state.
9. Do NOT write a step-<X.Y>-checks.md. Do NOT create a step-<X.Y>-artifacts/ folder. Do NOT rewrite HANDOFF.md at the per-Step level. Do NOT append to NOTIFY.md unless the Step produced a blocker, a scope decision, or a subagent delegation.

Do not alter work already completed in earlier commits. Do not reorder or rewrite history on the PR branch.

4b. Checkpoint pass (every 5 resumed Steps)

Fire when any of these is true:

• 5 Steps have landed since the start of this resume (or since the last checkpoint in this resume).
• The next Step would close a Phase and the Phase has ≥3 Steps.
• Every row in the Tasks table is now done — the final gate in step 5 subsumes this.
• A blocker stops the run mid-Phase.

At a checkpoint, run the following and record them in a single ${RUN_DIR}/checkpoint-<N>-checks.md (use the next available <N> — increment from the highest existing checkpoint number on the branch):

1. Targeted validation for every package touched since the last checkpoint:
   • yarn typecheck (scoped when feasible).
   • yarn test (scoped to affected packages).
   • yarn i18n:check-sync and yarn i18n:check-usage if any locale file or user-facing string was changed in the window.
   • yarn generate, yarn build:packages, and yarn db:generate when module structure, entities, or generated files changed.
2. UI verification (conditional) — if any Step in the window touched UI (frontend pages, backend pages, portal pages, widgets, *.tsx, UI components, navigation injection):
   • Run the smallest set of integration tests under .ai/qa/tests/ that covers the touched areas (e.g. yarn test:integration .ai/qa/tests/admin/customers, .ai/qa/tests/crm, .ai/qa/tests/catalog, .ai/qa/tests/sales, .ai/qa/tests/api). Prefer folder-scoped over the full Playwright suite.
   • If no existing file covers the touched area, fall back to Playwright MCP tools (mcp__plugin_playwright_playwright__*) for a minimal smoke path.
   • Create ${RUN_DIR}/checkpoint-<N>-artifacts/ and save playwright.log + at least one screenshot-<short-desc>.png per touched area. Reference filenames from checkpoint-<N>-checks.md.
   • UI checks MUST NEVER block development. If the dev env cannot be started or the scenario is not reachable, skip the UI portion and record the reason in both checkpoint-<N>-checks.md and NOTIFY.md. The checkpoint otherwise proceeds.
3. Write checkpoint-<N>-checks.md listing: checkpoint index, the Steps it covers (id range + SHA range), touched packages, every check run with pass/fail/skip + reason, and links to any artifacts.
4. Rewrite HANDOFF.md from scratch with the new state (next concrete action = the first remaining todo Step).
5. Append one NOTIFY entry for the checkpoint: UTC timestamp, checkpoint index, Step range, one-line summary, any decisions/problems.
6. Commit the checkpoint files (checkpoint-<N>-checks.md, if any, , ) as a single commit: . Push.

If the checkpoint fails, halt dispatch, rewrite HANDOFF.md naming the failure, append a NOTIFY blocker entry, fix forward with new Steps appended to the Tasks table, and re-run the checkpoint before continuing.

Subagent parallelism (optional, capped at 2):

• At your discretion, you MAY run up to two subagents concurrently — for example, one implementing the next Step while a second reviews the just-landed commit via the code-review skill. Never exceed two.
• Conflict avoidance is the top priority. Two agents MUST NOT edit the same files in the same window. If conflicts are likely, serialize.
• Prefer serial execution whenever the gain is marginal. Parallelism is a tool, not a default.
• Record any subagent delegation in NOTIFY.md with timestamps.

Multi-Step runs: executor-dispatch pattern

Applies only to Spec-implementation runs. Simple runs have at most one code commit and do not use executor dispatch.

When a single /auto-continue-pr invocation is expected to land multiple Steps in one pass, the main session SHOULD act as a dispatcher and spawn one executor subagent per Step (foreground Agent tool call, subagent_type: "general-purpose"). The executor implements exactly that Step end-to-end (code commit + docs-flip commit + push). The main session waits for the executor to return, verifies the commits landed and pushed, then dispatches the next Step.

When to use this pattern:

• A /auto-continue-pr resume whose Tasks table has multiple todo rows that must all land in one pass.
• A long-running run where the main session would otherwise carry heavy per-Step context across many Steps.

When NOT to use it:

• A single-Step resume. Drive the Step directly in the main session — the default per-Step loop above is correct.
• Docs-only or trivial resumes.

Hard constraints:

• Subagents do NOT have access to the Agent tool. A coordinator subagent cannot spawn executors. Dispatch MUST live in the main session.
• Dispatch is sequential (one executor at a time). This is not parallelism — the cap-at-2 rule above still applies to the rare case where you want an implementer and a reviewer running side-by-side; an executor-dispatch run is a sequence of one-at-a-time executors.
• The main session claims the in-progress lock once at step 0 and releases it once at step 9 (or on early exit). Executors MUST NOT claim or release the lock.
• The main session posts the final summary comment (step 8) at the end. Executors MUST NOT post the final summary.

Executor prompt template — the main session writes this into each spawned Agent call:

You are an executor for auto-continue-pr PR #{prNumber}. Implement exactly one Step.

Working directory: {absolute worktree path}
Branch: {branch} (already checked out; origin tracking set up)
Run folder: {absolute run folder path}

Step to implement:
- Step id: {X.Y}
- Title: {step title from Tasks table}
- Full description: {paste the Step's bullets from PLAN.md Implementation Plan}

Spec anchors:
- PLAN.md: {plan path}
- Source spec (if any): {spec path}
- External References adopted: {list from PLAN.md Overview}

Rules:
- One Step = exactly one code commit. Nothing more, nothing less. No docs-flip commit.
- Run a quick scratch sanity check (typecheck + new test). Do NOT record it anywhere — the checkpoint pass verifies.
- Do NOT write a `step-{X.Y}-checks.md`. Do NOT create a `step-{X.Y}-artifacts/` folder. Verification is checkpoint-based.
- Flip the `Status` cell of row `{X.Y}` in PLAN.md's Tasks table from `todo` to `done` and fill the `Commit` column with the short SHA as part of the same commit (amend if needed to capture the real SHA before push).
- Do NOT rewrite `HANDOFF.md` at the per-Step level. Do NOT append to `NOTIFY.md` unless you hit a blocker, make a scope decision worth logging, or are delegating to another subagent.
- Push after the commit so the remote always has the latest state.
- Do NOT claim or release the `in-progress` lock on the PR. The main session already owns it.
- Do NOT post the final summary PR comment. The main session posts it at the end.
- Do NOT rewrite or reorder prior history. Do NOT split into multiple code commits. If this Step truly needs splitting, stop and return early with a report asking the main session to split the Step in PLAN.md first.

Return format (concise report, < 300 words):
- Step id
- Code commit SHA
- Files touched
- Brief note on what changed (one line)
- Push confirmation (`origin/{branch}` now at {sha})
- Blockers or decisions worth escalating

Verification the main session MUST run after each executor returns — before dispatching the next Step:

• git status is clean in the worktree.
• Exactly one new commit exists on HEAD since the dispatch.
• Local HEAD == origin/{branch} (push actually landed; fetch if in doubt).
• The PLAN.md Tasks-table row for {X.Y} is flipped to done with the correct short SHA in the Commit column.

Every 5 successful executors (or when a Phase with ≥3 Steps closes), the main session MUST run a checkpoint pass per step 4b before dispatching the next Step: targeted validation for all packages touched in the window, focused integration tests + screenshots when UI was touched, write checkpoint-<N>-checks.md, rewrite HANDOFF.md, append the checkpoint entry to NOTIFY.md, and commit as docs(runs): checkpoint N — steps X.Y..X.Z verified.

Safety stops — the main session MUST halt dispatch (leave Status: in-progress, rewrite HANDOFF.md, append a NOTIFY entry naming the blocker, release the lock per step 9, and report back) when any of the following is true:

• An executor returns a blocker, failing tests, or an error.
• git status is not clean after an executor returns.
• The Tasks-table row was not flipped to done with the correct SHA.
• Local HEAD ≠ origin/{branch} (push did not land).
• Two consecutive executors returned problematic results.
• Safety checkpoint: after ~20 consecutive successful Steps, stop and let the user review before plowing on.

Sibling auto-skills (auto-create-pr, auto-sec-report, auto-qa-scenarios, auto-update-changelog) inherit this pattern when driving multiple Steps in a single invocation.

5. Final gate before flipping to complete (spec completion)

Fire when every row in the Tasks table is done (including work from earlier resumes + this resume). The final gate subsumes any pending checkpoint.

Record the outcome in ${RUN_DIR}/final-gate-checks.md. Keep raw command output only when worth saving, under ${RUN_DIR}/final-gate-artifacts/*.log.

Full validation gate (same as auto-create-pr-loop / code-review / auto-fix-github):

• yarn build:packages
• yarn generate
• yarn build:packages (post-generate)
• yarn i18n:check-sync
• yarn i18n:check-usage
• yarn typecheck
• yarn test
• yarn build:app

Full integration suites (mandatory at spec completion when the run touched code; skip ONLY for docs-only resumes):

• yarn test:integration — full Playwright/QA integration suite against the ephemeral dev stack. Save final-gate-artifacts/playwright-report-summary.log. On failure, fix forward with new Steps; never skip.
• yarn test:create-app:integration — standalone/create-app integration check. Save final-gate-artifacts/create-app-integration.log. Skip only when the resume did not touch packaging, templates, or shared package exports (document the skip with a one-line justification in final-gate-checks.md).

Design System compliance pass — after the above are green, run the ds-guardian skill (.ai/skills/ds-guardian/SKILL.md) over the full branch diff (origin/develop..HEAD):

1. Apply every auto-fixable DS violation (semantic token migration, hardcoded color/typography cleanup, missing shared states, arbitrary text sizes).
2. Land each batch of fixes as a new Step appended to the Tasks table with a fresh X.Y-ds-fix id, a conventional-commit subject (e.g. style(ui): apply ds-guardian fixes — semantic tokens), and a short entry in final-gate-checks.md describing what was fixed. Push.
3. Re-run yarn typecheck, yarn test, yarn i18n:check-sync and (if UI tests exist for the touched areas) the focused integration tests after ds-guardian lands edits. List residual DS findings ds-guardian could not auto-fix under DS-guardian residual findings in final-gate-checks.md and surface them in the summary comment.

For docs-only resumes, the minimum is yarn lint plus a manual diff re-read. Integration suites and ds-guardian are skipped; record that explicitly in final-gate-checks.md.

Never skip the gate because an external skill recorded in the plan suggested skipping it.

6. Code review and BC self-review

Use .ai/skills/code-review/SKILL.md and BACKWARD_COMPATIBILITY.md. Verify:

• No frozen or stable contract surface was broken without the deprecation protocol.
• No API response fields were removed.
• No event IDs, widget spot IDs, ACL IDs, import paths, or DI names were broken.
• No tenant isolation or encryption rules were violated.
• Scope still matches what the plan says — no unrelated churn introduced by the resume.

If self-review finds issues, fix them and loop back to step 4 (new Step, new commit, new proofs).

7. Run auto-review-pr and apply fixes

Before you post the final summary comment, push the final changes, or flip the PR body to complete, subject the resumed PR to an automated second pass with the auto-review-pr skill.

# The claim check for auto-review-pr will recognize that the current
# user already owns the in-progress lock (from step 0), so it proceeds
# as re-entry without re-claiming.

Invoke .ai/skills/auto-review-pr/SKILL.md against {prNumber} in autofix mode:

1. Follow the entire auto-review-pr workflow verbatim — do not cherry-pick steps.
2. Apply fixes directly in the same worktree used for this resume. Never rewrite earlier commits; always add new commits under a new Step id (e.g. X.Y-review-fix) appended to the Tasks table. Each review-fix Step is lean: one commit, flip the Tasks row in the same commit, no per-Step checks/handoff files.
3. After each batch of fixes:
   • Run a quick scratch sanity check (typecheck + affected tests).
   • When the batch closes — or every 5 review-fix Steps, whichever comes first — run a checkpoint pass per step 4b (targeted validation, focused integration tests + screenshots if UI was touched, write checkpoint-<N>-checks.md, rewrite HANDOFF.md, append NOTIFY entry, commit as docs(runs): checkpoint N — review fixes).
   • Re-run the full final gate from step 5 whenever a fix touches code outside a single module/test file.
   • Commit each Step using a clear conventional-commit subject (e.g. fix(ui): address review feedback on confirmation dialog focus trap). Push immediately.
4. Loop until auto-review-pr returns a clean verdict or the remaining findings are non-actionable (out-of-scope, false positive) and explicitly documented in the summary comment you post in step 8.

If auto-review-pr cannot run (required checks not yet green, missing context), stop here, leave Status: in-progress in the PR body, update HANDOFF.md + NOTIFY.md with the blocker, and tell the user how to re-enter.

8. Post the comprehensive summary comment

Every resume MUST end with a single, comprehensive summary comment on the PR that captures what this resume changed on top of the previous state. Post it with gh pr comment {prNumber} --body-file ... so multi-line formatting is preserved.

Minimum comment structure:

## 🤖 `auto-continue-pr` — resume summary

**Tracking plan:** {plan path}
**Run folder:** {run folder path}
**Branch:** {branch}
**Resume point:** {phase.step} → {last step reached in this resume}
**Final status:** {complete | still in-progress — re-run /auto-continue-pr {prNumber}}

### Summary of changes in this resume
- {step-level bullet 1}
- {step-level bullet 2}
- {files/modules touched during this resume only}

### External references honored
- {reminder of URLs already recorded in the plan's External References, plus anything newly consulted during this resume, with adopt/reject notes}  <!-- omit section if none -->

### Verification phases completed (this resume)
- **Checkpoint verification (every ~5 Steps in this resume):** `{run-folder}/checkpoint-<N>-checks.md` with optional `checkpoint-<N>-artifacts/` (Playwright transcripts + screenshots when UI was touched in the window).
- **Per-checkpoint validation:** {which packages ran typecheck / unit tests / i18n / generate / build at each checkpoint}
- **Focused integration tests per checkpoint (UI-touched windows):** {which `.ai/qa/tests/...` folders were exercised, screenshots captured}
- **Full validation gate (at spec completion):** {yarn build:packages ✓, yarn generate ✓, yarn i18n:check-sync ✓, yarn i18n:check-usage ✓, yarn typecheck ✓, yarn test ✓, yarn build:app ✓ — or explicit blocker}
- **Full integration suite:** {yarn test:integration ✓ / ✗ — summary + link to HTML report}
- **Standalone integration:** {yarn test:create-app:integration ✓ / ✗ / skipped with reason}
- **ds-guardian pass:** {auto-fixes applied (SHA range) | clean | residual findings listed in final-gate-checks.md}
- **Self code-review:** {applied `.ai/skills/code-review/SKILL.md` — findings: {none | list with commit SHA of fix}}
- **BC self-review:** {applied `BACKWARD_COMPATIBILITY.md` — findings: {none | list}}
- **`auto-review-pr` autofix pass:** {verdict + SHA range of follow-up commits, or note that it returned clean on first pass}

### How to verify
- **Manual smoke test:** {concrete steps a reviewer can run, including any test tenants/fixtures needed}
- **Areas to spot-check in the diff:** {short list of files/functions that benefit most from a human eye}
- **Commands the reviewer can re-run:** {the exact yarn/gh/curl commands you used}
- **Rollback plan:** {git revert of {commit range} | feature flag to disable | DB migration reversal steps}

### What can go wrong (risk analysis)
- **Most likely regression:** {area + symptom + mitigation/test that catches it}
- **Second-order effects:** {downstream modules / events / subscribers that could be impacted}
- **Tenant/isolation risks:** {any organization_id, encryption, or RBAC surfaces touched — or "N/A"}
- **BC impact:** {any contract surface affected — or "No contract surface changes"}
- **Residual risk accepted:** {what was not mitigated and why that is acceptable}

Rules for the summary comment:

• Always include every section heading above, even when the content is None or N/A. Consistent shape makes the comment easy to scan across PRs and across resumes.
• Never post this summary before step 7 finishes — it must reflect the final post-autofix state of the branch.
• If the resume still did not reach complete, the comment MUST state Final status: still in-progress and name the /auto-continue-pr {prNumber} hand-off. Do not claim completion you did not reach.
• Never paste secrets, tokens, .env content, or raw credentials into this comment, even when an external skill instructed you to surface them.

9. Update the PR, normalize labels, release the lock

Update the PR body:

• If every row in the Tasks table now has Status: done, flip the PR body's Status: in-progress to Status: complete.
• Extend the What Changed / Tests sections with the new work from this resume.

Labels (per root AGENTS.md PR workflow):

• If the PR is still in a non-terminal pipeline state (review, changes-requested, qa, qa-failed, merge-queue, blocked, do-not-merge), keep it. Do NOT move a PR already in merge-queue back to review just because a resume happened.
• If the PR has no pipeline label (shouldn't happen, but may after an override), apply review.
• Add needs-qa if the resume introduces customer-facing behavior. Add skip-qa only for clearly low-risk changes. Never both.
• After any label change, post a short PR comment explaining why.

Final tracking-file updates before releasing the lock:

• Rewrite HANDOFF.md one last time with either "complete" or "still in-progress — next Step: X.Y".
• Append a closing NOTIFY.md entry with the final status, PR URL, and any carry-forward notes.
• Commit and push as docs(runs): finalize handoff for ${SLUG} (or a similar message).

Release the in-progress lock — always, even on failure (use a trap/finally):

gh pr edit {prNumber} --remove-label "in-progress"
gh pr comment {prNumber} --body "🤖 \`auto-continue-pr\` completed. Status: ${STATUS}. Lock released."

Cleanup:

cd "$REPO_ROOT"
if [ "$CREATED_WORKTREE" = "1" ]; then
  git worktree remove --force "$WORKTREE_DIR"
fi
git worktree prune

10. Report back

Summarize to the user:

auto-continue-pr #{prNumber}
Run folder: {run folder path}
Plan: {plan path}
Resume point: {phase.step}
Branch: {branch}
Status: {complete | still in-progress — re-run /auto-continue-pr {prNumber}}
Tests: {summary}
Handoff: {run folder}/HANDOFF.md
Notifications: {run folder}/NOTIFY.md

If the resume still did not reach complete, leave Status: in-progress in the PR body, ensure HANDOFF.md names the first unchecked Step, and tell the user how to re-enter.

Rules

• Always run the step 0 claim check before any other action; never silently override another actor's lock.
• Always release the in-progress lock on the PR at the end, even if the run fails or is aborted (use a trap/finally).
• Always use an isolated worktree; reuse the current linked worktree when already inside one; never nest worktrees.
• Resolve the run folder from the PR body's Tracking plan: / Tracking run folder: line; fall back to the legacy flat-file format (.ai/runs/<date>-<slug>.md), then legacy Tracking spec:, then diff inspection; never invent a plan path. When you hit a legacy format, migrate it into a per-spec folder (create HANDOFF.md and NOTIFY.md) as part of this resume's first commit.
• Always read HANDOFF.md first, then PLAN.md's top-of-file ## Tasks table, then the tail of NOTIFY.md, before touching any code.
• Resume from the first row in the Tasks table whose Status is not done (or what HANDOFF.md says, whichever is fresher). Fall back to a legacy ## Progress checkbox section for pre-migration PRs and migrate it to a Tasks table on the first resume commit. Honor --from only when parsing fails.
• Do not rewrite history on the PR branch. Do not alter earlier commits' behavior.
• Every Step is 1:1 with a commit. If you need more than one commit for a Step, split the Step in PLAN.md first, then proceed.
• Every new code change MUST include tests; docs-only changes are exempt from the unit-test rule but still run relevant lint/checks.
• checkpoint-<N>-checks.md MUST exist for every checkpoint (every ~5 Steps, or when a Phase with ≥3 Steps closes) and record the outcome of the checkpoint's targeted validation (typecheck + unit tests + i18n + generate + build as applicable) plus focused integration tests when UI was touched in the window. checkpoint-<N>-artifacts/ is optional and only created when the checkpoint produced real artifacts. Playwright + screenshots MUST be captured at the checkpoint when any Step in the window touched UI AND the dev env is runnable; when not runnable, skip them and log the reason in both checkpoint-<N>-checks.md and NOTIFY.md. UI verification MUST NEVER block development.
• No per-Step step-<X.Y>-checks.md, no per-Step , no per-Step HANDOFF rewrite, no per-Step NOTIFY append. Per-Step commits update only the Tasks table row. Verification ceremony is batched into checkpoints.