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/kdcube/kdcube/automationsnpx skills add kdcube/kdcube --skill automationsgit clone --depth 1 https://github.com/kdcube/kdcubeWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/kdcube/kdcube/automations)<a href="https://agentmods.dev/skills/kdcube/kdcube/automations"><img src="https://agentmods.dev/badge/skills/kdcube/kdcube/automations.svg" alt="Measured on agentmods" height="20"></a>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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00023 | $0.01714 |
| Opus 5 | $0.00012 | $0.00857 |
| Sonnet 5 | $0.00005 | $0.00343 |
| Haiku 4.5 | $0.00002 | $0.00171 |
Grade A, and why
automations 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 6d ago.
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.
How it starts
The opening of the file, as written. The whole thing — 150 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Automations
Automations are executable assets. They are not user memory.
Use automations.list_automations before creating a automation when the request may duplicate an existing automation.
Use automations.search_automations when the user asks to edit, delete, connect, or find a specific existing automation.
Use automations.get_automation to inspect the full automation definition and recent execution history before changing or explaining it.
Use automations.create_automation for actionable work the assistant may later execute or schedule.
Use automations.update_automation for automation definition changes after identifying the exact automation.
Use automations.delete_automation for removal requests; it soft-deletes by default.
Use automations.set_automation_status for disable, archive, delete, restore, and enable requests.
Use automations.link_automation when automations have follow-up, dependency, blocker, parent/child, or related-automation semantics.
Use automations.list_automation_executions when the user asks whether a automation ran, how it ended, or what happened recently.
Use automations.search_automation_executions when the user asks for prior run output, failures, logs, or produced files.
Use automations.search_recent_outputs when the user refers to a prior delivered
report, spreadsheet, file, job result, or says "it", "that report", or "the file
you sent" and the item is not on the current chat timeline.
Use automations.get_automation_execution after list/search returns an execution id and you
need the exact execution result, job conversation id, turn id, or artifact
metadata.
Use automations.materialize_execution_artifact after search_recent_outputs or
get_automation_execution returns the artifact to copy it into the current React turn
before reading, editing, or regenerating from it. Pass only the returned
artifact_ref; do not split it into execution id, automation id, filename, or path
arguments.
Only pass automation ids, execution ids, or memory ids after a list/search/get tool has returned them. Do not invent ids. Conversation ids, execution conversation ids, source labels, hard-delete flags, automation execution ids, and execution journal ids are runtime/UI concerns, not model-authored automation-management parameters.
When creating a automation, keep the title short, put execution details in the
description, and preserve schedule/context fields explicitly when the user
provides them. schedule.recurring is a boolean. Use true for repeating
automations and false for one-shot scheduled automations that should disable themselves
after the first due run. Do not represent recurrence as strings or numbers.
Manual and due executions should use the shared fresh-job execution loop. Each
run creates a fresh automation_job_* conversation and records the result in automation
execution storage.
Execution records are separate from automation definitions. Store only substantial run
outcomes there: status changes, user-facing summaries, compact log excerpts,
structured result data, and artifacts that must be available after the turn.
Artifact references may start as React fi: logical paths; execution-journal
tooling should later resolve and rehost them into bundle storage before
notifying the configured delivery channel.
The main conversational agent does not write execution records directly. Manual
and scheduled automation execution must go through the fresh job-execution loop, where
the job agent writes progress through automation_job.update_execution_journal.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 6d ago First seen · 150 lines · 23 tokens per session scan A bf4e31c76032
automations is a skill published in the GitHub repository kdcube/kdcube (25 stars, last pushed yesterday), licensed MIT. It adds 23 tokens to every session and 1,714 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-30.
Other skills, from other repositories
agent-framework-py-release
Use when cutting a Python release for the microsoft/agent-framework monorepo. Triggers on "bump py versions", "cut a python release", "prepare release PR for python", "release py packages", "bump python to X.Y.Z", or similar requests to bump Python package versions and prepare a release PR. Handles all four lifecycle…
python-package-management
Guide for managing packages in the Agent Framework Python monorepo, including creating new connector packages, versioning, and the lazy-loading pattern. Use this when adding, modifying, or releasing packages.
foundry-hosted-agent-validation
Step-by-step process for validating a Python Foundry hosted agent sample (under python/samples/04-hosting/foundry-hosted-agents/) end to end — running it locally (native runtime and azd ai agent run) and after deploying it to an Azure AI Foundry project with azd. Use this when asked to validate a hosted agent sample.
verify-samples-tool
How to use the verify-samples tool to run, verify, and manage sample definitions in the Agent Framework repository. Use this when adding, updating, or running sample verification.
python-feature-lifecycle
Guidance for package and feature lifecycle in the Agent Framework Python codebase, including stage meanings, feature-stage decorators, feature enums, and how to move APIs from one stage to the next.
python-testing
Guidelines for writing and running tests in the Agent Framework Python codebase. Use this when creating, modifying, or running tests.