Solidify "user leaves, Agent pushes through the night" into a reusable loop.Since v0.2.0, host-agnostic and domain-agnostic: scheduling is only the trigger; the loop itself is a five-step general process; acceptance criteria are parameterized by domain (code-type / legal-type).
First-battle instance: dsh-plugins repo, night of 2026-09-30 (ZCode host, 15-minute rounds, code domain, six-card delivery); the generalization requirement came from the user's same-day instructions (other hosts have different scheduling mechanisms + legal projects must also be able to run overnight).
Positioning and division of labor: this skill is theautonomous advancement loop layer— task self-organization, scheduled triggering, patrol-based acceptance, recording and handoff. Channel selection, dispatch gating, and worker discipline follow its host rules multi-agent-orchestration ; Git/PR rules use git-workflow. This skill does not repeat their content.
1. Core loop (five steps, host-agnostic)
- Organize tasks: automatically aggregate and generate/refresh the candidate queue from task sources — project TASKS files, issues, leftover session to-dos, user dictation. Deduplicate, sort by dependency; automatically bucket by value criteria:dispatchable(implementation/verification type, hand to worker),Agent retains(research/investigation type),requires user(decision/presence/authorization type, register only without advancing); mark doubtful items as pending confirmation, do not guess.
- Find the next item: take items by bucket — if dispatchable and active workers are not full (default ≤3), dispatch; if only retained items remain, do them yourself in this loop; if only user-required items remain, switch to pure patrol recording.
- Complete or dispatch: for dispatch, select the type according to orchestration channel criteria (small/medium cards use host subagent, independent worker scenarios follow their mode table); task cards are self-contained (goal/allowed/prohibited items/acceptance commands/delivery protocol).
- Verify and advance: verify the delivery according to domain acceptance criteria (§4); if it passes, close it out (merge/archive/register); if it fails, either close the loop with a minor fix or park it — during unattended periods,prefer conservatism。
- Record and hand off: each round, update the queue anchor (state machine: completed/in-flight/pending dispatch/parked); at the end, produce three types of handoff reports (completed/parked/pending user).
2. Scheduled trigger layer (decoupled from the loop)
The loop itself contains no scheduling mechanism; the trigger contract:input = queue anchor path + safety boundaries (who can write/prohibited list) + loop prompt;output = anchor state written back + handoff artifacts. Any scheduler satisfying the contract can drive it.
| Host | Scheduled driving | State |
|---|---|---|
| ZCode | Built-in scheduled tasks (CronCreate/CronUpdate, prompt injects this loop) | First-battle verified |
| Claude Code | Native /goal mode(Goal-driven autonomous iteration, progress/audit dual-sided) preferred; second choice headless CLI (claude -p --continue) + system scheduling |
Pending real-world testing (mapping spec see local TASKS NA-D6) |
| Codex | goal mode(Iterate the next work unit until the goal is achieved) preferred; second choice headless CLI (codex exec) + system scheduling |
Pending real-world testing |
| OS-level fallback | cron / launchd invokes the host CLI headless entry point, feeding parameters as loop prompt and anchor path | Available on any host |
Key points of the fallback path: the scheduler only handles "launching the Agent on schedule + passing parameters"; all loop state is persisted to anchor files (no assumption of a resident process); each round self-limits its timeout (e.g. kill at 15 minutes) to prevent scheduling pileup.
3. Pre-launch checklist (do not proceed if any item is unmet)
| # | Prerequisite | Description |
|---|---|---|
| 1 | Explicit user authorization | Unattended + frequency + approximate duration; no scheduled tasks may be set up without authorization |
| 2 | Task source readable | The queue can be aggregated automatically (§1.1), butthe safety boundary must be put in writing: writable scope, do-not-touch list (production environment/others' territory/sensitive data), delivery channel |
| 3 | Acceptance criteria in writing | Select by domain (§4) and declare in the anchor; the legal domain must explicitly list the human final-review gate |
| 4 | Recovery anchor persisted to disk | Queue state + rails + stop conditions written to a persistent file (session context may be summarized/restarted) |
| 5 | Trigger ready | Create scheduled tasks per the host table; pre-sleep report (what has been dispatched/how the guardrails work/what will be seen upon waking) |
4. Acceptance criteria (domain-parameterized)
Code type(default): full test suite green + lint/mechanical review 0 FAIL + diff within allowed scope + NOT_VERIFIED truthfully marked. Delivery form = branch + PR (Git rules follow git-workflow).
Legal type(document/retrieval tasks):
- Mechanically verifiable layer(Agent can self-check automatically): checklist item by item (document elements complete), citation verification (statutes/case numbers compared against authoritative databases—tools such as Yuandian hallucination check), consistency of party and case number information, format and deadline calculation review (dates/amounts/counts), versioning and audit trail (file names/modification records).
- Human final-review gate (cannot be bypassed automatically): lawyer final review, signing, and external sending (court/opposing party/client) are all left to the user—overnight output can only be "draft + verification record + morning review checklist".
- Delivery form = files + verification record (git/PR not mandatory; if there is a repo, go through the repo).
- Data red line: actual client materials by default do not enter the unattended loop—desensitize/synthesize first; confidential materials are always handled in person.
Custom domains extend isomorphically: just define the triad of "mechanically verifiable layer + human final-review gate + delivery form".
5. Patrol inspection and worker monitoring
- Dual channel: host subagent and independent worker (Orca supervised/terminal-managed/tmux)—completion authority and patrol evidence priority follow the orchestration §2 mode table; this skill does not create its own.
- Dead worker determination (dual proof, distilled from two real-world runs on 2026-09-30): ① Session/output log stops updating (transcript mtime unchanged for a long time) ② No progress in worktree/artifacts (file mtime stalled, no commit). Both proofs present → declare dead; a single proof is not enough to declare dead (may be running a long test).
- Disposition tiers: Complete delivery not pushed → PM independently re-verifies, then delivers; midway WIP → clean up and re-dispatch (task card can be replayed); same card fails 2 consecutive times → park and record, do not blindly re-pull.
- Zombie UI entries: The interface shows running but the task system finds no such task — verify with the stop interface (if it returns No task found, it is purely a display remnant; refreshing clears it).
- Infrastructure failure fallback: If GitHub GraphQL errors persist when creating a PR → REST API (
gh api repos/<o>/<r>/pulls）。
6. Queue anchor template (standardized)
## 授权与 rails
授权（日期+频率+时长）/ 定时任务 id / 领域与验收判据型 / 禁碰清单 / 交付形态 / 停止条件
## 队列状态（每轮更新）
1. [完成·PR/交付物] 卡名（去向）
2. [在途·workerX] 卡名（要点 + allowed）
3. [自留] 研究项
4. [待派] 卡名（派发前置）
5. [泊车] 卡名（原因 + 证据）
6. [需用户] 事项
## 巡检日志
- HH:MM 轮：一行结论（做了什么/全静/泊车原因）
7. Morning handover
- Three categories summarized:Completed(deliverables list + destination),Parked(reason + evidence),Pending user decision。
- Remind the user to stop scheduled tasks (or delete them as soon as the user says stop); clean up one-off resources.
8. Boundaries and known limitations
- In the trigger host table, the two rows Claude Code (
/goal)/ Codex (goal mode) are pending field testing — after field testing, update this table and the mapping specification (NA-D6). Native mode only replaces loop driving; it does not replace anchors, acceptance criteria, or the human final-review gate. - In the legal domain, the mechanically verifiable layer is a framework, not a checklist — specific check items are customized per project, andnever automate the human final-review gate。
- Session-bound built-in timers stop when the session terminates; use an OS-level fallback for cross-session persistent scheduling.
- Quota is shared (host subagent and main session); self-limit the duration of each round, and do not do unbounded long tasks.