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 0.5.4 install. 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/kishore-gutta/engineering-runtime-releases/main/install.sh | sh
runtime version

Expected:

runtime 0.5.4

Prepare the Runtime Home¶

Bootstrap Engineering Runtime and show me what it created.

Should run runtime bootstrap. Expected on a first run:

Runtime Home: ~/.engineering-runtime
  created runtime home
Capabilities: ~/.engineering-runtime/capabilities
  seeded 50 user-owned file(s) (existing files left untouched)
  refreshed runtime-owned specs/ and commands/ for (new runtime home) -> 0.5.4: 34 file(s) written
Runtime is ready.

Connect GitHub¶

Authenticate Engineering Runtime against GitHub using my personal access token.

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¶

What can my Engineering Runtime installation actually 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)¶

Run the files/notes-roundtrip capability in Engineering Runtime,
writing "hello" to ./hello.txt.

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: default
  Transport:       file
  Message:         wrote 5 bytes to ./hello.txt
Step 2: files read
  Runtime Context: default
  Transport:       file
  Message:         read 5 bytes from ./hello.txt
  Output:
  hello
capability completed: 2 step(s)

Report on a repository¶

Run the github-repo-health capability in Engineering Runtime
for repository <owner>/<repo>.

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¶

Run the github-org-health-check capability in Engineering Runtime.

Should run:

runtime capability execute github/github-org-health-check

Takes no inputs. It reports on the org in your active Runtime Context, so set that first:

runtime context show

See Runtime Context.

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:

runtime capability validate github/java-service-scaffold-and-ship

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¶

Show me the Engineering Runtime audit log for what you just ran.

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¶

Point my Engineering Runtime at our Control Plane and sync the policy.

Should run:

runtime portal status
runtime portal sync

Enterprise only, and it needs portal.base_url configured — see Connect the Control Plane.

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¶

AI agent setup