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 skills add Heapy/kortex --skill exec-plangit clone --depth 1 https://github.com/Heapy/kortexWrote 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/heapy/kortex/exec-plan)<a href="https://agentmods.dev/skills/heapy/kortex/exec-plan"><img src="https://agentmods.dev/badge/skills/heapy/kortex/exec-plan/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/heapy/kortex/exec-plan"><img src="https://agentmods.dev/badge/skills/heapy/kortex/exec-plan.svg" alt="Reviewed on agentmods" width="80" 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.00045 | $0.01224 |
| Opus 5.5 | $0.00018 | $0.00490 |
| Sonnet 5.5 | $0.00009 | $0.00245 |
| Haiku 4.5 | $0.00005 | $0.00122 |
Grade A, and why
exec-plan 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 13d 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 — 84 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Execute Plan
Carry the approved plan through implementation, verified findings, integrated checks, and human task
review. Use the kotgent CLI for every daemon operation and Git for repository changes. Do not use
direct HTTP, an SDK, or database edits. Honor a narrower user-selected scope; never mark the whole plan
complete when authorized work remains.
Establish identity and state
Read repository instructions and kotgent --version / help. Require plan execution commands and
session done. Use the live Kotgent pane as caller. Outside a pane, require the exact Kotgent session ID
from the user or invocation context; never infer it from environment variables, provider conversations,
names, cwd, recency, or kotgent list. Append --session ID to caller-dependent plan/task commands only
in that explicit mode. start, stop, and session done address explicit sessions and have no such flag.
Resolve the linked task using ref-less kotgent task show (plus the explicit session flag when needed).
If the user supplied a different task, reconcile that mismatch before execution; do not silently relink.
Keep its explicit reference for all plan commands, and read kotgent plan show REF. Require an
in_progress backlog task and an approved or executing plan. A draft or outstanding review goes
through kotgent:make-plan; never manufacture approval. A done plan needs a human-review handoff, not
another execution. Inspect task activity, session links, Git status, worktrees and existing branches.
Owned child sessions already assigned in this plan are coordinated work; unrelated overlapping sessions
need coordination under kotgent:work-task before edits.
Run kotgent plan claim REF. Read execution.orchestratorSessionId from its successful response as the
validated parent ID for children. A live different orchestrator is a conflict; do not kill or impersonate
it. A dead owner's plan can be claimed and resumed. The task plan is the source of runtime truth, not
an old transcript or local checklist.
What ships with it
3 files 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.
- 13d ago First seen · 84 lines · 45 tokens per session scan A a15d866745cd
exec-plan is a skill published in the GitHub repository Heapy/kortex (7 stars, last pushed 7d ago), licensed Apache-2.0. It adds 45 tokens to every session and 1,224 once invoked, about $0.0002 per session on Opus 5.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-10-03.
Other skills, from other repositories
actions-reusable-workflows
Wire a repository to the bitwise-media-group/github-workflows reusable workflows — thin, SHA-pinned caller workflows for CI, security (CodeQL) scanning, release (release-please/GoReleaser/Zensical docs), the signature-preserving fast-forward /merge + merge-review-ack + merge-notice flows, and add-to-project — plus the…
go-release
Release engineering for Go projects — GoReleaser v2 with version ldflags into an internal/version package, SBOMs and multi-arch container images, tag-triggered GitHub Actions releases, CI running build/vet/test -race/govulncheck with SHA-pinned actions, and Renovate coverage for gomod, tools, npm, and Actions. Use…
python-release
Release engineering for Python projects on uv — static versioning in pyproject.toml exposed via importlib.metadata, building the sdist and wheel with uv build, publishing to PyPI with uv publish via Trusted Publishing (OIDC, no token), tag-triggered GitHub Actions releases, CI running ruff/ty (or pyright)/pytest with…
workflow-commit
Commit changes the way a sandboxed agent must — write Conventional Commit messages and, because commit signing fails inside the sandbox, hand the real commit off through a generated commit.sh script. Inside a git worktree, commit normally (unsigned) and emit a commit.sh that re-signs the range; in the main checkout…
understand-diff
Use when you need to analyze git diffs or pull requests to understand what changed, affected components, and risks.
make-pr-easy-to-review
Prepare PRs for review by cleaning noisy history, improving PR descriptions, and adding reviewer guidance without changing code behavior. Use for "make this easy to review", "tidy this PR", "clean up commits", or "annotate the diff".