0xenzyme/agent-harness/orient

Harness Orient

Use this skill to inspect durable project-control state without mutation.

The current user instruction and project instructions take precedence over this skill. This skill supplies routing and safety boundaries; it does not add an approval requirement beyond the boundaries stated below.

1. Read repo instructions and inspect config:

node <plugin-root>/scripts/agent-harness.mjs config inspect --cwd <project> --json
node <plugin-root>/scripts/agent-harness.mjs orient next --cwd <project> --json

orient next prioritizes one nonterminal enforced checkpoint and emits its revision, control state, sole next action, pause reason, and prohibited actions. When multiple active checkpoints exist, select one explicitly with --run <run-dir>; never choose by timestamp or chat memory. For an accepted one-entry target, use orient next --goal <goal-file> or orient next --milestone <milestone-file> to inspect the same target-scoped decision as execute next. Check the adjacent <target-filename>.plan.json named by Execution Plan: and report the whole target's next action, including pending sync or review. done means the selected Goal or Milestone is complete; reconcile with needUser: null reports a non-user blocker, while need-user carries a concrete decision. When the accepted target is a Milestone, an absent plan is a replan task for that Milestone, not permission to route to a listed child Goal. Use --goal-slice only after the user explicitly narrows the target to one Goal. A ready human Task with satisfied mapped items and concrete Evidence routes to verify-node for receipt capture; ask only when the accepted record is absent.

1. Read the configured adapter, Goal index, bounded status, and only the

relevant Spec/Goal/Run evidence. When the question concerns stale or growing artifacts, also run artifacts inspect --json and read Artifact Lifecycle.

1. Reconcile those artifacts with newer explicit conversation decisions.
2. Recommend one execution path before naming a public entry:

• host-direct for ordinary clear work with no state-sync obligation;
• host-direct-postflight when simple work only needs a bounded update to

state that already existed;

• durable-harness for recovery, audit, milestone acceptance, orchestration,

multiple workers, persistent state sync, or high risk.

1. Map durable and postflight paths to harness:execute; map setup, capture,

and read-only state to harness:init, harness:intake, and harness:orient. Asking and shaping remain ordinary actions.

1. A prepared enforced Run cannot be downgraded to postflight-only. Ordinary

clear work should not invoke Harness merely because the plugin is installed.

1. Proposal competition is an explicit advanced read-only technique for

genuinely ambiguous or high-risk decisions, never a default route.

Do not mutate files, launch workers, create lifecycle artifacts, or perform delivery actions. Treat summaries and worker output as candidate evidence.

For sealed completed targets, report evidenceScope and currentVerification with done: historical acceptance can remain valid while later input hashes are changed. Do not call those later changes verified by the old Run. Route follow-up work separately. Legacy Runs need original source/log recovery before explicit run seal; orient itself never seals or repairs state.