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.
npx agentmods add skills/helixdevelopment/code/scheduled-work-queuenpx skills add HelixDevelopment/code --skill scheduled-work-queuegit clone --depth 1 https://github.com/HelixDevelopment/codeWhat 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.
| Model | Per session | Once 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 |
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.
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:
-
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.
-
RECORD HOW ITS OUTCOME WILL BE CHECKED. An entry whose completion cannot be verified later is a note, not a queue item.
-
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.
-
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".
-
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.
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.
- yesterday First seen · 45 lines · 19 tokens per session scan A 8db5edc2865d
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.
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-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-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.
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…
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…
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…