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 kitchen-engineer42/joharnessburg --skill job-runtimegit clone --depth 1 https://github.com/kitchen-engineer42/joharnessburgWrote 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/kitchen-engineer42/joharnessburg/job-runtime)<a href="https://agentmods.dev/skills/kitchen-engineer42/joharnessburg/job-runtime"><img src="https://agentmods.dev/badge/skills/kitchen-engineer42/joharnessburg/job-runtime/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/kitchen-engineer42/joharnessburg/job-runtime"><img src="https://agentmods.dev/badge/skills/kitchen-engineer42/joharnessburg/job-runtime.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.00153 | $0.01616 |
| Opus 5 | $0.00077 | $0.00808 |
| Sonnet 5 | $0.00031 | $0.00323 |
| Haiku 4.5 | $0.00015 | $0.00162 |
Grade A, and why
job-runtime 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 9d 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 — 82 lines — stays where its author put it; the contents beside it link to each section on GitHub.
job-runtime
Some produced apps have the I/O shape: an end-user submits an input, the app runs an expensive generation job — often minutes of staged workerLLM calls — and the user eventually downloads an artifact. The naive build runs that job inside the HTTP request that submitted it. It works in a demo and fails in use, three ways:
- The job dies with the request. Browser disconnect, laptop sleep, a flaky proxy — and minutes of generation are gone.
- Refresh loses everything. There's no task ID to come back to; the user's only option is to start over.
- A stuck job eats capacity forever. One hung generation holds its slot until someone restarts the server.
This skill teaches the runtime that prevents all three: a persistent task registry as the single source of truth, a bounded worker pool with leases, and endpoints whose state derives from the registry rather than from any open connection.
When this applies (and when it doesn't)
Apply it when generation is expensive enough that an end-user waits on it — multi-stage pipelines, anything past a few seconds, anything with a progress bar. Skip it when it isn't:
- Static-output apps (the mechanism ran at build time; the runtime just serves files) have no jobs to manage.
- Instant request/response (one workerLLM call, an answer in a couple of seconds) should stay a plain inline call per [[workerllm-runtime]].
The gray zone is a single 5–30 second call. The deciding question: would a user plausibly refresh, navigate away, or submit twice while waiting? If yes, give the job a task ID and a registry row; the rest of the machinery can stay minimal.
Not [[vertical-workflows]], not the event log
John has two kinds of long parallel work, and they live at different layers. Provider-native scale-out plus [[event-log-and-reducer]] orchestrates build-time work: subagents fanning out inside the John session to build the app, coordinating through .john/events/. The job runtime ships inside the produced app and serves its end-users at app runtime — where the build agent, its subagents, and the event log don't exist. Don't reach for build-session orchestration in produced-app code, and don't build a tasks table to coordinate build-time subagents. Same instinct, different layer, different machinery.
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.
- 9d ago First seen · 82 lines · 153 tokens per session scan A 0ed6c3c33150
job-runtime is a skill published in the GitHub repository kitchen-engineer42/joharnessburg (9 stars, last pushed 2mo ago), licensed MIT. It adds 153 tokens to every session and 1,616 once invoked, about $0.0008 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
symfony:doctrine-events
React to Doctrine entity lifecycle in Symfony with attribute listeners (#[AsDoctrineListener]/#[AsEntityListener], ORM 3) and lifecycle callbacks.
symfony:api-platform-dto-resources
Map entities to API DTOs in API Platform v4 with the Symfony Object Mapper (#[Map], stateOptions) for decoupled input/output contracts.
symfony:api-platform-filters
Implement API Platform filters - v4 Parameters API (QueryParameter) and legacy.
symfony:api-platform-versioning
Evolve API Platform APIs via deprecation (deprecationReason/sunset, RFC 8594/9745), the recommended alternative to versioning; plus path/header strategies.
symfony:config-env-parameters
Manage Symfony configuration with .env files, parameters, secrets vault, and environment-specific settings.
symfony:controller-cleanup
Refactor fat controllers into lean ones by extracting business logic to services, handlers, and invokable commands.