MOVA Contract Writer

Transform a fully calibrated pre-contract into a complete MOVA contract — structured JSON with envelope, instruction profile, and episode frame — ready for execution by any MOVA-compliant runtime.

What this skill does

1. 1. Parses the pre-contract — reads all sections produced by INLINECODE0
2. Maps to MOVA constructs — translates each pre-contract section into the correct MOVA artifact
3. Drafts each artifact — envelope (env.*), data schema references (ds.*), instruction profile, episode frame
4. Human review gate — each artifact is shown to the user for approval before the final contract is assembled
5. Outputs the complete MOVA contract — a single JSON document ready for submission to a MOVA runtime

Requirements

• - A completed pre-contract with Status: VALID from INLINECODE4
• MOVA spec available at /home/mova/.openclaw/workspace/mova-spec/ for schema validation

Pre-contract → MOVA mapping

Pre-contract section	MOVA artifact	Notes
ACTOR (actor, owner, reasonnow)	INLINECODE6	actor = sender/initiator, owner = recipient/accountable
CHANGE DEFINITION (changetarget, changetype, afterstate)

verb_id in envelope | change_type maps to verb: action→create/update, state→route/record, result→analyze/publish | | OBJECT (objectdescription, selectionrule) | ds.* schema reference + input_data_refs[] | describes what is being acted on | | GOAL (goalstatement, verificationmethod, confirmation_owner) | Episode result contract | defines expected result_status and confirmation criteria | | CONSTRAINTS (forbiddenaction, invariant, unacceptableconsequence) | ds.instruction_profile_core_v1 rules | each constraint → a deny or transform rule in instruction profile | | SUCCESS/FAILURE states | Episode result_status allowed values | success → completed; failure → failed/cancelled/partial | | DECISION POINTS (deterministic) | Inline in episode frame or envelope verb | deterministic rules go into policy; human decisions go to human gates | | HUMAN GATES | ds.instruction_profile_core_v1 HITL rules | trigger_condition maps to policy rule; pause execution and wait for human input | | INPUTS (name, available, source) | input_data_refs[] + input_envelopes[] in episode | unavailable inputs → blocking dependency in instruction profile | | DEPENDENCIES (name, type, blocking) | Instruction profile: required_resources[] or blocking rules | blocking deps → must be resolved before execution starts | | ASSUMPTIONS | Episode context notes + instruction profile on_violation | blocking assumptions → deny rule; safe assumptions → warn rule | | TIME LIMITS (deadline, maxattempts, stopcondition) | Instruction profile limits or episode finished_at constraint | encode as policy constraints | | AMBIGUITIES | Annotation in meta.ext of the envelope | documented but not executable until resolved | | LINEARITY CHECK | Validates that the episode frame has no hidden branches | non-linear → decision points must appear as explicit HITL gates |

Verb selection guide

Change type from pre-contract	Verb	Use when
Creating something new	INLINECODE30	afterstate is a new record or artifact
Modifying existing data

update | afterstate is a changed version of an existing record | | Making a routing/selection decision | route | the task is choosing between options | | Recording a fact or observation | record | the task produces an audit entry or episode | | Publishing to a registry | publish | the task distributes a catalog or configuration | | Analyzing data | analyze | the task produces findings, scores, or risk bands | | Planning a sequence of steps | plan | the task produces a plan or strategy | | Explaining a decision | explain | the task produces a human-readable justification | | Summarizing content | summarize | the task condenses input into a shorter form |

Step-by-step process

Step 1 — Receive and validate the pre-contract

Ask: "Paste the pre-contract document (output of mova-intent-calibration)."

Check:

• - Status must be VALID — if BLOCKED, stop here and tell the user to resolve the blocking items first
• All required sections must be present
• No unresolved blocking ambiguities

Step 2 — Identify the core MOVA constructs

From the pre-contract, determine:

1. 1. Verb — use the Verb selection guide above
2. Envelope ID — format: env.[domain]_[operation]_v1 (e.g. env.procurement_po_review_v1)
3. Primary data schema — format: ds.[domain]_[object]_v1 (e.g. ds.procurement_po_v1)
4. Roles — map actor → initiator, owner → accountable, confirmation_owner → INLINECODE47
5. Instruction profile ID — format: [domain]_policy_v1 (e.g. procurement_po_policy_v1)

Show the user this mapping and ask for confirmation before continuing.

Step 3 — Draft the envelope

CODEBLOCK0

Show to user. Ask to approve or edit.

Step 4 — Draft the instruction profile

CODEBLOCK1

Show to user. Ask to approve or edit.

Step 5 — Draft the episode frame

CODEBLOCK2

Show to user. Ask to approve or edit.

Step 6 — Assemble and output the complete MOVA contract

When all three artifacts are approved, output the final contract:

CODEBLOCK3

Spec reference

All schema structures are validated against:

• - INLINECODE50
• INLINECODE51
• INLINECODE52
• INLINECODE53

Use mova-spec-guide skill to look up any concept while drafting.

Rules

• - NEVER accept a pre-contract with status BLOCKED — stop and tell the user what to resolve first
• NEVER invent verb IDs, schema IDs, or policy values outside the MOVA verb catalog — read from spec
• NEVER skip the human review step for each artifact — the user must approve envelope, profile, and episode frame individually
• NEVER produce a contract with unresolved blocking ambiguities — mark it PENDING AMBIGUITY RESOLUTION
• If the pre-contract has optional sections marked notrequired — omit the corresponding MOVA fields
• Generated IDs (envelopeid, profileid, episodetype) follow MOVA naming conventions: lowercase, underscores, versioned with v1
• toolid = 0 unless the pre-contract specifies an external tool channel