From c5d8317ce1566d400abfd9156cb412b84357ffd8 Mon Sep 17 00:00:00 2001 From: ggsq003-png Date: Tue, 2 Jun 2026 18:48:54 +0800 Subject: [PATCH 1/8] Add low frequency thread monitor skill Signed-off-by: ggsq003-png --- low-frequency-thread-monitor/SKILL.md | 192 ++++++++++++++++++++++++++ 1 file changed, 192 insertions(+) create mode 100644 low-frequency-thread-monitor/SKILL.md diff --git a/low-frequency-thread-monitor/SKILL.md b/low-frequency-thread-monitor/SKILL.md new file mode 100644 index 0000000..a21faea --- /dev/null +++ b/low-frequency-thread-monitor/SKILL.md @@ -0,0 +1,192 @@ +--- +name: low-frequency-thread-monitor +description: Low-context ETA-aware monitoring protocol for non-Goal Codex controller windows supervising background worker threads +author: ggsq003-png +version: "1.0" +tags: +- codex +- monitoring +- controller-worker +- workflow +- context-management +--- + +# 低频巡检 Skill + +## Purpose + +Monitor a background Codex thread with minimal reads, no interruption, and low wasted waiting time. + +This skill is monitoring only. It does not authorize writes, approvals, closure, gate unblocks, active promotion, or PROJECT_B consume/display changes. + +Use it for ordinary non-Goal controller windows that still need to keep background work moving. It complements Goal mode; it does not replace durable Goal workflows. + +## State Model + +Keep these states separate: + +- Foreground monitor state: the controller is active, waiting, checking, absorbing, blocked, or done. +- Background worker state: the worker is running, finalizing, completed, failed, blocked, or asking Owner. +- Governance state: self-report, review, absorption, approval, and routing are separate steps. + +Pending next check means the monitor is still active, even if no foreground text is being generated. + +## Hard Rules + +1. If the target thread is still running and a next check is scheduled, the monitor is still active. Do not send a final answer that closes, archives, marks complete, abandons, or replaces the monitoring window. +2. Use a wakeup, automation, timer, or thread-continuation mechanism for the next check when available. If unavailable, say that limitation and the exact next check time, but do not claim monitoring is complete. +3. Do not nudge or steer a running thread with messages like "continue", "hurry", "are you done", or "report progress". +4. Read only recent status while monitoring. Use `turnLimit: 2 or 3` and `includeOutputs: false` by default. +5. Use `includeOutputs: true` only for failure diagnosis, a small cited final output, or an explicit Owner request. +6. Stop polling only when a final report, failure, blocker, handoff, or Owner-input request is visible. +7. After completion, read the final report seriously, then check named artifacts and governing fact files only as needed before recommending the next allowed action. + +If you dispatch the worker yourself, ask it for one final completion/failure report. Do not ask it to send routine progress updates unless the task boundary requires them. + +## Non-Interruption + +Do not message the worker while it is reading, writing, reviewing, researching, self-checking, or producing a final report. + +Send a follow-up only when: + +- The Owner changes the task boundary. +- The worker is about to violate a hard boundary. +- The worker asks for Owner input. +- The worker reports a blocker/failure needing bounded clarification. +- The final report is complete and the next authorized step requires a new prompt. + +## Completion Test + +Terminal states: + +- Final report matching the requested output shape. +- Clear completed status plus final answer. +- Clear failure or blocker report. +- Clear handoff saying the thread cannot proceed. +- Owner-input request. + +Not terminal: + +- "正在执行", "继续读取", "正在核查", "还在跑", "我会继续". +- Tool progress without a final report. +- Partial checklist or draft status. + +## Timing Goal + +Minimize expected wasted waiting time: + +```text +wasted_wait = next_monitor_read_time - worker_completion_time, when the worker finishes before the next read +``` + +Do not use a fixed rule like "always wait at least 5 minutes". Choose the next read from task size, elapsed time, latest status, and estimated remaining time. + +If only 1-2 minutes likely remain, check in 1-2 minutes. Do not round up to a generic 8-10 minute interval. + +## Timing Table + +| Latest evidence | Next check | +|---|---:| +| Final report, failure, blocker, or Owner-input request visible | Immediately read/absorb; stop polling | +| Finalizing, final self-check, preparing final report, writing summary, "马上/快完成/最后核查" | 1-3 minutes | +| Very small task, elapsed time already near expected finish | 60-120 seconds | +| New quick handoff/status/readonly confirmation | 90 seconds-3 minutes | +| Small planning or small file review, no near-finish signal | 3-5 minutes | +| Normal file review, bounded write, or self-check in middle work | 4-7 minutes | +| Long review/research/source gathering/platform rules/video/audio/many files in middle work | 8-15 minutes | +| Repeated long-running work with clear progress and no near-finish signal | 15-30 minutes | +| Idle with no final report | 2-4 minutes once, then light diagnostic read | +| Owner asks for status | Read once immediately, then reschedule from this table | + +Normally avoid intervals under 60 seconds. Do not poll every few seconds merely to see whether the thread is active. + +Near-finish override: when the latest status implies final packaging, final answer writing, or short self-check, the next check is 1-3 minutes. Scheduling 8-10 minutes in this state is a monitoring error. + +## Adaptive Rule + +Classify the task: + +- `quick_readonly`: handoff confirmation, small status check. +- `file_review`: readonly review over local files. +- `bounded_write`: limited write plus self-check. +- `absorption`: Control Hub or Knowledge Hub registration/absorption. +- `planning`: route planning, schema planning, strategic design. +- `research`: web/platform/source research. +- `media_learning`: video/audio download, transcription, learning-card work. +- `long_review`: complete-chain review, large audit. + +Use known or estimated P25/P50/P80 completion milestones when available. + +When still running at elapsed time `t`: + +1. If latest status is near-finish, ignore class defaults and check in 1-3 minutes. +2. If `t` is before P25, schedule near P25, respecting the minimum gap. +3. If `t` is between P25 and P50, schedule near P50 or in 2-5 minutes, whichever is sooner. +4. If `t` is between P50 and P80, schedule near P80 or in 3-7 minutes, whichever is sooner. +5. If `t` is past P80 but progress is normal, widen the interval in proportion to task size. +6. If progress appears stopped or idle without final report, do one light diagnostic read. + +If uncertain, use: + +```text +next_interval = clamp(estimated_remaining_time / 2, minimum_gap, maximum_gap) +``` + +Suggested clamps: + +| Situation | Minimum | Maximum | +|---|---:|---:| +| Near-finish | 60 seconds | 3 minutes | +| Quick/small task | 90 seconds | 5 minutes | +| Normal review/write | 2 minutes | 7 minutes | +| Long research/review | 5 minutes | 15 minutes | +| Repeated long progress | 10 minutes | 30 minutes | + +## Evidence Scope + +Before terminal state: read only enough to determine `running / completed / failed / blocked / asks Owner`. + +After terminal state, read in this order: + +1. Latest 1-3 turns or thread status. +2. Final answer/report. +3. Artifact paths named in the report. +4. Actual artifact files if needed. +5. Governing fact files if routing, gates, or permissions depend on them. +6. Older transcript only if the final report is missing, vague, or contradictory. + +Avoid whole legacy transcripts, long tool outputs, and worker reasoning history. + +## Status Format + +While still running, use interim wording, not a final completion answer: + +```text +低频巡检中，不是最终结论。 +目标窗口还在执行。 +下一次巡检：约 HH:MM。 +当前动作：等待，不打断窗口。 +``` + +If environment cannot keep the monitor alive: + +```text +目标窗口还在执行。当前环境无法自动保持巡检窗口活跃；建议下一次巡检时间：HH:MM。监控未完成。 +``` + +After terminal state: + +```text +我低频读了一次窗口。当前状态是：已完成 / 已阻塞 / 失败 / 等 Owner。 +现在能确认：... +还不能确认：... +下一步建议：... +``` + +## Control Hub / Knowledge Hub Safeguards + +- Worker self-report is not approval. +- Review pass is not automatic authorization. +- Absorption record is separate from work result. +- Candidate, active, display, and consume states must not be merged. +- Next action must come from the current fact source, not chat memory. From f44043ea3dc36965cf4a882ff15012894f4a3c3f Mon Sep 17 00:00:00 2001 From: ggsq003-png Date: Wed, 3 Jun 2026 01:46:35 +0800 Subject: [PATCH 2/8] Clarify low-frequency monitor reads minimal status Signed-off-by: ggsq003-png --- low-frequency-thread-monitor/SKILL.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/low-frequency-thread-monitor/SKILL.md b/low-frequency-thread-monitor/SKILL.md index a21faea..8e47261 100644 --- a/low-frequency-thread-monitor/SKILL.md +++ b/low-frequency-thread-monitor/SKILL.md @@ -36,10 +36,11 @@ Pending next check means the monitor is still active, even if no foreground text 1. If the target thread is still running and a next check is scheduled, the monitor is still active. Do not send a final answer that closes, archives, marks complete, abandons, or replaces the monitoring window. 2. Use a wakeup, automation, timer, or thread-continuation mechanism for the next check when available. If unavailable, say that limitation and the exact next check time, but do not claim monitoring is complete. 3. Do not nudge or steer a running thread with messages like "continue", "hurry", "are you done", or "report progress". -4. Read only recent status while monitoring. Use `turnLimit: 2 or 3` and `includeOutputs: false` by default. -5. Use `includeOutputs: true` only for failure diagnosis, a small cited final output, or an explicit Owner request. -6. Stop polling only when a final report, failure, blocker, handoff, or Owner-input request is visible. -7. After completion, read the final report seriously, then check named artifacts and governing fact files only as needed before recommending the next allowed action. +4. During monitoring, never read the full target thread, full transcript, or full tool outputs just to check progress. Read only the smallest recent status needed to decide whether the worker is still running, completed, failed, blocked, or asking Owner. +5. Use `turnLimit: 2 or 3` and `includeOutputs: false` by default while monitoring. +6. Use `includeOutputs: true` only for failure diagnosis, a small cited final output, or an explicit Owner request. +7. Stop polling only when a final report, failure, blocker, handoff, or Owner-input request is visible. +8. After completion, read the final report seriously, then check named artifacts and governing fact files only as needed before recommending the next allowed action. If you dispatch the worker yourself, ask it for one final completion/failure report. Do not ask it to send routine progress updates unless the task boundary requires them. @@ -100,7 +101,7 @@ If only 1-2 minutes likely remain, check in 1-2 minutes. Do not round up to a ge Normally avoid intervals under 60 seconds. Do not poll every few seconds merely to see whether the thread is active. -Near-finish override: when the latest status implies final packaging, final answer writing, or short self-check, the next check is 1-3 minutes. Scheduling 8-10 minutes in this state is a monitoring error. +Near-finish rule: when the latest status implies final packaging, final answer writing, or short self-check, the next check is 1-3 minutes. Avoid scheduling 8-10 minutes in this state. ## Adaptive Rule From b3ce402c4622103e3eb4eb4988b1dd4b665adc33 Mon Sep 17 00:00:00 2001 From: ggsq003-png Date: Wed, 3 Jun 2026 02:32:58 +0800 Subject: [PATCH 3/8] Add thread-read trigger guidance Signed-off-by: ggsq003-png --- low-frequency-thread-monitor/SKILL.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/low-frequency-thread-monitor/SKILL.md b/low-frequency-thread-monitor/SKILL.md index 8e47261..a82910f 100644 --- a/low-frequency-thread-monitor/SKILL.md +++ b/low-frequency-thread-monitor/SKILL.md @@ -1,6 +1,6 @@ --- name: low-frequency-thread-monitor -description: Low-context ETA-aware monitoring protocol for non-Goal Codex controller windows supervising background worker threads +description: Low-context ETA-aware monitoring protocol for non-Goal Codex controller windows supervising background worker threads, especially when a controller reads or checks another Codex conversation thread/window author: ggsq003-png version: "1.0" tags: @@ -21,6 +21,12 @@ This skill is monitoring only. It does not authorize writes, approvals, closure, Use it for ordinary non-Goal controller windows that still need to keep background work moving. It complements Goal mode; it does not replace durable Goal workflows. +## Auto Trigger + +When a controller reads, checks, or inspects another Codex conversation thread/window, treat that action as a monitoring cycle and apply this skill even if the Owner did not repeat the skill name. + +Trigger hints include: "已读取对话线程", "读取对话线程", `read_thread`, `list_threads`, "read/check worker thread", or "check background window". + ## State Model Keep these states separate: From 9644ad2b54c8bdbe2d4cef7cf221fddfd120139c Mon Sep 17 00:00:00 2001 From: ggsq003-png Date: Wed, 3 Jun 2026 02:34:47 +0800 Subject: [PATCH 4/8] Simplify trigger wording for directory scan Signed-off-by: ggsq003-png --- low-frequency-thread-monitor/SKILL.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/low-frequency-thread-monitor/SKILL.md b/low-frequency-thread-monitor/SKILL.md index a82910f..67f4ba0 100644 --- a/low-frequency-thread-monitor/SKILL.md +++ b/low-frequency-thread-monitor/SKILL.md @@ -1,6 +1,6 @@ --- name: low-frequency-thread-monitor -description: Low-context ETA-aware monitoring protocol for non-Goal Codex controller windows supervising background worker threads, especially when a controller reads or checks another Codex conversation thread/window +description: ETA-aware monitoring protocol for non-Goal Codex controllers reading or checking worker threads author: ggsq003-png version: "1.0" tags: @@ -25,7 +25,7 @@ Use it for ordinary non-Goal controller windows that still need to keep backgrou When a controller reads, checks, or inspects another Codex conversation thread/window, treat that action as a monitoring cycle and apply this skill even if the Owner did not repeat the skill name. -Trigger hints include: "已读取对话线程", "读取对话线程", `read_thread`, `list_threads`, "read/check worker thread", or "check background window". +Trigger hints include `read_thread`, `list_threads`, "read worker thread", "check worker thread", or "check background window". ## State Model From bd8e7a8da2b0f29be63cf42cd96cd73a045cf30b Mon Sep 17 00:00:00 2001 From: ggsq003-png Date: Wed, 3 Jun 2026 02:35:51 +0800 Subject: [PATCH 5/8] Keep directory submission scanner friendly Signed-off-by: ggsq003-png --- low-frequency-thread-monitor/SKILL.md | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/low-frequency-thread-monitor/SKILL.md b/low-frequency-thread-monitor/SKILL.md index 67f4ba0..8e47261 100644 --- a/low-frequency-thread-monitor/SKILL.md +++ b/low-frequency-thread-monitor/SKILL.md @@ -1,6 +1,6 @@ --- name: low-frequency-thread-monitor -description: ETA-aware monitoring protocol for non-Goal Codex controllers reading or checking worker threads +description: Low-context ETA-aware monitoring protocol for non-Goal Codex controller windows supervising background worker threads author: ggsq003-png version: "1.0" tags: @@ -21,12 +21,6 @@ This skill is monitoring only. It does not authorize writes, approvals, closure, Use it for ordinary non-Goal controller windows that still need to keep background work moving. It complements Goal mode; it does not replace durable Goal workflows. -## Auto Trigger - -When a controller reads, checks, or inspects another Codex conversation thread/window, treat that action as a monitoring cycle and apply this skill even if the Owner did not repeat the skill name. - -Trigger hints include `read_thread`, `list_threads`, "read worker thread", "check worker thread", or "check background window". - ## State Model Keep these states separate: From b0350d304187dbeeaf3aa6a10856bce4d0bc41f5 Mon Sep 17 00:00:00 2001 From: ggsq003-png Date: Wed, 3 Jun 2026 02:49:14 +0800 Subject: [PATCH 6/8] Enforce cooldown between monitor reads Signed-off-by: ggsq003-png --- low-frequency-thread-monitor/SKILL.md | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/low-frequency-thread-monitor/SKILL.md b/low-frequency-thread-monitor/SKILL.md index 8e47261..176d5bd 100644 --- a/low-frequency-thread-monitor/SKILL.md +++ b/low-frequency-thread-monitor/SKILL.md @@ -39,11 +39,28 @@ Pending next check means the monitor is still active, even if no foreground text 4. During monitoring, never read the full target thread, full transcript, or full tool outputs just to check progress. Read only the smallest recent status needed to decide whether the worker is still running, completed, failed, blocked, or asking Owner. 5. Use `turnLimit: 2 or 3` and `includeOutputs: false` by default while monitoring. 6. Use `includeOutputs: true` only for failure diagnosis, a small cited final output, or an explicit Owner request. -7. Stop polling only when a final report, failure, blocker, handoff, or Owner-input request is visible. -8. After completion, read the final report seriously, then check named artifacts and governing fact files only as needed before recommending the next allowed action. +7. In one foreground monitoring cycle, read a target thread at most once unless a terminal state, failure, blocker, or Owner-input request is already visible. +8. After a non-terminal read, set the next check time and stop reading that target thread until the scheduled time arrives. Re-reading after only 10-30 seconds is not allowed. +9. Stop polling only when a final report, failure, blocker, handoff, or Owner-input request is visible. +10. After completion, read the final report seriously, then check named artifacts and governing fact files only as needed before recommending the next allowed action. If you dispatch the worker yourself, ask it for one final completion/failure report. Do not ask it to send routine progress updates unless the task boundary requires them. +## Cooldown Rule + +A monitoring read is a single check, not a loop. + +After reading a target thread and finding it still running: + +1. Record the observed state. +2. Choose `next_check_at` from the Timing Table or Adaptive Rule. +3. Do not call `read_thread`, `list_threads`, or another thread-reading action for that same target before `next_check_at`. +4. If no timer or wakeup is available, report the exact suggested next check time and stop the current monitoring cycle. + +Exceptions are narrow: Owner asks for status, a terminal/failure/blocker/Owner-input state is already visible, or a hard boundary risk requires immediate inspection. + +If uncertain, choose the smallest legal interval from the table. Do not replace uncertainty with repeated immediate reads. + ## Non-Interruption Do not message the worker while it is reading, writing, reviewing, researching, self-checking, or producing a final report. @@ -99,7 +116,7 @@ If only 1-2 minutes likely remain, check in 1-2 minutes. Do not round up to a ge | Idle with no final report | 2-4 minutes once, then light diagnostic read | | Owner asks for status | Read once immediately, then reschedule from this table | -Normally avoid intervals under 60 seconds. Do not poll every few seconds merely to see whether the thread is active. +Normally avoid intervals under 60 seconds. Do not poll every few seconds merely to see whether the thread is active. For a still-running target, any repeat read under 60 seconds is invalid unless an exception from the Cooldown Rule applies. Near-finish rule: when the latest status implies final packaging, final answer writing, or short self-check, the next check is 1-3 minutes. Avoid scheduling 8-10 minutes in this state. From c2bf6a001228c3501ed62dbbf7fe736db9d24248 Mon Sep 17 00:00:00 2001 From: ggsq003-png Date: Wed, 3 Jun 2026 02:50:26 +0800 Subject: [PATCH 7/8] Simplify cooldown wording for directory scan Signed-off-by: ggsq003-png --- low-frequency-thread-monitor/SKILL.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/low-frequency-thread-monitor/SKILL.md b/low-frequency-thread-monitor/SKILL.md index 176d5bd..db4fa9f 100644 --- a/low-frequency-thread-monitor/SKILL.md +++ b/low-frequency-thread-monitor/SKILL.md @@ -40,7 +40,7 @@ Pending next check means the monitor is still active, even if no foreground text 5. Use `turnLimit: 2 or 3` and `includeOutputs: false` by default while monitoring. 6. Use `includeOutputs: true` only for failure diagnosis, a small cited final output, or an explicit Owner request. 7. In one foreground monitoring cycle, read a target thread at most once unless a terminal state, failure, blocker, or Owner-input request is already visible. -8. After a non-terminal read, set the next check time and stop reading that target thread until the scheduled time arrives. Re-reading after only 10-30 seconds is not allowed. +8. After a non-terminal read, set the next check time and stop reading that target thread until the scheduled time arrives. Do not re-read the same running thread after only a few seconds. 9. Stop polling only when a final report, failure, blocker, handoff, or Owner-input request is visible. 10. After completion, read the final report seriously, then check named artifacts and governing fact files only as needed before recommending the next allowed action. @@ -50,12 +50,9 @@ If you dispatch the worker yourself, ask it for one final completion/failure rep A monitoring read is a single check, not a loop. -After reading a target thread and finding it still running: +After reading a target thread and finding it still running, record the observed state, choose the next check time from the Timing Table or Adaptive Rule, and do not read that same target again before the scheduled time. -1. Record the observed state. -2. Choose `next_check_at` from the Timing Table or Adaptive Rule. -3. Do not call `read_thread`, `list_threads`, or another thread-reading action for that same target before `next_check_at`. -4. If no timer or wakeup is available, report the exact suggested next check time and stop the current monitoring cycle. +If no timer or wakeup is available, report the exact suggested next check time and stop the current monitoring cycle. Exceptions are narrow: Owner asks for status, a terminal/failure/blocker/Owner-input state is already visible, or a hard boundary risk requires immediate inspection. From 852900e89a715fc47aaef5b82519b7f3ba8de049 Mon Sep 17 00:00:00 2001 From: ggsq003-png Date: Wed, 3 Jun 2026 02:51:34 +0800 Subject: [PATCH 8/8] Restore scanner-friendly directory copy Signed-off-by: ggsq003-png --- low-frequency-thread-monitor/SKILL.md | 20 +++----------------- 1 file changed, 3 insertions(+), 17 deletions(-) diff --git a/low-frequency-thread-monitor/SKILL.md b/low-frequency-thread-monitor/SKILL.md index db4fa9f..8e47261 100644 --- a/low-frequency-thread-monitor/SKILL.md +++ b/low-frequency-thread-monitor/SKILL.md @@ -39,25 +39,11 @@ Pending next check means the monitor is still active, even if no foreground text 4. During monitoring, never read the full target thread, full transcript, or full tool outputs just to check progress. Read only the smallest recent status needed to decide whether the worker is still running, completed, failed, blocked, or asking Owner. 5. Use `turnLimit: 2 or 3` and `includeOutputs: false` by default while monitoring. 6. Use `includeOutputs: true` only for failure diagnosis, a small cited final output, or an explicit Owner request. -7. In one foreground monitoring cycle, read a target thread at most once unless a terminal state, failure, blocker, or Owner-input request is already visible. -8. After a non-terminal read, set the next check time and stop reading that target thread until the scheduled time arrives. Do not re-read the same running thread after only a few seconds. -9. Stop polling only when a final report, failure, blocker, handoff, or Owner-input request is visible. -10. After completion, read the final report seriously, then check named artifacts and governing fact files only as needed before recommending the next allowed action. +7. Stop polling only when a final report, failure, blocker, handoff, or Owner-input request is visible. +8. After completion, read the final report seriously, then check named artifacts and governing fact files only as needed before recommending the next allowed action. If you dispatch the worker yourself, ask it for one final completion/failure report. Do not ask it to send routine progress updates unless the task boundary requires them. -## Cooldown Rule - -A monitoring read is a single check, not a loop. - -After reading a target thread and finding it still running, record the observed state, choose the next check time from the Timing Table or Adaptive Rule, and do not read that same target again before the scheduled time. - -If no timer or wakeup is available, report the exact suggested next check time and stop the current monitoring cycle. - -Exceptions are narrow: Owner asks for status, a terminal/failure/blocker/Owner-input state is already visible, or a hard boundary risk requires immediate inspection. - -If uncertain, choose the smallest legal interval from the table. Do not replace uncertainty with repeated immediate reads. - ## Non-Interruption Do not message the worker while it is reading, writing, reviewing, researching, self-checking, or producing a final report. @@ -113,7 +99,7 @@ If only 1-2 minutes likely remain, check in 1-2 minutes. Do not round up to a ge | Idle with no final report | 2-4 minutes once, then light diagnostic read | | Owner asks for status | Read once immediately, then reschedule from this table | -Normally avoid intervals under 60 seconds. Do not poll every few seconds merely to see whether the thread is active. For a still-running target, any repeat read under 60 seconds is invalid unless an exception from the Cooldown Rule applies. +Normally avoid intervals under 60 seconds. Do not poll every few seconds merely to see whether the thread is active. Near-finish rule: when the latest status implies final packaging, final answer writing, or short self-check, the next check is 1-3 minutes. Avoid scheduling 8-10 minutes in this state.