Execution Verifier

intent

Stop fake progress reporting by enforcing hard evidence of work. this skill separates what an agent claims it's doing from what it actually changed. use it when long-running tasks stall, when users report "the agent says it's working but nothing happened", or when you need automated progress checkpoints every 15-30 minutes with blocker detection. the core rule: no artifact change = no progress. period.

inputs

• project_dir (path): root directory of the project being monitored. required. example: projects/ai-human-co-production.
• status_file (path): markdown file tracking current state. required. example: projects/ai-human-co-production/STATUS.md. format: free-form markdown with timestamps and last-known state.
• open_tasks_file (path): markdown or json listing actionable next steps. required. example: projects/ai-human-co-production/OPEN_TASKS.md. format: numbered or bulleted list of concrete tasks with acceptance criteria.
• window_min (integer): time window in minutes to check for file changes. required. default: 30. controls how far back the verifier looks for evidence.
• verify_progress_script (path): python script that detects file deltas, commits, test outputs, and line changes. included: skills/execution-verifier/scripts/verify_progress.py.
• verify_execute_verify_script (path): python script that runs closed-loop: verify, trigger executor if blocked, re-verify. included: skills/execution-verifier/scripts/verify_execute_verify.py.
• executor_cron_id (uuid, optional): unique id of the executor job to auto-trigger if verifier detects zero progress. example: fc567f18-83fa-426c-8181-71a10f4568b3. required only for closed-loop mode.
• git_repo (path, optional): if project is git-tracked, verifier will check commit history within window_min. default: inferred from project_dir.

procedure

1. execute one concrete next action. pull the top task from open_tasks_file. confirm it has acceptance criteria (e.g. "create file X with lines Y and Z"). run the action. output: at least one file modified or one commit pushed within the window_min.

2. write artifacts to target files. ensure files on disk change (line additions, deletions, edits, new files, or deletions). do not rely on logs or console output as proof. output: file modification timestamps and byte size deltas measurable by filesystem.

3. run verify_progress script. execute the verifier command below with your project paths and window_min value. the script scans the window_min timeframe for file changes, git commits, test result files, and line deltas. output: json report with keys: progress_detected (boolean), changed_files (list), commit_shas (list), blocker_reason (string if no progress), timestamp.

4. generate strict 3-line report. use the verifier output to build the report in the format below. if progress_detected is true, report concrete evidence. if false, name the blocker and suggest next action. output: three-line markdown string ready for status updates.

5. if closed-loop mode, trigger re-verify. after executor auto-triggers (step 2 in decision points), wait 2-3 minutes and run verify_progress again. compare before/after json. output: combined json with before, triggered_execute, after keys showing state transition.

decision points

• if progress_detected is true: report line 1 as 已完成：<file_path> (<line_delta> lines added/removed). proceed to line 2 (current actionable step). example: 已完成：src/parser.py (+47 lines).
• if progress_detected is false (no file changes, no commits in window): replace line 1 with 本轮无新增（原因：<blocker_reason>）. blocker_reason should name the concrete blocker (e.g. "auth token expired", "api rate limit hit", "dependency missing", "test suite timeout"). line 2 becomes the immediate unblock action. example: 本轮无新增（原因：api key invalid）.
• if executor_cron_id is provided and closed-loop mode is enabled: after detecting no progress, auto-trigger the executor job via openclaw cron run <executor_cron_id> --force. do not wait for manual intervention. re-verify after 2-3 minutes.
• if executor auto-trigger fails (cron job not found or api error): log the error and report it in the blocker field. do not silent-fail. example: 本轮无新增（原因：cron trigger failed - job not found）.
• if window_min has zero commits and zero file changes: this counts as no progress. do not credit "the agent thought about it" or "logs show startup". output blocker report.
• if multiple files changed but none match acceptance criteria: investigate. check if files are artifacts (code, config, test results) or noise (temp logs, .cache/). accept only intentional changes. if unsure, report the change but flag risk.

output contract

verify_progress script output (json):

{
  "timestamp": "2025-01-15T14:32:00Z",
  "project_dir": "projects/ai-human-co-production",
  "window_min": 30,
  "progress_detected": true|false,
  "changed_files": ["src/parser.py", "tests/test_parser.py"],
  "file_deltas": [
    {"path": "src/parser.py", "lines_added": 47, "lines_removed": 12}
  ],
  "commit_shas": ["a1b2c3d"],
  "commit_messages": ["feat: add async parsing"],
  "blocker_reason": null|"<reason>",
  "next_action": "<task from open_tasks_file>"
}

strict 3-line report format (markdown):

已完成：<file_path + concrete change>
进行中：<current actionable step>
下一步+ETA：<next step + time estimate>

or if blocked:

本轮无新增（原因：<blocker>）
进行中：<unblock action>
下一步+ETA：<next step + time estimate>

closed-loop json output (json):

{
  "before": {<verify_progress output>},
  "triggered_execute": true|false,
  "executor_job_id": "fc567f18-83fa-426c-8181-71a10f4568b3",
  "after": {<verify_progress output after executor runs>},
  "duration_sec": 180
}

all files must be written to disk (not just claimed in logs). commit hashes or file mtimes serve as proof. json outputs written to projects/<project>/VERIFIER_REPORT.json (one per cycle).

outcome signal

• user sees the 3-line report in STATUS.md or dashboard and can immediately spot: (a) what file changed and by how much, (b) what step is running now, (c) what's blocked if nothing changed.
• if closed-loop is enabled, a blocked task auto-triggers executor and re-reports within 3-5 minutes. no manual babysitting needed.
• if the agent claims "done" but verifier shows no file change, the contradiction is visible. user knows to investigate the blocker.
• cron jobs never report-only without verification. every 30m, the verifier job runs closed-loop and logs before/after state in VERIFIER_REPORT.json.

verifier commands

single-pass verification (check current state):

python3 skills/execution-verifier/scripts/verify_progress.py \
  --project-dir projects/ai-human-co-production \
  --status projects/ai-human-co-production/STATUS.md \
  --open-tasks projects/ai-human-co-production/OPEN_TASKS.md \
  --window-min 30

closed-loop mode (verify → auto-trigger → re-verify):

python3 skills/execution-verifier/scripts/verify_execute_verify.py \
  --verify-cmd "python3 skills/execution-verifier/scripts/verify_progress.py --project-dir projects/ai-human-co-production --status projects/ai-human-co-production/STATUS.md --open-tasks projects/ai-human-co-production/OPEN_TASKS.md --window-min 30" \
  --execute-cmd "openclaw cron run fc567f18-83fa-426c-8181-71a10f4568b3 --force"

the closed-loop script outputs combined json to stdout with keys: before, triggered_execute, after, duration_sec.

cron setup (recommended)

run two jobs, offset by 5 minutes:

• executor job (every 30m, isolated agentTurn): executes next action and writes artifacts.
• verifier job (every 30m offset +5m, main systemEvent): runs closed-loop script above. auto-triggers executor if no progress detected.

never deploy a report-only cron without verifier attached. silent failures kill trust.

edge cases handled

• rate limits: if api call fails with 429, verifier detects zero progress and reports blocker. executor auto-triggers on retry.
• auth expiry: if api key or token expires mid-window, file writes stop. verifier catches it, blocker_reason includes "authentication failed".
• network timeout: if executor hangs, verifier detects no change after window_min and auto-triggers retry.
• empty result sets: if api returns 200 ok with empty data, no artifacts change. verifier treats as no progress.
• git not initialized: if project_dir has