TESP

Enforce the Task Execution Signal Protocol for non-instant work so execution stays visible, staged, versioned, and auditable. Use when a task will take more...

Security Scan

The skill's purpose (a lightweight execution-tracking protocol) is reasonable and requires no credentials or installs, but its runtime instructions reference undeclared, user-specific filesystem paths and imply persistent hooks (a cron) that are not actually provided — an inconsistency worth caution.

Purpose & Capability

The name/description match the instructions' intent (govern execution visibility and staging) and the skill requires no credentials or installs, which is proportionate. However, the protocol explicitly names a user-specific config path (/Users/weweclaw/.openclaw/workspace/TASK_QUEUE.md and TASK_ARCHIVE.md) even though the skill declares no required config paths — this is an inconsistency that could cause the agent to read/write arbitrary files in the user's home.

Instruction Scope

SKILL.md and references instruct the agent to create/update local task board files, enforce cadence, and rely on an 'existing audit cron' in the source workspace. Because this is an instruction-only skill, these are the exact runtime actions the agent will take: touching local files and looking for system-scheduled jobs. The skill does not declare or ask for permission for these filesystem or scheduling actions, and the hard-coded absolute path contains a specific username, which is unexpected and potentially intrusive.

Install Mechanism

No install spec and no code files — lowest-risk delivery model. Nothing will be written to disk by an installer; runtime behavior is entirely driven by the instruction text.

Credentials

The skill declares no environment variables or credentials (appropriate for its stated purpose), but the instructions reference configuration paths and an existing 'light audit' cron that imply access to persistent workspace artifacts. Because these paths/configs are not declared in the metadata, there is a mismatch between declared and actual required local resources.

Persistence & Privilege

always:false and no autonomous-permission escalation are fine. But the skill's text implies there is a pre-existing daily audit cron in a 'source workspace' (tesp:light-audit). Since no code or install creates that cron, the statement is misleading — it may prompt the agent to search system cron entries or try to create one without explicit install instructions.

What to consider before installing

This skill appears to be what it says (a protocol to make long tasks visible) and doesn't request credentials or install anything — that's good. However, it hard-codes a user-specific file path (/Users/weweclaw/.openclaw/workspace/...) and claims a daily audit cron exists even though no install or code is included. Before installing or invoking it: 1) confirm or change the task-board path to a location you control (or require explicit permission to read/write); 2) ask the skill author to remove hard-coded usernames and to make any cron/scheduling opt-in with clear install steps; 3) test in an isolated workspace so you can see what files the agent creates/updates; and 4) if you don't want the agent touching your filesystem, do not grant it file access or adjust the protocol to use ephemeral or explicit user-provided storage. These inconsistencies are not proof of malicious intent but are enough to warrant caution.

Apply TESP whenever silence would create coordination risk.

中文简介

TESP（Task Execution Signal Protocol / 任务执行信号协议）是一套面向非即时任务的执行治理协议。 它的核心不是“把任务做完”本身，而是让执行过程对协作者可见、可查、可监督。 适用于研究、迁移、排查、实施、跨 agent 协作、异步任务和任何需要持续推进但不能静默消失的工作。

What this skill is for

TESP turns long or multi-step work into a visible execution flow. It is for tasks that need acknowledgement, staged progress, blockers, active task tracking, and clean handoff discipline.

Typical triggers:

• “Do this and keep me posted.”
• “Break this big task down and supervise execution.”
• “Set a working protocol so I don’t need to chase status.”
• “Audit whether agents are actually following the execution standard.”
• “Clean up the task board so only current work stays visible.”

Core operating sequence

Follow this order:

1. Acknowledge fast — send Layer 1 with visible TESP version, scene, and goal.
2. Stage the work — if the task is long, split it into numeric progress units like 2/5.
3. Broadcast by cadence — update based on expected duration, not random chatter.
4. Track active work — keep current tasks in TASK_QUEUE.md.
5. Archive finished work — move completed items into TASK_ARCHIVE.md.
6. Escalate blockers clearly — say what is blocked and what decision is needed.
7. Keep audits cheap — prefer file checks, diffs, and samples over full replay.

Minimum operating requirements

For any non-instant task:

• Use Layer 1 acknowledgement with visible TESP version.
• Use numeric progress for long tasks.
• Keep active and completed work separated.
• Do not make the human chase status.

Multi-agent rule

When multiple agents are involved:

• update the task board first
• write the shared handoff second
• then transfer execution

Model rule

Use GLM / MiniMax by default for lightweight governance, queue checks, and audits. Upgrade only when stronger reasoning is actually needed.

Read next

For the full protocol text and exact templates, read:

• references/protocol.md
• references/templates.md