Remediate findings

Remediation turns a finding into a proposed fix in your Instruction Hub. A remediation agent opens a pull request; a human reviews and merges it. That human review is the gate.

When a remediation pull request opens

Only high-confidence findings are eligible for remediation — a finding created at high confidence, or one promoted from low to high as evidence accumulates. For an eligible finding, an isolated remediation agent runs in your worker — the same worker that runs the Friction Analyzer — in its own workspace, and:

1. Checks out a fresh branch of your Instruction Hub repository.
2. Uses a repository-scoped token to draft a change that addresses the finding.
3. Opens a pull request against your hub.

The agent runs in isolation with only a repository-scoped token; it holds no other credentials for your systems. The pull request proposes a change to your hub that addresses the finding; you decide whether it lands.

Review and merge

A human reviews the pull request and merges it. Nothing merges automatically — this review is the gate that decides whether a change lands in your hub. Merging into your hub’s default branch is the same merge event that triggers the publish workflow, so the improved instructions recompile and redistribute through the normal publish path, closing the loop from finding to fix.

Hosts pick up the new release when they refresh their plugins on startup, so fleet-wide adoption is eventual as hosts restart rather than an instantaneous, confirmable event. To check a single host’s state, run promptless-host-runtime status on it. See Enroll your hosts.

Note

Review a remediation pull request as you would any change to your instructions. The remediation agent proposes; you decide.

Evaluation gates

There is no automated evaluation gate before a remediation merges today; human review is the only gate the product ships. Evaluation-gated remediation is a future direction, so do not rely on an automated step deciding whether a fix is safe to merge.