scheduled-work-queue

A scheduled-work queue for recording deferred or background tasks together with their completion criteria and later verification method.

In plain words
What is it for?
It helps record work for later sessions, define what done means, check the real outcome, and distinguish completed, outstanding, and blocked tasks.
Why use it?
It prevents dispatched or apparently quiet work from being reported as finished without evidence.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/helixdevelopment/code/scheduled-work-queue
Any agent
npx skills add HelixDevelopment/code --skill scheduled-work-queue
Clone the repo
git clone --depth 1 https://github.com/HelixDevelopment/code

Made for: Claude Code, Codex.

Per session 19 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 472 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00019 $0.00472
Opus 5 $0.00010 $0.00236
Sonnet 5 $0.00004 $0.00094
Haiku 4.5 $0.00002 $0.00047

Measured yesterday against content hash 8db5edc2865d, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

scheduled-work-queue scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

helix_code/internal/commands/builtin_skills/scheduled-work-queue/SKILL.md · 45 lines

What it actually says

You are recording deferred work on the scheduled-work queue for a HelixCode user.

Work to record: {{ARG.task}}

The purpose of the queue is not merely to remember work — it is to stop unverified work being reported as finished. Apply this discipline:

  1. RECORD THE WORK with enough detail that a later session, with none of the present context, can pick it up: what must happen, what "done" looks like, and what evidence would prove it.

  2. RECORD HOW ITS OUTCOME WILL BE CHECKED. An entry whose completion cannot be verified later is a note, not a queue item.

  3. WHEN THE ITEM COMES BACK AROUND, RE-CHECK IT RATHER THAN ASSUMING. The entire value of the queue is that work whose real outcome is uncertain, blocked or overdue gets verified before anyone calls it done. Never report a queued item as complete because it was dispatched, because time passed, or because nothing appeared to go wrong. Absence of an error is not evidence of success.

  4. DISTINGUISH THE THREE STATES HONESTLY:

    • done, with the checked evidence named;
    • still outstanding;
    • blocked, naming exactly what it is blocked on. Never collapse "unverified" into "done".
  5. A BLOCKED ITEM PARKS ITSELF, NOT THE WHOLE QUEUE. Keep making progress on everything that is not blocked.

If a background task reported an exit status, remember that the status describes the wrapper that ran the work, not the work itself — confirm the actual artifact or state change the task was supposed to produce.

The queue is served by the scheduled-work component; the full contract is documented in constitution/skills/scheduled-work-queue/skill.md.

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 45 lines · 19 tokens per session scan A 8db5edc2865d

Subscribe to this mod's changes

scheduled-work-queue is a skill published in the GitHub repository HelixDevelopment/code (2 stars, last pushed 4d ago), licensed MIT. It adds 19 tokens to every session and 472 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Related

Other skills, from other repositories

reskin

Author a NEW skin for the reskinnable-demo app. A skin is a self-contained domain plugin under src/skins/ / that implements the frozen Skin contract (src/shell/skin-contract.ts) to swap the app's entire experience — brand, theme, layout, pages, tools, data, and agent — as a live sales demo. Use when the user says "add…

CopilotKit/CopilotKit · 154 tokens

copilotkit-channels

Use for the CODE half of a managed Intelligence Channel with Slack or Microsoft Teams: customising the Channel a CLI-scaffolded project already ships, or — for a project the CLI did not generate — writing the Channel declaration, the long-running host, and the awaited activation call. Teams provider setup is in scope…

CopilotKit/CopilotKit · 112 tokens

copilotkit-setup

Use when adding CopilotKit to an existing project or bootstrapping a new CopilotKit project from scratch. Covers framework detection, package installation, runtime wiring (managed Intelligence or self-hosted SSE), provider setup, and first working chat integration.

CopilotKit/CopilotKit · 56 tokens

setup-slack-channel

Use for the PROVIDER half of getting a locally running CopilotKit Channels agent to answer in Slack, when no Slack app exists yet — setting up a Channels bot in Slack for the first time, creating the Slack app and its tokens, attaching it to a managed Intelligence Channel, or when a Channel reports setuprequired, sits…

CopilotKit/CopilotKit · 206 tokens

a2ui-renderer

Render A2UI (Agent-to-UI declarative surfaces) in CopilotKit v2. Enable the runtime via CopilotRuntime({ a2ui: {...} }), then enable the provider via . Auto-activates via /info — do NOT manually pass renderActivityMessages. createA2UIMessageRenderer ships from @copilotkit/react-core/v2; low-level primitives…

CopilotKit/CopilotKit · 175 tokens

runtime

@copilotkit/runtime — mount a fetch-native CopilotRuntime on any JS server, wire middleware, pick an AgentRunner, instantiate BuiltInAgent (Factory Mode with TanStack AI is the preferred default) or plug in any of 12 external agent frameworks (Mastra, LangGraph, CrewAI Crews/Flows, PydanticAI, ADK, LlamaIndex, Agno…

CopilotKit/CopilotKit · 150 tokens