OpenProse contract authoring for agent harnesses

What OpenProse contracts are designed to solve

OpenProse addresses contract authoring: expressing intent by composing requirements instead of encoding every action as a fixed program. A contract records what must remain true, what a one-time call must return, or which sequence must be followed. An agent performs the work, an evaluator assesses the result, and the executor returns evidence for that assessment. Execution and evaluation can repeat as the contract requires.

The intended users are teams building workflows for Prose-Complete coding agents such as Claude Code, Codex CLI, or OpenCode. The artifacts are readable `*.prose.md` files intended to remain the reference for success. That choice matters because the agent session performs the work rather than a separate OpenProse binary. Portability comes from keeping requirements and execution trails reusable across compatible hosts, although the README does not claim that different agents will produce identical results.

OpenProse is not an autonomous agent by itself. It supplies the Contract Markdown format, ProseScript, the `open-prose` skill, and reusable libraries. The agent supplies its own tools. Inputs, capabilities, permissions, and model behavior therefore remain outside the contract language's control.

How responsibilities and Forme subscriptions form a graph

A `responsibility` describes state that should remain true over time. Its `### Maintains` section defines the world-model schema. This identifies the truth kept current, distinguishes material fields from immaterial fields, may divide truth into independently subscribable facets, and states postconditions that a render must satisfy before committing.

Material content affects a fingerprint, which is a content hash compared by the runtime when deciding whether work should rerun. Immaterial content does not move that fingerprint. This is a specific control over change detection, although the README excerpt does not specify the hash algorithm.

`### Requires` lists upstream facets consumed by a node. Forme, the wiring layer, matches `Requires.<facet>` to `Maintains.<facet>` and creates the subscription edge. The graph is therefore derived from contracts rather than wired manually. `### Continuity` determines how execution is awakened: input-driven behavior is the default, self-driven behavior uses a freshness cadence, and external-driven behavior depends on a gateway converting ingress into an edge.

This design makes composition visible in source text. It does not eliminate infrastructure concerns. A standing responsibility still needs a host capable of continuous operation.

Responsibilities, functions, gateways, patterns, and tests

OpenProse defines several contract kinds rather than using one construct for every form of work. A `function` represents a called, stateless helper and uses `### Parameters` through `### Returns`. A `responsibility` represents maintained state and operating intent. A `gateway` models external ingress as a contract, while a `pattern` provides a reusable coordination algorithm. A `test` contains fixtures and assertions.

ProseScript supplies ordered or method-specific steps when sequence and procedure matter. It can also express calls within a node, while subscription handles cross-node composition. This division gives authors a choice between declarative requirements and procedural instructions instead of forcing every requirement into a script.

The test kind is also significant because `prose compose` is described as shaping “outside-in semantic tests.” The excerpt does not document a complete test command for running contract tests through an agent. Repository scripts do expose a repository-level Vitest command, but that command covers `tests/open-prose` and should not be presented as a contract test runner without further documentation.

Installing the skill and authoring a first contract

The documented quickstart installs the skill into a Prose-Complete coding agent. The README names Claude Code, Codex CLI, OpenCode, and other compatible hosts.

npx skills add openprose/prose

After installation, point the agent at a contract and ask it to run the file:

prose run <file>

The session acts as the virtual machine, so there is no separate binary to launch for this workflow. Before running a file, the README recommends reading its contract and starting with the examples in `skills/open-prose/examples/`.

For a new program, the documented interaction starts with initialization:

prose init

Progressive composition then materializes one directory package:

prose compose

If the author already understands one contract and needs focused work, the README names `prose write` instead. A contract begins as a Markdown file with `kind: responsibility` frontmatter and a `### Goal`. The README calls `skills/open-prose/` and `spec/` the deeper sources for grammar and execution semantics, so the quickstart does not document every section needed for a production contract.

Deterministic reruns without deterministic model output

The current language replaces the older judge, verdict, pressure, and fulfillment loop with a deterministic reconciler. According to the migration notice, a render runs when subscribed input fingerprints or the node's own contract fingerprint changes. The README explicitly states that no LLM is involved in the wake or commit decision.

This separates scheduling and commit decisions from agent execution. The host may still use a model while performing contract work, but the documented trigger does not ask a model to decide whether every node should run. Material fields move fingerprints because they represent truth that can affect subsequent work.

That boundary should not be overstated. The README excerpt does not claim deterministic execution, deterministic evaluation, or identical output across hosts. It says the opposite in effect by warning that portability does not guarantee identical model results. The evidence requirement also leaves evaluation dependent on an evaluator and on the executor returning evidence suitable for assessment.

Breaking changes from OpenProse v0.14 and earlier

The migration from `runtime_contract 1` to `2` is explicitly breaking. The project is not a drop-in upgrade for older contract vocabularies. `kind: service` became `kind: function`, and its `### Parameters` to `### Returns` structure replaces the older shape. `kind: system` was removed. Composition within a node is now handled through ProseScript `call`, while cross-node composition uses subscriptions through Forme.

For responsibilities, `### Ensures` became `### Maintains`, which now represents the world-model schema rather than only an output list. The older `### Criteria`, `### Memory`, and `### Fulfillment` sections folded into the new structure. Existing runtime data, including old `ReceiptV0` ledgers, the policy registry, and bundled `runs/`, `state/`, and `dist/` directories, is abandoned rather than migrated.

The migration command is documented as a skill command executed inside an OpenProse session:

prose upgrade --dry-run

It reports mechanical rewrites and cases requiring manual review without editing files. The README specifically says to run it before `prose upgrade`. A real upgrade still requires reviewing diagnostics, particularly when an older `system` or `### Wiring` contract must be flattened or split.

MIT licensing, repository scope, and upgrade boundaries

OpenProse remains MIT-licensed. The repository calls contracts and their trails portable artifacts, while deployment secrets and private data do not need to be published with them. This is a repository boundary rather than a promise that a host has every required tool. A team must still provide the operations, permissions, and ingress mechanisms named by its contracts.

The repository contains the specification under `spec/`, skill content under `skills/`, packages, tests, and workspace configuration. Its root `package.json` identifies `[email protected]` as the package manager and defines a Vitest script for `tests/open-prose`. It is a private workspace package, so the root package is not presented as a published end-user runtime.

Reactor, the reference harness, has moved to `github.com/openprose/reactor` and is described as experimental alpha software without stability guarantees. Its packages and `reactor` binary retain their install names, but OpenProse itself does not guarantee a stable reference harness. Teams should account for both contract-vocabulary upgrades and experimental harness changes when planning adoption.

Editorial conclusion

Adopt OpenProse when an engineering team wants portable, inspectable requirements that can run inside agents already used for development. Do not adopt it as a standalone runtime, deterministic execution engine, or complete substitute for harness capabilities. Verify first that the chosen host is Prose-Complete, that it can perform every operation named by the contract, and, for any v0.14-or-earlier source, that `prose upgrade --dry-run` produces an acceptable migration plan. For v0.14-or-earlier projects, clean runtime state is required because the repository provides no data migrator.

Frequently asked questions

Official sources

1. License: MIT
2. openprose/prose on GitHub
3. Project website
4. README
5. Releases