/proactive-loop

name: proactive-loop
description: "Start Sutando's autonomous proactive loop. Monitors tasks, runs health checks, and builds missing capabilities on a recurring schedule."
user-invocable: true

Proactive Loop

One pass = the numbered steps below, in order. Each step is a command, its exit codes, and what to do per code. The reasoning, measurements and incidents behind every step live in [`docs/proactive-loop-rationale.md`](../../docs/proactive-loop-rationale.md) under the same step number; read it when a step surprises you, never per pass. A rule belongs here only as a command a mechanism enforces; prose lessons go to the rationale doc (`tests/proactive-loop-skill-budget.test.py` caps this file and refuses date stamps in it).

**Usage**: `/proactive-loop [interval]` (default 10m).

On activation

1. `/schedule-crons` — registers the session crons and stamps them. 2. Task watcher via the `Monitor` tool: `command: 'bash src/watch-tasks-stream.sh --role session --inbox "$(bash scripts/sutando-config.sh workspace)/tasks"'` (substitute `$SUTANDO_TASKS_DIR` for the inbox when it is set — the same tag step 9's re-arm uses), `timeout_ms: 1800000`, `description: 'Streaming task watcher'`. Each `TASK_FILE: <name>` line is one task to Read and process. Re-arm it on the expiry notice and on any notice that it exited early (on macOS Claude Code reports a SIGTERM death as `exit code 144`); the inbox is unwatched until the standby's grace elapses. `Monitor` has no `persistent` option: it kills the command at `timeout_ms` (30 min is the maximum) and sends one expiry notice. On that notice, re-arm the watcher the same way (a start on a watched inbox exits 0); until you do, the external standby announces tasks through the pane after a 45 s grace. Windows has no `Monitor` tool: `src/startup.ps1` owns `src/task-dispatcher.ps1`; do not start another watcher. 3. If `CronList` already shows a `main-loop` / `/proactive-loop` job, run the per-pass body directly — never add a second loop driver.

Per pass

`WORKSPACE="$(bash scripts/sutando-config.sh workspace)"` once; quote every `"$WORKSPACE/..."` path.

0. **Status.** `bash scripts/core-status.sh running "<work>"` on each pivot. Finish with step 1’s idle command; never redirect the JSON. 0.5. **Quota tier** (Claude core): `python3 $CLAUDE_CONFIG_DIR/skills/quota-tracker/scripts/read-quota.py | python3 skills/proactive-loop/scripts/quota-tier.py` → `TIER <FULL|MEDIUM|LIGHT|MINIMAL> (bound by …)`. Then `python3 skills/proactive-loop/scripts/claude-quota-cadence.py --json` → if `effective_cron` differs from the `/proactive-loop` job in `CronList`: capture the old job id, `CronCreate` the new job with `prompt: "/proactive-loop"` and `cron: <effective_cron>`, confirm it in `CronList`. Then `CronDelete` the old id and confirm exactly one `/proactive-loop` job remains. If create or confirmation fails, keep the old job and stop loudly. Codex core: `python3 skills/proactive-loop/scripts/codex-quota-gate.py --json`. Tier caps step 6's depth (LIGHT/MINIMAL: no self-development); it never skips owner tasks, health or the log. 0.7. **Reconstruct.** Invoke the `context-reconstruct` skill (a Skill-tool call, not a mention). It reads `<workspace>/hosts/<host>/current-track.md` first, then the live thread (`python3 src/discord-read.py <channel> --serving <channel>` when serving a task, `--operator` otherwise), pending questions, relay, build log. Trust the record over recall; maintain `current-track.md`. 1. **Tasks.** Process every file in `$WORKSPACE/tasks/`; `access_tier: team|other` → the sandboxed path. Group a thread with `[deduped: task-<latest>]`, staged under its FINAL name and gated into place — `results/` is claimed by a poller in under a second, and the checker reads the source id from the BASENAME, so a generic temp name makes it pass everything: `S="$WORKSPACE/state/dedup-staging/<file>"` then `python3 skills/proactive-loop/scripts/check-dedup-targets.py "$S" && mv -f "$S" "$WORKSPACE/results/<file>"` (0 clean · 1 the dedup delivers nothing · 2 cannot answer). All-notice groups use `[no-send]` on each. Marker semantics belong to `src/result_markers.py`; never re-implement them. When this core consumes a task itself, move `$WORKSPACE/tasks/<id>.txt` to `$WORKSPACE/tasks/archive/<id>.txt` after writing its result; bridges and the Windows dispatcher archive their own claims. Before idle: `python3 scripts/unanswered-tasks.py --workspace "$WORKSPACE" && bash scripts/core-status.sh idle "" --loop-complete` (1 = a task got no result, so idle does not run). 1.5. **Connect waits.** `python3 skills/connect-apps/scripts/connectors.py rearm` restarts the waiter of any pending connector wait that lost it; idempotent, and a failure never blocks the pass. 2. **Questions.** A question reaches the owner once, when asked (`scripts/ask-owner.py`). Flagless, `src/check-pending-questions.py` files the outbox and sends a stored card's one-time pointer, no reminders; `--notify` reminds only when he asks. `src/pending_questions_reader.py list` only when he asks or you are blocked on an answer. 3. **Health.** `python3 src/health-check.py`; fix with `--fix` what it can. A warn is a pointer into the record: before investigating, `grep -in "<entity from the warn TEXT>" "$H/current-track.md"` and `pending_questions_reader.py list --json | grep -i "<entity>"` with `H="$WORKSPACE/hosts/$(bash scripts/sutando-config.sh host-label)"`; a zero means try another token, then `grep -n '^## ' "$H"/*.md` before concluding absence. Extend a hit; never re-file it. 3.45. **Duplicate issue gate**, chained so a refusal cannot be skipped: `python3 skills/proactive-loop/scripts/gh-duplicate-check.py --repo <owner/name> --title "<title>" && gh issue create --repo <owner/name> --title "..." --body-file <f>` (0 no candidate · 1 do not file, candidates named · 2 cannot answer)