Skip to content

Start with AI

Goal: get Engineering Runtime installed, authenticated and running a real capability by asking your AI assistant — without reading the rest of this site first.

You do not need to learn Engineering Runtime to use it. You need to accomplish an engineering task. Your assistant reads these pages; the runtime executes, governed and audited.

Paste this

Install Engineering Runtime by following
https://docs.engineeringruntime.com/get-started/installation/
then bootstrap it, authenticate GitHub, and run the github-repo-health
capability with repository=<owner>/<repo>.

Any capable assistant works. This prompt names a URL and a goal — not a vendor, not a tool-specific feature. That is deliberate, and it is the template every prompt on this site follows. Bring whichever assistant you already use.

More in the prompt library.

What it will do

The assistant walks the Get Started chain:

  1. Install Runtime — one command, no GitHub account needed
  2. Authenticate Runtime — using your platform credentials
  3. Connect GitHub — a token you supply
  4. Run Your First Capability — a real, audited operation

You supervise a named sequence rather than guessing what it did.

What it will ask you for

Things it cannot invent, and should never pretend to have:

Input Why
A GitHub personal access token The runtime uses your credentials. It never issues its own
Your organisation name Nothing can guess which org you mean
Permission to write outside the working directory Installing to /usr/local/bin may need sudo

If an assistant claims it finished without asking for a token, it did not authenticate. Check with the commands below.

How to verify it worked

Do not take the assistant's word for it. Three commands:

runtime version
runtime config validate
runtime audit tail -n 5

runtime config validate reports where every file came from and which auth providers are live. Real output from a fresh install with no token exported:

Config:   ~/.engineering-runtime/config.yaml
Policy:   ~/.engineering-runtime/policy-config.yaml
Context:  ~/.engineering-runtime/context.yaml (active: default)
Capabilities: ~/.engineering-runtime/capabilities
Portal:   disabled (local policy only)

Auth Providers:
  PROVIDER    ENABLED  BINARY     INSTALLED  AUTH STATUS
  github      yes      -          -          ✗ no token found in $RUNTIME_GITHUB_TOKEN; export it (e.g. in ~/.zshrc: export RUNTIME_GITHUB_TOKEN=ghp_xxx) and open a new shell
  gcp         no       gcloud     ✓          (disabled)
  kubernetes  no       -          -          (disabled)
  openshift   no       oc         ✗          (disabled)

That ✗ is what an unauthenticated install looks like — it tells you exactly what to export.

The audit log is the proof. Every operation lands there, success or failure:

[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 runs the work, consumer=ai appears instead of consumer=human — so you can always tell what was done on your behalf.

After github-repo-health — see what the runtime is for

Repo health is a real, audited GitHub operation. It is not the ceiling.

When you want the picture that shows what Engineering Runtime can do — scaffold a Maven service into a repository, commit it, push it, and trigger CI in one capability (18 steps across two providers and the Command Engine) — run the showcase next:

Using Engineering Runtime, validate the github/java-service-scaffold-and-ship
capability, then show me what its 18 steps would do.

Full prerequisites, inputs, and the safe validate-first path: Showcase: scaffold and ship a Java service.

Not a first-run substitute

That capability does not ship with the binary, needs a write-scoped token, and creates real commits. Keep github-repo-health as the first authenticated run; treat the Java service as the next demo once you want the full story.

What it will refuse to do

If you also apply the Runtime Agent contract — reproduced in full on that page — the assistant executes only through runtime — never raw gh, kubectl, terraform or arbitrary shell.

That is a feature, not a limitation. It is what makes the run auditable: work that goes through the runtime is governed by policy and lands in the audit log. Work that goes around it is invisible.

Enforcement depends on your assistant

Some assistants (Claude Code, Cursor today) ship hook systems that can mechanically block non-runtime shell. Most cannot — for those the contract is a strong instruction the model chooses to follow, and nothing stops it being ignored.

This is a statement about hook systems, not a recommendation of a vendor. See AI agent setup for what each can enforce.

What this page does not promise

Assistants are not deterministic. Two assistants, or the same one on different days, will not take identical steps. This page promises the goal chain and the verification commands — not exact assistant behaviour.

If it goes wrong, the commands above tell you where you actually are, and Troubleshooting covers the common failures.

Next

Install Runtime