mission-runtime

A Claude Code plugin that does the prompt engineering for you.

Write the way you already write — short, vague, slangy, a follow-up fragment, a frustrated debug line. The plugin reconstructs the intended task from the conversation, delegates the work, and answers in your style. You do not have to start a mission or learn a command vocabulary.

A legacy /mission path still exists for long-horizon work that needs on-disk ledgers across sessions.

Install

In Claude Code, run:

/plugin marketplace add bodencrouch/mission-runtime
/plugin install mission-runtime@mission-runtime

That is the whole setup. There are no packages to install and no accounts to create. The plugin's scripts need Python 3, which most systems already have.

Know before you install: the plugin records what each run did — including your prompts, in full — to a folder on your own computer (~/.missionruntime/). Nothing leaves your machine. To record nothing, set the environment variable MISSIONRUNTIME_TELEMETRY=off. Details in Telemetry.

Just say it

Tell Claude what you want, however you would say it to a person:

bro why is this broken

or:

yeah do that but only fedora

The plugin fills in the missing context, sends a complete spec to a specialist, and brings the answer back. For a multi-session outcome you can still type /mission and get the older contract-and-ledger loop.

Then let it run. Here is what happens:

1. Claude reads your message and the conversation. Fragments, slang, and "yeah do that" are treated as a real task, not as a request to restate the original ask.
2. The plugin compiles a self-contained execution spec: the real objective, recovered context, semantic constraints, and what would count as done. Tone and length stay at this layer.
3. A specialist from the existing agent roster gets that spec — they never see the conversation, so everything they need is in the spec.
4. The answer comes back in your register. You should not have to know a skill ran.

For a multi-session outcome that needs on-disk ledgers, type /mission. The .mission/ folder still holds that older loop, and "resume the mission" still picks it up.

Say it, get it

Just talk. "only fedora" and "less writing" are not the same kind of constraint: one changes the work, the other changes how the answer reads. The plugin splits them.

How it works

The compile. Your message is treated as evidence of what you need, not as a literal task list. The plugin recovers the intended job from the conversation, writes a self-contained spec, and holds presentation preferences (tone, length, "give me the answer first") at this layer.

The split. A clause goes to the specialist if removing it would change the work or the correct answer. It stays here if it only changes how the finished result reads. Ambiguous cases go to the spec.

The agents. Ten specialists handle bounded jobs: mapping the repo, research, implementation, tests, security review, code review, failure diagnosis, docs, a final independent audit, and one general analyst for jobs the others do not cover. Reviewers cannot write files; writers get exact file boundaries. They see the spec, not the chat.

Any phrasing. You never have to tune your wording. A fragment, a typo, or a frustrated debug line is enough. The plugin does not invent requirements it cannot see in the conversation or the repo.

Questions. It only interrupts you when evidence genuinely cannot decide — a fact only you have, an irreversible step, a real scope change. Even then the question arrives as a short pick-list with a default that fires on silence.

The legacy loop. /mission still writes a contract into .mission/ and runs the older plan–do–verify–replan cycle across sessions. Use it when the work needs a ledger, not when you just said "bro why is this broken."

The .mission folder

Legacy missions keep their memory in .mission/ at your project root: the contract, the current state, the work queue, decisions, assumptions, failed attempts, and test evidence. This folder is why a /mission run survives closed sessions and multi-day gaps.

It is kept out of your version control automatically (via .git/info/exclude — your .gitignore is never touched). Deleting the folder deletes the mission's memory. Ordinary prompt-runtime sessions do not create this folder.

Telemetry

Every run leaves a local record, so you can measure what the plugin costs you instead of guessing.

What is recorded: session timings, tool activity, agents launched, and your prompts — in full, by default. Where: ~/.missionruntime/ on your machine. Nothing is ever transmitted.

Read the numbers:

python3 scripts/mr_report.py             # summary; missions vs. ordinary sessions
python3 scripts/mr_report.py --sessions  # one row per session

The report gives costs only — time, tool calls, agent counts. It does not claim the runtime was worth it; that judgment needs your own verdict on what each run produced.

Check recording works:

python3 scripts/mr_doctor.py

Turn it down or off (environment variables win over the config file):

• MISSIONRUNTIME_TELEMETRY=off — record nothing.
• MISSIONRUNTIME_REDACT=1 — store text lengths instead of text.
• MISSIONRUNTIME_HOME=<path> — move the store.
• ~/.missionruntime/config.json — the same switches, in a file.

Delete history by removing ~/.missionruntime/sessions/.

Claude Code records automatically. Config templates for Cursor, Copilot, and Codex ship in hooks/ but have not been tested against those hosts — treat them as unproven. Install one with python3 scripts/mr_install_hooks.py --host cursor --apply. The full design is in skills/mission/references/telemetry.md.

Requirements

• Claude Code.
• Python 3 for the telemetry scripts. They use only the standard library.

No other dependencies. No build step. No network calls.