# Prompt: Translate Workflow for Harness
Use this prompt when a harness needs to run this repository without a checked-in adapter, whether it emits a native workflow/config artifact or runs directly from a primitive map plus ready-to-run handoff.
Before sending this prompt, prepare:
- one selected project pack under `projects/`
- one concrete target scope for the run
- one dedicated writable run root or harness workspace identifier
- the harness facts and operational startup/load-order guidance listed in `AGENTS.md`
- any pack-local staged support material under `projects/<selected-project>/references/`
- verified render/toolchain prerequisites for the selected pack
Required substitutions and context:
- replace `<selected-project>` with the actual repo-relative pack path you selected
- keep the target scope and run root concrete, not placeholder text
- attach or preload the selected pack and reusable repo materials named below
Expected result and next step:
- this prompt must return a ready-to-run handoff for the selected pack and scope
- keep that handoff in the same thread/session, or paste it above the next prompt, then run `prompts/run-selected-project.md`
```text
You are translating a neutral RFC workflow pack into this harness's native primitives.
Load these operator-provided run facts before planning execution:
- selected project pack under `projects/`
- target scope
- run workspace or run root
- verified render/toolchain prerequisites for the selected pack
- any staged pack-local support material under `projects/<selected-project>/references/`
- the operational startup/load-order guidance in `AGENTS.md`
- the harness's native workflow/config language, schema, or DSL when one exists (for example, `Ultracode`), plus the form the emitted runnable artifact should take, or an explicit `none`/`not supported` when this harness runs directly from a primitive map and handoff
- any harness-native schema, reference docs, example configs, templates, or validator-facing shape needed to emit valid runnable workflow/config text when the harness expects native workflow/config syntax, or an explicit note that no separate native artifact is supported here
Load these repo inputs before planning execution:
- `workflow.contract.yaml`
- the neutral workflow docs under `core/`
- any reusable role briefs under `briefs/`
- any reusable mechanics under `toolchains/`
- any templates needed for active stages
- the selected project pack under `projects/<selected-project>/`
- `AGENTS.md`, treating it as operational startup/load-order guidance to translate into harness-native execution setup
Your job is translation, not redesign.
## First, gather the harness facts you will translate against
State the exact native mechanism this harness will use for each of these:
- controller primitive
- stage execution primitive
- role brief delivery
- gate/checkpoint mechanism
- recursive correction mechanism
- evidence artifact workspace
- public deliverable workspace
- escalation path
- repo-file loading method
- native workflow/config language, schema, or DSL plus the emitted runnable artifact form, or an explicit `none`/`not supported`
- native workflow/config authoring references: schema, reference docs, examples, templates, or validator-facing shape needed to emit valid native text when a separate native artifact is required, or `none required`
If any item is unknown, stop and ask for that fact before claiming the workflow is translated. For the native workflow/config fields, an explicit `none`/`not supported` is a concrete answer when this harness does not use a separate native artifact. If the harness expects native workflow/config syntax but you were not given the authoring references needed to emit valid native text, stop and escalate instead of falling back to a prose plan or generic controller/stage description.
## Translation rules
1. Treat `workflow.contract.yaml` as authoritative for stage IDs, stage order, entry criteria, outputs, role visibility, backpressure, and the public/evidence split.
2. Preserve workflow semantics exactly. Translate the workflow into native primitives such as jobs, tasks, workers, agents, lanes, or staged prompts, but do not change what the stages mean.
2a. Translate `AGENTS.md` operational startup/load-order guidance into this harness's own execution model before execution. Treat it as run-shaping guidance, not as something to ignore or copy verbatim without translation.
3. Preserve the workflow's evidence discipline: public RFC text is drafted from accepted evidence, not from memory, orientation summaries, or project-pack overview text alone.
4. Preserve the separation between public deliverables and evidence artifacts.
5. Preserve recursive correction: when a gate fails, route the fix to the earliest faulty artifact and then re-run only affected downstream stages.
6. Preserve the late-stage review shape: review lanes, reader-facing gates, clean-room proof, and final packaging remain distinct stages unless the contract explicitly combines them.
7. Do not create repo-local harness adapter files, command stubs, or hidden policy layers unless the operator explicitly asks for them outside this repo.
8. Keep `core/` source-agnostic. Any source-specific behavior belongs only to the selected project pack.
9. If the harness lacks a native primitive the contract expects, emulate it with the smallest explicit mechanism and record that mapping.
9a. If this harness needs a native workflow/config object, staged prompt bundle, job graph, or equivalent runtime representation, generate or configure it explicitly before first execution and include the actual native text/object/artifact shape in the handoff. A prose-only description is insufficient when the harness expects runnable native workflow/config syntax.
9b. If this harness does not support a separate native workflow/config artifact, a concrete primitive map plus ready-to-run handoff is acceptable. If it does expect a named native workflow/config language/schema/DSL, but the operator did not supply enough schema/reference/examples/templates to author valid text in it, return an explicit escalation for those missing inputs instead of substituting generic session primitives.
10. Treat the selected target scope, run root, and verified prerequisite state as required run facts. Do not invent or silently replace them.
## Produce a translation plan with these sections
### 1. Native primitive map
Map each neutral concept to a harness primitive:
- controller
- stage execution unit
- role brief delivery
- gate/checkpoint
- evidence artifact workspace
- public deliverable workspace
- recursive correction loop
- escalation path
- native workflow/config language, schema, or DSL plus the emitted runnable artifact form, or `none`/`not supported`
- native workflow/config authoring references used to emit valid native text, or `none required`, or an explicit escalation if native syntax is required but the inputs are unavailable
### 2. Stage wiring
For each contract stage, state:
- which native primitive will execute it,
- which inputs it reads,
- which outputs it must produce,
- which gate blocks promotion to the next stage,
- and how failures route backward.
### 3. Runtime loading order
State the exact repo load order for this run:
- contract,
- neutral core docs,
- reusable briefs/toolchains/templates needed,
- selected project pack,
- `AGENTS.md` operational guidance translated into harness-native startup/execution ordering,
- the named native workflow/config language, schema, or DSL plus any native workflow/config artifact or equivalent runtime configuration required before stage execution when one exists,
- then execution.
### 4. Harness gaps and compensations
List any harness limitation that affects the workflow and the explicit workaround you will use without changing workflow semantics.
### 5. Ready-to-run handoff
End with a concise run handoff that this harness can execute immediately for the selected project pack.
If this harness requires a native workflow/config artifact or equivalent runtime configuration before it can run stages, include that generated representation or the exact configuration it must instantiate before the first execution step.
If this harness does not support a separate native workflow/config artifact, say so explicitly and make the primitive map plus ready-to-run handoff concrete enough to execute immediately. When the harness expects a named native language/schema/DSL such as `Ultracode`, include the actual native workflow/config text or object shape in that language/schema/DSL, not just a prose summary of what it should do.
This handoff is required context for `prompts/run-selected-project.md`, so keep it structured enough to paste above that prompt in a fresh thread if needed.
The handoff must name, at minimum:
- selected project pack,
- target scope,
- run workspace or run root,
- evidence workspace path,
- public workspace path,
- verified render/toolchain prerequisites,
- controller primitive,
- stage execution primitive,
- native workflow/config language, schema, or DSL plus the emitted runnable artifact form, or `none`/`not supported`,
- the native workflow/config authoring references, examples, or templates used to emit the artifact, or `none required`, or an explicit escalation if native syntax was required but those inputs were unavailable,
- the actual native workflow/config artifact or equivalent runtime configuration required before execution, or an explicit statement that none is needed,
- the first execution step,
- and the escalation condition that stops the run.
## Short worked example of the expected specificity
This example is illustrative of output shape only. Replace the primitive names and paths with the real harness facts you gathered.
This specific example is only valid for a harness with **no separate native workflow/config syntax**. If your harness uses a named language/schema/DSL such as `Ultracode`, replace the `none` fields below with the real native language, the authoring references needed to emit valid text, and the actual emitted native artifact.
### Example harness facts
- controller primitive: one orchestrator session that can dispatch stage-specific worker prompts
- stage execution primitive: one worker task per contract stage
- role brief delivery: each worker prompt includes repo-relative files to read before acting
- gate/checkpoint: a stage result with `PASS` or `FAIL`, produced artifact paths, and a named root-fault artifact when failing
- recursive correction: the controller re-dispatches the earliest faulty stage, then only the affected downstream stages
- evidence artifact workspace: `<run-root>/evidence/`
- public deliverable workspace: `<run-root>/public/`
- escalation path: the controller stops and emits `BLOCKED` to the operator with the missing fact or contradiction
- repo-file loading method: workers are told which repo files to read in order before writing outputs
- native workflow/config language, schema, or DSL + emitted artifact form: none; this harness runs directly from controller/worker prompts
- native workflow/config authoring references: none required because this example harness has no separate native workflow/config syntax
### Example translation excerpt
1. Native primitive map
- controller -> orchestrator session
- stage execution unit -> worker task
- gate/checkpoint -> controller-reviewed stage result
- evidence artifact workspace -> `<run-root>/evidence/`
- public deliverable workspace -> `<run-root>/public/`
- recursive correction loop -> targeted re-dispatch from the controller
- native workflow/config language/schema/DSL -> none
- native workflow/config authoring references -> none required
2. Stage wiring sample
- `claim-ledger`
- executor: draft-author worker task
- reads: `run-brief`, `context-packet`, `source-map`, optional `source-scout-report`
- writes: `<run-root>/evidence/claim-ledger.md`
- promotion gate: every claim has authority class, source anchor, status, and public-section impact
- failure route: if evidence is missing, return to `source-map` or `source-scout`; if evidence exists but claims are malformed, re-run `claim-ledger`
3. Ready-to-run handoff example
- selected_project_pack: `projects/fossil/`
- target_scope: `document:delta`
- run_root: `/tmp/fossil-delta-run`
- evidence_dir: `/tmp/fossil-delta-run/evidence`
- public_dir: `/tmp/fossil-delta-run/public`
- verified_prerequisites: `kramdown-rfc` and `xml2rfc` available
- controller: orchestrator session
- stage_execution: worker task per contract stage
- native_workflow_config_language: `none`
- native_workflow_config_authority_inputs: `none required`
- native_workflow_config_artifact: `none required; controller/worker prompts are the runtime representation in this harness`
- first_step: load `workflow.contract.yaml`, then `core/`, then required reusable briefs/toolchains/templates, then `projects/fossil/`, then dispatch `scope`
- escalate_when: a required harness fact is missing, a required source is absent, a harness-native language is required but its schema/reference/examples/templates were not supplied, or any gate returns `FAIL` without a repairable root artifact
## Translation guardrails
- Do not collapse evidence-building, drafting, review/correction, and clean-room proof into one undifferentiated pass.
- Do not promote project-pack summaries into authoritative technical behavior.
- Do not replace stage gates with best-effort suggestions.
- Do not expose prompts, tool transcripts, internal IDs, or workflow archaeology in public RFC output.
- Do not assume a harness-specific path, command name, plugin, or installation model that is not present in the loaded inputs.
```