Prompt library¶
Goal: give you prompts that work in any AI assistant, each mapped to the
exact runtime commands it should produce — so you can check the assistant did
what you asked.
Every prompt here names a URL and a goal, never a vendor or a tool-specific feature. That is what makes them portable.
Verify the commands, not the wording
Assistants are not deterministic — two will phrase the same work differently. What is fixed is the command each prompt should end in. Every capability named below was validated against a real release candidate. If your assistant runs something else, that is your signal.
All of them ship with the binary except the last showcase, which comes from the public capability store and says so where it appears.
Install and verify¶
Install Engineering Runtime by following
https://docs.engineeringruntime.com/get-started/installation/
and confirm the version.
Should run:
curl -fsSL https://raw.githubusercontent.com/engineeringruntime/engineering-runtime-releases/main/install.sh | sh
runtime version
Expected:
Prepare the Runtime Home¶
May run runtime bootstrap to report what any first Runtime command prepares
automatically. Expected on a first run:
Runtime Home: ~/.engineering-runtime
created runtime home
Capabilities: ~/.engineering-runtime/capabilities
refreshed runtime-owned specs/ and commands/ for (new runtime home) -> <version>: 39 file(s) written
Runtime is ready.
There is no capability seed. runtime capability list on this Home is an
empty success.
Connect GitHub¶
Should have you export RUNTIME_GITHUB_TOKEN, then run runtime auth status.
Before the token is exported the runtime says exactly what is missing:
github ✗ no token found in $RUNTIME_GITHUB_TOKEN; export it (e.g. in ~/.zshrc: export RUNTIME_GITHUB_TOKEN=ghp_xxx) and open a new shell
The assistant cannot invent this token. If it reports success without asking you for one, it did not authenticate.
Check what this install can do¶
Should run runtime <provider> --help and read the Runtime Home:
runtime github --help
runtime files --help
ls ~/.engineering-runtime/capabilities/
ls ~/.engineering-runtime/commands/
Two providers, and only two
This binary ships files and github. The cheatsheets in
~/.engineering-runtime/commands/ cover many other CLIs — aws, gcloud,
terraform, kubectl — but those are Command Engine pass-throughs, not
providers, and they have no operation surface of their own. An assistant
that offers to "use the AWS provider" has misread the directory. See
Command Engine binaries.
Run your first capability (no auth needed)¶
Should run:
runtime capability validate files/notes-roundtrip
runtime capability execute files/notes-roundtrip \
--input path=./hello.txt --input message=hello
Expected:
Step 1: files write
Runtime Context: context_free
Transport: file
Message: wrote 5 bytes to ./hello.txt
Step 2: files read
Runtime Context: context_free
Transport: file
Message: read 5 bytes from ./hello.txt
Output:
hello
capability completed: 2 step(s)
Report on a repository¶
Should run:
runtime capability validate github/github-repo-health
runtime capability execute github/github-repo-health --input repository=<owner>/<repo>
Requires a GitHub token. The input is repository as <owner>/<repo> — not
an organisation name.
Report on an organisation¶
Should run:
Requires organization. GitHub has no native context for Runtime to read,
so the organization is always explicit — the same command means the same thing
on a laptop and in CI. runtime github org list shows which organizations your
token can see.
See Where operations run.
Showcase: scaffold a whole service¶
Using Engineering Runtime, validate the github/java-service-scaffold-and-ship
capability, then show me what its 18 steps would do.
Should run:
Setup required — it does not ship with the binary, and executing it needs a write-scoped token and creates real commits. Validation is the safe way to see it. See Showcase: Java service.
Prove what happened¶
Should run runtime audit tail -n 10:
[2026-08-06T18:12:23+05:30] success consumer=human context=default transport=file command=files write 0ms wrote 5 bytes to ./hello.txt
[2026-08-06T18:12:23+05:30] success consumer=human context=default transport=file command=files read 0ms read 5 bytes from ./hello.txt
When an assistant does the work, consumer=ai appears instead of
consumer=human. Denials are recorded too — nothing executes without a
trace.
Connect the Control Plane¶
Should run:
Enterprise only, and it needs portal.base_url configured — see
Connect the Control Plane.
Write a new capability with your assistant¶
The one prompt to start from. It works on a fresh install, because everything it names ships with the binary or is one command away.
I want to author an Engineering Runtime capability for the release installed on
this machine. The outcome I want is:
show me the repositories that have forked cli/cli, newest first
If I have no capability library yet:
git clone https://github.com/engineeringruntime/engineering-runtime-capabilities
export RUNTIME_CAPABILITIES_DIR=$PWD/engineering-runtime-capabilities/capabilities
Run `runtime --output json capability authoring-context`. Treat its output as the
source of truth — use runtime_home, the absolute paths in contracts, and
selected_source.dir. Do not reconstruct a path from ~, and do not assume
$RUNTIME_CAPABILITIES_DIR is the selected source.
Read the contract at the `agent` path and follow it exactly. It is written for
this exact release and wins over anything you already know, including this
prompt.
Validate, plan, then execute. Validate passing is not evidence it works — show me
what each step returned.
Why it is this short. It does not repeat the contract. RUNTIME-AGENT.md
ships inside the binary and is rewritten into your Runtime Home on every version
change, so it is version-exact in a way a web page can never be — and until
v0.9.3 the published prompt and the contract had already drifted apart. The
prompt now carries only what an assistant needs before it can read one.
authoring-context comes first because it answers the two things an assistant
otherwise guesses: where the file belongs, and what policy will allow. Ask for
JSON — the text output reports the Runtime Home as a parenthetical and the
contracts as a count, which is not enough for anyone who has moved their Home.
The sample outcome is real. Following this exact prompt on 0.9.3 produced
github/repo-forks-review,
now in the public library — validated, planned, then executed against cli/cli
for twenty forks.
If you have no capabilities directory yet, this is the whole setup:
git clone https://github.com/engineeringruntime/engineering-runtime-capabilities
export RUNTIME_CAPABILITIES_DIR=$PWD/engineering-runtime-capabilities/capabilities
That directory is read from and written to — there is no separate authoring setting to configure first.
Should run, at minimum:
runtime capability authoring-context
runtime capability validate <the new file>
runtime capability plan <the new file> --input …
runtime capability execute <name> --input …
Expected from step one, on a machine with a capabilities directory set:
Authoring ready: true
Runtime: 0.9.2 (/Users/you/.engineering-runtime)
Config: compiled default
Policy: compiled safety profile
Authoring source: capabilities-dir — /Users/you/…/capabilities (exists=true)
Write policy: allowed=true
Contracts: 8; providers: 2; allowed binaries: 21
Authoring ready: false means the reason is printed next to it — usually no
capabilities directory configured, or several configured with none named.
Writing your own prompts¶
| Do | Don't |
|---|---|
| Name a URL and a goal | Name a vendor or a tool-specific feature |
| Name the capability you want run | Assume the assistant will pick the right one |
| Ask it to show you the audit record | Take "done" as evidence |
| Say which repo or org | Expect it to guess |
Next¶
Operational examples on this site were verified against Runtime 0.9.8. After bootstrap, the version-exact files in Runtime Home win.