Execute AFlow Checkpoint

Use this skill only for checkpoint-scoped aflow execution. Treat aflow as the canonical spelling. This skill is intentionally lightweight, and the plan itself should already carry the detailed checkpoint contract.

The plan file is the source of truth. Do not rely on chat memory when the plan, repository state, test output, or git history disagree.

Test and command completion

• Prefer foreground commands and the execution tool's process/session handle.
  Read the command's actual exit status and bounded output before deciding to
  wait, retry, or report success. A launcher exit or a successful tail is not
  the test result; preserve the tested command's status when piping output.
• If background execution is necessary, retain the exact child handle/PID and
  collect its exit status (wait "$child_pid" only from its owning shell).
  Across tool calls, use a supported persistent session or an owned completion
  receipt tied to that invocation; a vanished PID alone does not prove success.
• Never use broad pgrep -f command-text matching to decide whether your test
  finished: it can match the polling shell itself or another run. Do not use
  fixed long sleeps or detached nohup polling in place of child completion.
• Use only timeout options supported by the installed runner. A usage error
  means the command already failed; diagnose it immediately. Prefer an existing
  execution-tool timeout or a verified platform timeout wrapper when needed.
• Once required checks have finished, record the result and continue the
  handoff. Do not rerun matching successful checks merely to fill a wait.
  A whole-harness exclusive resource remains occupied during shell/test waits;
  never manually release its lease while the harness can still issue requests.

Storage and evidence hygiene

• Before heavy writes for this checkpoint, measure free bytes and inodes and, where applicable, backing capacity; compare against the plan's stated peak allocation and reserve.
• Serialize heavy campaigns through the environment's shared lock; do not start a parallel heavy campaign that the lock exists to prevent.
• If space is low, do not immediately AFLOW_STOP: inspect bounded category usage, reuse valid caches and artifacts, and remove only known disposable owned intermediates (or native-manager unused caches) within authorization. Rerun the capacity check and continue in the same attempt.
• Honor installed native cleanup helpers where available; do not invent destructive recovery, expand disks, or delete other owners' data.
• Never delete active work, unique data, retained base or release images, models, session history, AFlow lineage, or proofs required for unresolved failures.
• If no safe recovery suffices, report the actual free space, the conservative required peak/reserve, the actions tried, and the concrete remaining external decision.
• Keep primary logs, exact commands and results, revision/dirty fingerprints, and hashes inspectable. Bound verbose logs and captures at production. Select compact useful evidence; make no per-review copies or repeated full captures.
• Clean per-case QEMU writable disks after guest exit/unmount and successful evidence extraction; retain failed or unique images until diagnosed. This checkpoint may dispose of scratch it explicitly created as disposable, never inherited operation directories simply because they are old.
• Reuse valid prior verification and caches; do not run clean builds or full suites merely because a new checkpoint or reviewer started.

Plan Shape

• If the active plan is the original handoff plan with checkpoint headings, execute exactly one checkpoint from it.
• If the active plan is a review-generated non-checkpoint follow-up plan, execute that focused plan fully, verify it, and stop.
• Do not invent checkpoint structure in a review-generated non-checkpoint plan.

Core Rules

• Execute exactly one checkpoint.
• Work on the first unchecked checkpoint unless the prompt explicitly names a different checkpoint.
• Re-read the plan from disk before acting on the checkpoint and again after verification.
• Treat the on-disk plan as the source of truth for checkpoint scope, verification, and commit boundaries.
• For checkpointed plans, treat step checkboxes as required workflow state, not optional notes.
• For checkpointed plans, after implementation and checkpoint-level verification pass, validate each step in the target checkpoint one by one against the actual code, tests, and observable behavior before checking it off.
• Do not check off a step just because the checkpoint appears complete overall. Each step must be explicitly confirmed.
• Do not mark a checkpoint complete before every step in that checkpoint has been individually validated and checked off, and the required verification still passes.
• Treat a top-level ## User Acceptance Pending section after the checkpoints as handoff information, not executable work. Do not check it off or retry the worker for pending owner-only checks; implementation defects and required automated verification failures remain blocking.
• Do not create checkpoint commits, final approval commits, squash commits, or review-bookkeeping commits. Reviewer workflows own all commit creation and approval-grade git bookkeeping.
• Do not hide verified checkpoint work behind stale plan state or ambiguous git state.
• Stop after the target checkpoint is implemented and verified, even if the original plan still has more unchecked checkpoints.
• Stop and escalate when the plan is ambiguous, contradictory, unsafe, or buried under unrelated dirty changes.

Required Inputs

Following plan paths should be provided by the prompt;

ORIGINAL_PLAN: This is the original implementation plan.
ACTIVE_PLAN: This maybe same as the original plan file, or could be a transient follow-up plan focused on fixing of review findings.

Before acting, identify:

