openclaw/reporting-governance-plugin
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add silent long-task checkpoint gate

Browse Source
This commit is contained in:
Eve
2026-04-22 14:19:48 +08:00
parent 450b99fa5b
commit 83be99a6bb
4 changed files with 68 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
skills/long-task-governor/SKILL.md
View File

@@ -135,7 +135,22 @@ Use `checkpoint-template.md` in this skill directory.
---
## 5. No-fake-progress rule
## 5. Silent long-task governance
If a long-task will not naturally emit an immediate next user-visible message, treat it as a **silent long-task**.
A silent long-task must define at startup:
- the first forced checkpoint trigger
- what to report if not yet complete
- what status transition to use if there is no new evidence
- how final owner handoff will happen if a decision is expected
Silent long-tasks must not rely on memory, intention, or implied future follow-up.
If the user later has to ask where the update went, the flow is considered failed.
---
## 6. No-fake-progress rule
Only count as real progress if there is at least one of:
- new file change
@@ -154,7 +169,7 @@ If you only have status sync, say it is status sync. Do not dress it up as progr
---
## 6. Stop-clock gate
## 7. Stop-clock gate
If repeated checkpoints show no new evidence, do **not** keep the task cosmetically active.
You must choose one:
@@ -168,21 +183,22 @@ Without that, default to `paused`.
---
## 7. How to use this skill in practice
## 8. How to use this skill in practice
When this skill applies:
1. decide if the request is ordinary chat or long task
2. if long task, create/update a task record
3. choose one of the five valid states
4. if reporting progress, use the 5-part checkpoint structure
5. before claiming progress, check for real evidence
6. if no evidence and no concrete action, stop the clock
7. if the run is clearly heading toward a user pass/fail or accept/reject judgement on Telegram, prepare a button-path before the final handoff
8. if the entire test itself exists to validate Telegram decision closure, run it as a button-driven flow rather than a normal long plain-text report
4. if the task is silent, define the first forced checkpoint before proceeding
5. if reporting progress, use the 5-part checkpoint structure
6. before claiming progress, check for real evidence
7. if no evidence and no concrete action, stop the clock
8. if the run is clearly heading toward a user pass/fail or accept/reject judgement on Telegram, prepare a button-path before the final handoff
9. if the entire test itself exists to validate Telegram decision closure, run it as a button-driven flow rather than a normal long plain-text report
---
## 8. Integration guidance
## 9. Integration guidance
This skill should be paired with:
- the current session `WORKFLOW.md`
@@ -207,10 +223,11 @@ This prevents governed long-task flows from degrading back into ambiguous text-o
---
## 9. Success criteria
## 10. Success criteria
This skill is working correctly when:
- non-chat work always enters a governed state
- silent long-tasks never go dark without a predeclared checkpoint
- checkpoints no longer cause silent stalls
- no-evidence updates are not mislabeled as progress
- stalled work becomes `paused` / `blocked` instead of fake-`active`