Polling Best Practices
v1.0.1Best practices for automating long-running, asynchronous tasks via cron-style polling. Use when the user wants to monitor a background CLI command or API cal...
⭐ 0· 73·0 current·0 all-time
bySkywalker326@skywalker-lili
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Benign
high confidencePurpose & Capability
Name/description match the contents: a guidance SKILL.md and a single, clearly-labeled polling script template. The skill requests no env vars, no binaries, and contains only guidance plus a convenience script — all appropriate for a 'polling best practices' skill.
Instruction Scope
SKILL.md stays within its stated scope (deciding suitability, asking for a one-time confirmation, creating per-task temp folders, writing task.json, monitoring status). It explicitly requires explicit user confirmation before starting. Note: the provided template runs arbitrary shell commands (POLL_COMMAND evaluated via eval), so the agent or user must not run it without reviewing the command contents. This is expected for a general-purpose polling helper but is a security consideration the user should understand.
Install Mechanism
No install spec; instruction-only skill with an included template file. Nothing is downloaded or written by an installer — low install risk.
Credentials
The skill declares no required environment variables or credentials. However, the workflow stores parameters in task.json and runs user-supplied commands; users should avoid embedding secrets in those files or commands.
Persistence & Privilege
always:false and no special privileges requested. The skill does not request persistent presence or modify other skills or system-wide agent settings.
Assessment
This skill appears coherent and benign, but it executes user-supplied commands via a template script, so: (1) review any POLL_COMMAND or task.json contents before running; do not embed credentials or secrets in commands or task files; (2) run the template in a restricted account or sandbox (not as root) until you trust the commands; (3) verify parse rules (jq/grep) to avoid false positives/negatives; (4) set conservative POLL_INTERVAL/MAX_POLLS to avoid excessive retries or charges; (5) inspect logs and temp folders after runs and delete sensitive artifacts. If you plan to let an agent run this autonomously, require an explicit confirmation step from the human and limit the scope of commands the agent may run.Like a lobster shell, security has layers — review code before you run it.
latestvk97ccf052176rq2ces86fs9rq183nv9h
License
MIT-0
Free to use, modify, and redistribute. No attribution required.