• the active plan file
• whether it is a checkpointed handoff plan or a focused non-checkpoint follow-up plan
• for checkpointed plans, the checkpoint that will be implemented
• any Git Tracking, Dependencies, Verification, Done When, or Stop and Escalate If instructions attached to that checkpoint

If the prompt already names a concrete plan file, use it. If not, discover the single active original plan under plans/in-progress/ when that is unambiguous. If the plan file is missing, multiple candidate plans exist, or the checkpoint cannot be identified safely, stop and ask for clarification.

Execution Loop

• For checkpointed plans:
  • Read the target checkpoint fully before editing code.
  • Implement only that checkpoint's scope.
  • Run the exact verification commands from the plan.
  • If verification passes, re-read the checkpoint steps and validate them one by one in order against the implemented code and verification evidence.
  • Check off only the steps you explicitly validated. If any step is not clearly satisfied, leave it unchecked, fix the implementation, and re-run verification as needed.
  • Check off the checkpoint itself only after every step in that checkpoint is checked and the checkpoint still satisfies its Done When conditions.
  • Only then update the plan state.
  • Leave the verified checkpoint work uncommitted for the reviewer to validate and commit.
  • Stop there, do not move on to the next unchecked checkpoint.
• For review-generated non-checkpoint follow-up plans:
  • Execute the focused plan fully as written.
  • Run the exact verification commands from that plan.
  • If the focused plan uses task-list steps, keep them synchronized with validated progress using the same step-by-step standard.
  • Do not look for or invent checkpoint headings.
  • Stop after that focused follow-up plan is verified and the plan state is synchronized. Do not create approval-grade commits yourself.

Do not use this skill to invent a second execution spec. The plan should already define the checkpoint details, verification, and commit policy.

Git Workflow

• Before stopping, check git status --short, git diff --name-only, and git diff --stat so the reviewer inherits an accurate dirty worktree.
• The dirty worktree must contain only the target checkpoint's scoped changes plus allowed plan progress edits. If unrelated dirty files are present, stop and escalate instead of leaving an ambiguous handoff.
• Leave commit creation, squash/rewrite decisions, fix-plan cleanup, and Git Tracking / Review Log approval bookkeeping to reviewer workflows.
• Do not rewrite history unless the plan explicitly asks for it.

Verification Standard

• Run the exact required verification commands for the active checkpoint.
• Treat the checkpoint as incomplete until those commands succeed.
• After a failure, use small targeted diagnostic reruns to locate the cause, then rerun the required commands affected by the fix. Keep failed or interrupted checks marked as unverified.
• Do not replace required checks with weaker smoke tests.
• Do not add routine broad regression suites to a checkpoint when its plan assigns them to cumulative final review. If an existing explicit full-suite command appears misplaced, report it to the coordinator; run it as written unless the plan is formally revised before the attempt. Never silently substitute a focused check.
• If the plan names observable acceptance criteria in addition to commands, confirm both the commands and the behavior.

Step Validation Standard

• After checkpoint-level verification passes, review every step in the target checkpoint in order.
• For each step, confirm the step's promised outcome is actually implemented, not just partially implied by neighboring work.
• Use concrete evidence for each step such as code inspection, test output, command results, or direct behavioral checks named in the plan.
• Update the plan so the step checkbox state reflects what you validated on disk.
• If a step cannot be confidently validated, treat the checkpoint as still in progress.
• Do not leave a checkpoint checked while any of its steps remain unchecked.

Structural Scope Pressure

After preserving and verifying all safely completed work, emit this exact line
when the checkpoint's agreed meaning is clear but its remaining work is
structurally indivisible or oversized as one reviewable execution scope:

AFLOW_SCOPE_PRESSURE: <concise structural reason>

Scope pressure is advisory evidence for Full manager evaluation. It does not
request a particular split and must not be based on a numeric file/line count.
Do not emit it for normal incompleteness, a failing test that can be fixed in
scope, elapsed time, or a semantic/product decision that needs an owner.

Retain AFLOW_STOP for ambiguity, conflicting requirements, safety or ownership
boundaries, destructive handling of user changes, and other hard blockers that
require human intervention. If both markers would apply, emit only
AFLOW_STOP; it remains terminal.

Stop And Escalate If

• the checkpoint to implement is unclear
• the plan conflicts with the repository's actual structure
• required files, commands, or dependencies are missing
• the worktree contains unrelated dirty changes that make the checkpoint or commit ambiguous
• the plan requires a destructive git action you were not explicitly authorized to perform
• verification still fails after reasonable diagnosis and the failure suggests the plan is wrong or incomplete

When any of the above conditions is irrecoverable and cannot be resolved within the current turn, emit exactly the following line on its own in stdout or stderr before stopping:

AFLOW_STOP: <reason>

The workflow engine detects this line and fails the run immediately with the extracted reason instead of spending more turns on the same blocker. Do not emit this sentinel for normal plan-not-done states; use it only for hard blockers that require human intervention.