Agent Pulse

Standardized agent interruptibility and load-status check with fixed trigger words and fixed output. Use when the user sends `Agent Pulse` or `/pulse`, asks...

Security Scan

Agent Pulse's code, instructions, and requirements are internally consistent with its stated purpose of producing a small, rule-based status card — no extraneous credentials, network calls, or install steps are present.

Purpose & Capability

Name/description, triggers, and included scripts all align: the skill only needs low-cost runtime signals and local rule logic to produce a fixed pulse card. There are no unrelated environment variables, binaries, or external services requested.

Instruction Scope

SKILL.md confines the agent to collecting inexpensive runtime signals and running the supplied scripts (pulse_eval.py and render_pulse.py). It explicitly forbids treating the pulse check itself as workload evidence and discourages overreaching introspection. The instructions do assume the runtime can provide the listed signals (runningTask, queuedMessages, etc.), which is appropriate for this purpose.

Install Mechanism

No install spec is provided (instruction-only deployment), and included scripts are small, local Python files with no network downloads or extraction. There is no high-risk download or package installation.

Credentials

The skill requests no environment variables, credentials, or config paths. The decision logic works from a JSON signal input and does not attempt to access unrelated secrets or system state.

Persistence & Privilege

always is false and the skill does not request persistent system-wide privileges or modify other skills' configs. It relies on being invoked explicitly (or by normal autonomous invocation) which is appropriate for its purpose.

Assessment

This skill appears to do exactly what it says: evaluate a small set of runtime signals and return a compact, fixed-format pulse card. Before deploying, verify that your environment supplies the expected signal JSON (runningTask, queuedMessages, recentState, etc.), run the included scripts locally to confirm behavior, and ensure that whatever system invokes the scripts passes only intended signals (to avoid unintentionally exposing other runtime context). There are no network calls or secret requests in the code, but treat any execution of bundled scripts as code that will run locally — run them in a controlled/staging environment first if you have security concerns.

Overview

Use this skill as a strict status-check protocol. Return a compact pulse card about current load and interruptibility with fixed wording and fixed fields.

Default to baseline status, not self-influenced status. The pulse request itself should not make the agent look busier than it was immediately before the check.

Standard triggers

Treat these as direct pulse requests:

• Agent Pulse
• /pulse
• 你现在忙吗
• 忙不忙
• 现在方便吗
• 现在负荷怎么样
• 能接新任务吗
• 能插个任务吗
• 现在能接活吗

If the user explicitly uses Agent Pulse or /pulse, always return the fixed pulse card format and do not switch into conversational explanation unless asked.

Fixed output contract

Return exactly these four lines after the first line label:

Agent Pulse
status: <idle|light|busy|blocked|unknown>
interruptibility: <high|medium|low>
acceptNewTask: <yes|caution|no>
reason: <short reason>

Rules:

• No extra paragraphs by default
• No bullets by default
• No long explanation unless the user asks why
• Keep reason under 12 words when possible

Status meanings

• idle: not actively occupied; easy to interrupt
• light: active but not loaded; can accept work
• busy: currently occupied; interruption should be minimized
• blocked: waiting on dependency/tool/human
• unknown: signals insufficient or conflicting

Decision workflow

1. Gather low-cost signals

Use only cheap signals first:

• running task or stream
• queued messages
• blocked or waiting state
• recent activity recency
• obvious backlog signs
• active project being advanced
• pending action items not yet delivered
• work already started even if no heavy tool is currently running
• release-critical or due-soon work
• current tool or exec activity when visible
• whether the agent is waiting on the user or an external dependency

For OpenClaw-style environments, prefer visible runtime signals over introspection. Good sources include recent tool activity, pending background exec runs, undelivered work already in progress, and a quick session_status check when needed. Do not count routine async completion notices or the pulse query itself as workload evidence.

2. Evaluate with the bundled script

Use scripts/pulse_eval.py to map signal JSON into the pulse result.

3. Return fixed card

If trigger is Agent Pulse or /pulse, output only the fixed card. If trigger is natural language, the fixed card is still preferred unless the user clearly wants explanation.

Guardrails

• Prefer deterministic rules over model judgment
• Do not overclaim precision
• Do not infer hidden internal state without evidence
• If signals are weak, use unknown
• Use no only for genuinely overloaded or risky in-flight states
• Do not run proactively; require explicit pulse trigger by default
• Do not treat the pulse query itself as workload evidence

Deployment defaults

To reproduce the intended product behavior across users/environments:

• trigger only on explicit pulse requests
• return the fixed pulse card by default
• prefer baseline status over self-influenced status
• use rules first, model reasoning second
• keep output compact unless the user asks why

Resources

scripts/

• scripts/pulse_eval.py converts simple signals into a pulse result
• scripts/render_pulse.py renders the exact fixed output card

references/

• references/rules.md contains the classification thresholds and output policy
• references/openclaw-signals.md shows a practical signal-mapping recipe for OpenClaw-style runtimes