runward

RW™ · V0.22.0

Docs · Operate · From an AI agent

From an AI agent.

How an AI agent stands up and drives runward end to end: the mental model, the neutral baseline written at init, and building against the charter.

The headline claim — an agent can "discover, install and operate runward with no human at the keyboard" — is true, with one deliberate exception this page explains in full: runward never wires the gate into your repo by itself. The agent can perform that wiring, but only on the operator's explicit say-so. That is a feature, not a gap.

The loop an agent drives is the same everywhere: build, run the check, and on gaps loop back; on green, cross the gate.

The build loop: build, check, loop back or exitYou describe the mission; your agent builds the code and fills the conformance manifests; then runward check --strict decides. If gaps remain, it sends you back to fill the named deliverable and re-run. When everything is filled and every rule accounted for, the gate goes green (exit 0). That is the loop: the check sends you back to build, or lets you exit. Describe the missionThe agent buildsrunward check --strictGate green · exit 0 gaps: fill, re-run
The build loop: build, check, loop back or exit

The mental model: agent drives, runward frames

What runward is

runward does not generate code and is not a runtime. It is a deterministic frame around agent-produced delivery: the agent builds, and runward check audits whether the required deliverables exist and whether every CRITICAL/HIGH craft rule was accounted for with evidence that resolves. The audit is documentary — "runward did not run your code — it is not a runtime". The LLM lives in the harness driving runward, never in the gate.

The operating loop

The whole operating loop for an agent is:

  1. runward init — stand up the mission.
  2. Build, consulting the charter and phase skills.
  3. runward check / runward check --strict --json — read the verdict.
  4. Optionally runward wire — identify the auto-trigger channel and, on approval, wire it.
  5. Cross gates on evidence.

Exit codes are the primary signal throughout:

  • 0 current gate clean
  • 1 gaps
  • 2 no mission found

Step 1 — init writes a strictly vendor-neutral baseline

runward init scaffolds the mission. With no explicit --tools, it writes only the vendor-neutral core and privileges no harness (ADR-0030).

Two surfaces always written

Two surfaces are always written, unconditionally, before any tool profile:

  • AGENTS.md at the project root — the agent charter. This is the open standard read by Codex, Cursor, Copilot, Windsurf, Cline, Zed, Amp, opencode, goose, Junie, Warp and a long list of agents.
  • .agents/skills/runward-<phase>/SKILL.md — the vendor-neutral phase skills, the converged SKILL.md format read by 14+ harnesses, no agent privileged.

Profiles are opt-in

Under --yes (or any non-interactive run) the tool-profile list is empty and the wizard pre-checks nothing. A per-harness profile (.claude/, .cursor/, GEMINI.md, etc.) is an opt-in the operator or agent adds afterward, never a default. This closes a prior defect where init silently defaulted to the claude profile (ADR-0030).

Why neutral by default

Detecting the harness and auto-selecting its profile is reliable for only two or three harnesses and blind for the rest, so a detection-first init would "dress a partial capability as a general one and privilege Claude/Gemini by accident". The baseline already carries full operability: from the end of init, runward check runs in any harness with nothing else wired.

Agent recipe (fully non-interactive)

runward init --yes                 # neutral baseline, greenfield, floor tier
runward init --yes --tools cursor  # add one profile explicitly, on the operator's request
runward init --example             # a filled reference mission, every gate green out of the box

Supported --tools ids: claude, cursor, copilot, gemini, windsurf, continue, junie, trae, kiro (unknown ids warn but do not fail).

Step 2 — build against the charter and phase skills

The charter

AGENTS.md states five non-negotiable boundaries:

  • architecture constrains the model
  • boundaries before the stack
  • complexity deferred until a trigger
  • deterministic frontier
  • security on actions not display

and the working loop:

  • apply the craft rules at the point of action
  • run the decision-loop before any structural decision
  • one ADR per decision
  • never mark a phase done without its Definition of Done

The phase skills

The phase skills self-activate by relevance: each carries a description trigger an agent matches on, and points the agent at the CRITICAL/HIGH rules for that phase and at runward manifest --sync to scaffold the conformance rows it must fill. The skill helps apply rules; it does not enforce them — "runward check --strict is the sole authority".

Continue in this section

← Docs